Monday, August 29, 2005

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...


Anonymous Anonymous said...

[b]King Of Pirate Online[/b]

King Of Pirate is a fully 3D-designed multiplayer online game based on 5,000 years of pirate history.

In it, comical pirate characters and creatures travel the high seas and encounter intricate story-based quests,

wondrous cities and beautiful landscapes in their search for treasures fit for a king – or a king's ransom!

Though the excitement of ship-to-ship combat is a heady brew for newcomers and veterans alike,

many players take pride in their place among the community. Whether you seek to enforce the laws of the KoP world,

Tales of pirates private server
pirate king online private server
top/pko private server
private server
igg top

July 10, 2010 at 8:29:00 AM PDT  
Anonymous Buy Generic Viagra said...

I was looking for this information, thanks for put in this easy way, I mean in a easy way to understand it jajaja, well until the next time.

May 11, 2011 at 2:47:00 PM PDT  
Anonymous said...

Thanks for this article, really useful piece of writing.

November 21, 2011 at 12:51:00 AM PST  
Anonymous Anonymous said...

You wrote a very interesting article. And I agree with you. hair loss Read a useful article about tramadol tramadol

January 13, 2012 at 6:49:00 AM PST  
Anonymous Anonymous said...

I really liked your article. cardiovascular Read a useful article about tramadol tramadol

February 19, 2012 at 7:36:00 AM PST  

Post a Comment

<< Home