Tom on "Joel on Software" - BUFD: Big Up Front Design

Yesterday I read a posting on Joel on Software about Big Up Front Design (BUFD). Joel Spolsky, the namesake for Joel on Software, contrasts BUFD to Agile and states his preference for BUFD. I must admit that I was a little disappointed with how he presented his argument in the posting but I don't want to draw too many conclusions about him or his ideas based on this one posting.

Joel's point is that by doing BUFD you will save yourself from problems later in the project. According to Joel, not doing BUFD will undoubtly lead to rework that will cause delays in the project.

Rather than engage in a Holy War about software development methodologies at this point, my prefererence is to try to understand Joel's perspective a little better before I draw any conclusions about him or his ideas. Holy Wars tend to polarize people and ideas and I don't think that the question of BUFD vs Agile is battle that one has to take sides on. There are times when BUFD makes sense and times when Agile makes sense. There are even times when Agile and BUFD make sense on the same project.

So, in my opinion, the real question should be: In the context of the application, the customer, the technology being implemented and the makeup of the development team, does BUFD make sense?

Here are some questions that I would ask Joel about the project to help me determine if I would choose to do BUFD:

• What role are you, Joel, playing in the project you were referencing? (If Joel is filling the role of Software Architect on the project I can understand his preference for BUFD. Software architects are usually the smartest, most experienced and most strong willed people on the project team. They see there job is to architect things and so they diligently get to it right away on a project. But I have seen (and have been) the software architect over imposing themselves/myself on a development team by establishing architectures that a development team is forced to comply with.)
  
• How much time has been scheduled on the project for the Big Up Front Design phase? (BUFD can take months - it can also be never ending. You have to stop designing and start building at some point. Joel's point is that spending time on BUFD is intended to mitigate the risk of re-work. But re-work is an inevitablilty in our business. So we should not try to mitigate re-work but learn how to most effectively deal with it. But BUFD actually introduces an even greater risk to a project - project cancellation because of too much money spent on things that don't return business value. What returns business value? Working software in production.)
  
• How stable are your requirements? (If your requirements are stable then you may have a case for BUFD. But we all know that requirements change and often these changes require changes to the applications architecture.)
  
• How well does the development team know the domain of the application? (Eric Evans, author of Domain Driven Design, has been quoted as saying that a development team really doesn't know the applications domain model until the application has been in production for a year. Changes in the domain model as a team better understands the domain can have a big impact on the systems archtitecture.)
  
• How experienced in the development team in the technology being implemented? (BUFD for a development team that is new to technology often leads to rework as the team better understands how to work within the constraints of the new technology.)
  

So Andrew, here is what I would like for you to take away from this posting:

Don't be quick to take a position on an issue
Ask good questions to get to know what the real issue is (the real issue here is not BUFD vs Agile, but should BUFD be used on the project in question)
Ask even better questions to understand the context of the problem
Ask your best questions to get an understanding of other person's perspective on the problem

Don't argue your point in hopes that you will be able change the other person's mind
You will find that arguing with someone rarely ever changes their mind. They may concede your points, but most likely because you have worn them down with arguing or out skilled them in debating. But in reality you will not have won them over. Will they get behind you and actively support your decisions? Or will they will most likely get behind you and stick their tongue out at you?

Don't assume that the person that you are talking with understands your perspective
People may get the impression from Joel's posting that Agile means no design up front. But Agile does value doing up front design, but just enough design to get started and no more. Make sure that you are talking about the same thing - define your terms and state your position clearly early in your discussion so as to not waste time talking about your apples vs their oranges.

It is still worth the effort to discuss differing ideas with people
Even if you most likely won't convince someone to embrace your perspective through debate, it is still worth the effort to intelligently articulate your ideas with them. This is an important point that merits it's own posting. I look forward to telling you more about it...