I have a really hard time trying to convince colleagues at work that Big Design Up Front (BDUF) does not work, that it is waste and the more time you spend coding the more likely you are to reach a better design solution. But before we go deeper into this discussion it is worth defining what, after all, is BDUF.BDUF is characterized by a few preconceptions about software development. They are: You should not make mistakes, therefore you should spend time up front making sure you will not make mistakes later If you don't design for (put your favorite non-functional requirement here) you will not be able to put it there at the end We need to make big changes to the (whatever module) so we need to really re-think the architecture and what we need to change to be able to do those changes before starting to program. This feature/project is so big that we must really design it properly before we can start coding The list would go on, I'll stop here.The problem with explaining why BDUF does not work is that iterative design is most effective in exactly the same situations as the proponents of BDUF say it would fail. Each of the reasons above could be used to propose Iterative Design (ID): You should not make mistakes, therefore you should try to make as many mistakes as possible as early as possible and learn from them before you release the software If you don't iterate your design for (put your favorite non-functional requirement here) you will not be able to design something that works correctly We need to make big changes to the (whatever module) so we need to go through each change one at a time with a proper support of unit tests and iterate the design while making sure we don't break anything that was working properly This feature/project is so big that we must really start small and build the design over several iterations. It cannot be designed up front. So what is the difference between ID and BDUF then? It is rather one of approach. While BDUF proponents defend that you should tackle uncertainty (which is at the heart of each of the statements above) with a pre-planned (pre-designed) approach. The proponents of ID argue that you should spend only enough time to come up with a solution that would work with the current environment, and then with time, adapt or change your design based on the additional information that you obtain while executing the design (don't forget the Unit Tests! ;).So, when faced with a "big/hard/complex change" a BDUF adept would design until he would be perfectly happy with the design before proceeding to implementation. In real life however things are not that simple. Most designs fail ("most" because at some point one will work), they fail because we work with complex environments that are hardly predictable enough for us to be able to produce reliable designs that touch every possible point of the known problem space.An ID adept would use enough time to have a design solution that would work. The main difference here is that an ID would not try to make the design full-future proof (i.e. ready to tackle all possible predictable situations), but rather concentrate on making a design that would work with the restrictions and situations to be tackled at the time of design (not hypothetical future possible situations). Later, if and when the design would fail in a specific situation it would be changed or altered.Many of the BDUF proponents have an issue with this approach because "intuitively" it seems that the ID approach is "wasteful" in that it does not produce a "ready" design but rather it produces a design to which programmers will have to come back again and again "because they did not spend enough time designing it properly" (so the comment goes).But that's just it! The ID approach is counter-intuitive, but it works. It is present in many successful industries (like Toyota's famous Production System) and it works.I'm sure at some point in time there will be a proper analysis "why" ID works better than BDUF, but until then trust the empirical evidence, empirical evidence is also important, not just theory (which is what the BDUF success is based on).So, finally, why doesn't BDUF work in my opinion? In more than 10 years experience I've seen BDUF and ID fail often, but the ID people are always able to recover from their failures faster and more often than the BDUF people. I guess the reason is: it's impossible to avoid mistakes, so any process that accepts and accounts for that will be more effective in the long run. Posted by

I have a really hard time trying to convince colleagues at work that Big Design Up Front (BDUF) does not work, that it is waste and the more time you spend coding the more likely you are to reach a better design solution.

But before we go deeper into this discussion it is worth defining what, after all, is BDUF.

BDUF is characterized by a few preconceptions about software development. They are:

1. You should not make mistakes, therefore you should spend time up front making sure you will not make mistakes later
   


2. If you don't design for (put your favorite non-functional requirement here) you will not be able to put it there at the end
   


3. We need to make big changes to the (whatever module) so we need to really re-think the architecture and what we need to change to be able to do those changes before starting to program.
   


4. This feature/project is so big that we must really design it properly before we can start coding
   

The list would go on, I'll stop here.

The problem with explaining why BDUF does not work is that iterative design is most effective in exactly the same situations as the proponents of BDUF say it would fail. Each of the reasons above could be used to propose Iterative Design (ID):

1. You should not make mistakes, therefore you should try to make as many mistakes as possible as early as possible and learn from them before you release the software
   


2. If you don't iterate your design for (put your favorite non-functional requirement here) you will not be able to design something that works correctly
   


3. We need to make big changes to the (whatever module) so we need to go through each change one at a time with a proper support of unit tests and iterate the design while making sure we don't break anything that was working properly
   


4. This feature/project is so big that we must really start small and build the design over several iterations. It cannot be designed up front.
   

So what is the difference between ID and BDUF then? It is rather one of approach. While BDUF proponents defend that you should tackle uncertainty (which is at the heart of each of the statements above) with a pre-planned (pre-designed) approach. The proponents of ID argue that you should spend only enough time to come up with a solution that would work with the current environment, and then with time, adapt or change your design based on the additional information that you obtain while executing the design (don't forget the Unit Tests! ;).

So, when faced with a "big/hard/complex change" a BDUF adept would design until he would be perfectly happy with the design before proceeding to implementation. In real life however things are not that simple. Most designs fail ("most" because at some point one will work), they fail because we work with complex environments that are hardly predictable enough for us to be able to produce reliable designs that touch every possible point of the known problem space.

An ID adept would use enough time to have a design solution that would work. The main difference here is that an ID would not try to make the design full-future proof (i.e. ready to tackle all possible predictable situations), but rather concentrate on making a design that would work with the restrictions and situations to be tackled at the time of design (not hypothetical future possible situations). Later, if and when the design would fail in a specific situation it would be changed or altered.

Many of the BDUF proponents have an issue with this approach because "intuitively" it seems that the ID approach is "wasteful" in that it does not produce a "ready" design but rather it produces a design to which programmers will have to come back again and again "because they did not spend enough time designing it properly" (so the comment goes).

But that's just it! The ID approach is counter-intuitive, but it works. It is present in many successful industries (like Toyota's famous Production System) and it works.

I'm sure at some point in time there will be a proper analysis "why" ID works better than BDUF, but until then trust the empirical evidence, empirical evidence is also important, not just theory (which is what the BDUF success is based on).

So, finally, why doesn't BDUF work in my opinion? In more than 10 years experience I've seen BDUF and ID fail often, but the ID people are always able to recover from their failures faster and more often than the BDUF people. I guess the reason is: it's impossible to avoid mistakes, so any process that accepts and accounts for that will be more effective in the long run.