How do you ensure the quality of the design when the design is "by doing"?



  • I am convinced that an incremental design can be good.

    But if in the beginning a bad design is chosen and the subsequent steps are always based on it, in my opinion it can also run very badly.

    So how do you ensure the quality of the design when the design is "by doing"? How do you prevent the software from degenerating, because the team (or one of the teams) is always quick to hack something instead of making a meaningful design?

    How can I get involved as a tester early enough to recognize bad designs early on?

    I know the textbook wisdom, but does anyone have practical experience?



  • There are a few practices and concepts that are very important to iterative design.

    First, there should be a refactoring step in every iteration. This allows space for improvements to be implemented so you are not stuck with design decisions that the team has outgrown.

    Second, the team should be building with an architecture that is as decoupled as possible. This allows for almost any design decision to be undone. This may seen inefficient (and strictly speaking, it is) but if the team is releasing frequently and getting constant value out of their application, then the value from the earlier design should have more than paid for the refactor. If it doesn't, that's a great topic for the team to discuss and improve upon.

    Third, each design should be of good quality and viable in its context. That is to say that the team shouldn't be cutting corners to get to fast releases, just using simple, but still solid, designs for their early iterations.

    Fourth, there is an idea of "last responsible moment" in iterative design and architecture. The team should strive to put off all decisions in design until they can't any longer without the delay negatively impacting the application. That's a hard balance to find, but luckily it's usually less of a moment and more of a range.

    Finally, it is important to remember that you can't make paradigm shifts incrementally. The team may encounter a point at which they have to completely change some aspect of design. It happens in Scrum, it happens in waterfall. The decoupled architecture should make it less painful, but it will happen. If a team reaches that point, they shouldn't avoid doing the change just because it isn't incremental. Hope this helps.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2