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

Why is asking good questions important? Good question!

Andrew - I have a really good developer that I have been working with that is stuggling with some new things that he is trying to learn so I sent him this email today to encourage him to ask good questions to help him in his learning process. I thought you might like to read it.

"Mike - I have been wanting to catch up with you about some more stuff that I think may be of interest to you. I have been reading a lot of stuff by Eli Goldratt lately. His most significant contributions have been with his ideas in his Theory of Constraints (TOC). His first book, The Goal, where he first introduces TOC using the forum of a business novel, is becoming required reading in most business schools.

"There are three things that I really like about Goldratt's work. First is his Theory of Constraints which parallels a lot of what we are doing with our Agile software development. TOC comes from the manufacturing world but the principles can apply to software development too. We can chat more about TOC later but it is not the main idea that I wanted to share with you now.

"The second thing I really like about Goldratt is that he uses the Socratic method to teach his concepts within his business novels. Check out The Goal to see how he does it. If you really like the book, then pick up Critical Chain, another of Goldratt's business novels, which is more project management oriented than manufacturing. These books will give you some insights into Agile that many people even in the Agile camp don't get.

"So in using the Socratic method in The Goal, Goldratt has Jonah, the mentor, asking leading questions to his student (Alex Rogo) to get him to draw the conclusions/solutions himself that Jonah wants him to draw. Thus Alex Rogo ends up with a sense of ownership of the solutions that he would not have if the solution would have been handed to Alex from Jonah. In using the Socratic method Goldratt shows how to use influence rather than the wielding power to get things done. This is the third thing that I like about Goldratt - his teaching on how to create change in an organization.

"So, Mike, how does all this relate to you? Well, one of the things that Goldratt teaches is the thinking processes that can be used to create meaningful change. In the beginning of any change/thinking process you have to start with articulating the problem that you are trying to solve. In your case, learning a new technology or more importantly making a paradigm shift to Agile and Object Orientation, it is important for you to ask specific questions as to what you don't understand. Gaining understanding of Agile practices and OO is the problem that you are trying to solve. So articulate what you don't understand, not just that you don't understand. Then be disciplined in asking questions. Right now you are in a good environment, working with a team that encourages questions - take advantage of it.

"So don't let something that you don't understand get past you without asking about it. Don't just say you don't understand - think through what you know and what you don't know and craft a good question to ask.

"I know this process works. It has worked for me. Sometimes just coming up with an insightful question will give you what you need to answer your own question. And sometimes not, so don't hesitate to ask.

"Let me know if you have questions. Meaningful, well crafted questions, that is...

Tom"

Why do I think I have anything worth teaching my son?

Andrew with his Dad on the right and Dan Beaver, lifelong friend of Andrew's Dad on the left. (I think that is Martin Fowler sneaking up on Andrew from behind. Nope, he has too much hair on the top of his head to be Martin.)

Andrew, I don't think I am any smarter or wiser than the next guy. I don't have anything to share with you that I have figured out on my own or earned based on my own merit. What I do have is the extremely good fortune to have had some really great teachers in my life. So all I want to do is pass down to you those things that they have taught me.

My first great teacher has been your Grandpa Looy. Even before I was your age I was watching him work hard and I saw in him the joy of working when he was doing what he loved and when he was working with people that he liked and respected. As you and I continue with our conversations you will see that I have followed his example in choosing to work with people that I love and respect. Your Grandpa Looy has also been a great dad to me and my love for you comes from knowing how to love a son through his example of loving me.

My second great teacher has been your Uncle Mark, probably the smartest and funniest guy I know. As a big brother, he taught me though his example to set and meet the highest standards of integrity. But it his passion for the most important things in his life, his family and his ministry, that I find to be the most remarkable and inspiring. I am fortunate to have a big brother that, like our father, loves what he does and loves the people around him.

As we continue with our conversations I will share with you my experiences with some of the most wonderful people who have taught me so much. I look forward to reminiscing as I gather my thoughts to share them with you.

So who is Andrew?

Andrew is my son, age 10 at the time we begin this blogging experience together.

My intent with this blog is to share with Andrew those things that I am learning about work, family, faith and purpose in life. Some things he is ready to learn now and others he will have to wait before he will be able to grasp the lesson. So as I go forward writing in this blog it will be in the voice of me sharing my life's lessons and experiences in the form of Conversations with Andrew.

I love you, son...

Dad