Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

December 21st, 2010 at 1:37 pm

Agile dogmas: You shall never do any design.

with 9 comments

Agile has become one of the most beneficial and needed change in software development. It has helped to move the focus of software development:

  • From: Project managers, architects, documentation and requirements.
  • To: Programmers, implementation and opened discussions.

Paradoxically, some companies and programmers are pushing this change of paradigm so hard, that they are falling in the very same errors that doomed waterfall: Lack of flexibility and dogmatism.

One of the most popular dogmas among the agile community is: “you shall never do any design.”. This dogma it’s been mostly influenced by TDD, and that’s why this article focuses on it

TDD and its core pattern “red-green-refactor”, is an emergent design engineering practice that can dramatically improve the quality of the code. Being based in emergent design means that is not necessary to do any explicit design in software development, but that the design will flourish from the implementation.

The issue with TDD, as with any other emergent design approach, is that it doesn’t make any differentiation between the implementation design level (tactics), and the architectural design level (strategy). This lack of differentiation between strategy and tactics, for simple developments is OK, but for more complex developments becomes an issue.

A good metaphor would be climbing a mountain. Let’s imagine two different approaches; one where every single step of the route is prepared beforehand, and the other where we would just start climbing paying attention just to what we have a few steps ahead of us. The first approach would be the equivalent of an extremist waterfall approach; the second would be the equivalent of an extremist approach to agile. Obviously none of them would work.

Software development is, in that sense, like climbing a mountain. It is necessary to have a strategy and a tactic. Is also important to realize that, as climbing, we have to adapt to the different circumstances we face in the day to day of software development.

TDD, as any other emergent design technique, is ideal for the tactical part of software development, but they ignore the strategic part, which for complex developments is very important.

One of the biggest factors to determine whether a development is simple or complex is uncertainty. Having a high uncertainty means that there are a lot of critical details from the development that are no evident. When uncertainty is high, is when we can take advantage of doing design.

One sample of simple development, with almost no uncertainty, and which won’t require any previous design would be developing a component that would take a quantity and a percentage and would tell us what the interests are at the end of the year.

An example of a more complex development would be to develop a component that would be able to resolve a Sudoku. In this case we would take advantage of doing some previous design.

When doing designs, is important to take into consideration the following guidelines:

  1. The design should be informal. It shouldn’t have to be in any particular format or using any particular methodology.
  2. The design should be incomplete. We should distance from the Waterfall BDUF, we only want to capture the 20% of the essence, which is going to help us fix the 80% of our problems.
  3. The design should be small, and should take short time. We shouldn’t expend more than 2 hours doing the design, if so, the reason would probably be that we need to split the development into smaller development items.
  4. The design should be democratic and simple. This means that there shouldn’t be any architect throwing the design to the programmers. The design should be done via open discussions with your colleagues, and simplicity should be preferred to any other approach.
  5. The design changes and evolves. We have to move away from the waterfall approach where the design is static, in agile, the design should be used to help us identify the bigger picture and it changes as we discover hidden aspects of what we are developing.

Continuing with the previous Sudoku example and with the design guidelines just commented above, one design approach for a component that resolves Sudokus summarized in a few points, could be:

  • To find the solution for a Sudoku we have to guess, one at a time, what are the missing numbers in the empty cells.
  • The best approach to pick the next number to guess is to find a blank spot in the Sudoku that can only hold 1 valid number.
  • When a solution for one cell is found, a new Sudoku with that cell filled is created and recursively we keep looking for the next solution until all the cells are filled. Then the Sudoku is solved.
  • When there isn’t any cell with an unique possible value, we have to search the cell with the less amount of valid possible values and create an hypothesis from there. That’s it, from the list of possible values, pick randomly one of them.
  • With the hypothesis we keep looking for the solution as if it wasn’t an hypothesis, but a completely valid solution. The difference is that with hypothesis, if we ever get to a point where there isn’t any possible solution, we go back to the originating Sudoku of the current hypothesis, and we create a new hypothesis.
  • The hypothesis can contain other hypothesis.

It is important to realize from the previous design that it doesn’t get into implementation details, and is very informal. They are only a few guidelines to help with the development.

Even thought, they may not seen very important, this mini design sessions are key to help developers to obtain the bigger picture of what they are developing. Remember:

  • It is not right to try to guess beforehand what are all the directions we have to take paying no attention to the road.
  • Neither it is, to start walking only to realize 2 kilometres later that we took the wrong direction.

Balancing out the right amount and timing of designing and coding is, with any question, a quality common to all the best programmers in the world.

9 Responses to 'Agile dogmas: You shall never do any design.'

Subscribe to comments with RSS or TrackBack to 'Agile dogmas: You shall never do any design.'.

  1. […] This post was mentioned on Twitter by Alberto, Branimir Karadžić. Branimir Karadžić said: Agile dogmas: You shall never do any design.: Agile has become one of the most beneficial and needed change in s… http://bit.ly/hGOfRg […]

  2. […] Agile dogmas: You shall never do any design. | Making Good Software […]

  3. Nice post. Nothing to add.

    Ken Downs

    23 Dec 10 at 7:07 am

  4. Agile development has no dogma against design. Quite the opposite. Agile development is about doing design all the time.

    Andy Thomas-Cramer

    23 Dec 10 at 8:18 am

  5. Good point about architecture being like strategy and implementation being like tactics.

    George Fairbanks says in “Just Enough Software Architecture” that the amount of time you spend doing architecture and up-front design depends on the amount of risk involved. Do just enough design to understand and mitigate the risks. Of course you have to identify your risks first.

    It’s interesting that you chose sudoku as an example. Did you have the following blog post in mind, by any chance?

    http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html

    Dean

    23 Dec 10 at 8:52 am

  6. Agree with Andy. Agile is about development with design in mind.

    Agile Scout

    23 Dec 10 at 5:09 pm

  7. Hi guys, first, let me apologize for the late response… I have been quite busy lately…

    @Andy and @Agile_Scout:

    I see your point about Agile being about designing all the time, and I agree, that´s true. I guess the point I was trying to make is that even thought agile is always pushing you to redesign, you sometimes have to look further than your own feet to know where you have to go, which is in my opinion what you will end up doing if you follow up to the extreme TDD.

    @Dean

    I really think that the quote you used in your comment is excellent [George Fairbanks says in “Just Enough Software Architecture” that the amount of time you spend doing architecture and up-front design depends on the amount of risk involved.]

    I actually didn’t see that post first, It´s all based in a Sudoku resolver I did for fun at home, where I first got to that initial design, but that link http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html is definitely worth to check–

    Thanks for all your comments!

    Alberto Gutierrez

    27 Dec 10 at 6:07 pm

  8. […] Agile dogmas: You shall never do any design. (Dec 21, 2010) […]

  9. You have it backwards. Agile is very much about good design.

    Here’s a link to the short list of agile principles:
    http://agilemanifesto.org/principles.html

    This is the one about agile design:
    “Continuous attention to technical excellence
    and good design enhances agility.”

Leave a Reply