Dear Software Craftsmen,
You may have heard before that BDUF is bad. You probably heard that you should adopt the YAGNI principle. I won’t bore you with a long recap of these topics. However, it seems that every now and then we still bounce the idea over the wire. Uncle Bob just posted a new reminder entitled “Sufficient Design means Damned Good Design“, taking the move from Joshua Kerievsky’s “Sufficient Design” post. Both articles are worth reading, of course.
The message is clear: don’t get stuck in the Ivory Tower. Too much design is bad, because it leads to an inefficient use of our resources. Keep in mind pragmatic parameters such as time-, money-constraints, schedule and the most important business value in mind to keep you from falling into analysis-paralysis and/or infinite-refactoring. You should find a reason to stop in your tracks much sooner than those two extremes. Oh and if I may, we should just call this “Just Enough Design” (JED), because we need a 3LA, and JED sounds cool.
All that being said, I’d like to call your attention to a couple of cautions. I don’t mean to deny or diminish the message you heard till this point, by any means: think of these as the exceptions that confirm the rule, if you will.
- Know Your Audience: we have to be careful in our industry, because -for better and worse- it’s not an isolated adventure: part of our audience is made up of people whose expertise lies in other fields. We can’t survive without them, and we should value these people for all the wealth they bring us. However, we should also be careful because they may read our articles, or hear us talk, and run away with some serious mis-understanding. You say “Big Design Up Front is Evil” and someone may run away thinking “No Design is the Silver Bullet!‘. Don’t blame them: they’re not doing anything wrong. On one hand we have a very ambiguous medium (whatever language you may be speaking), coupled with the undeniable ability of humans to misunderstand, and on the other hand we have different perspectives, contexts and experiences, a cultural barrier that can only amplify the issue. Incidentally, when these people run away with a misunderstanding such as “No Design is the Silver Bullet!” they usually end up in a conference room where they plan the timeline, scope, budget and milestones for the next project: certainly you won’t find a 6-months (or longer) Design phase in it (good), but you won’t even find a 10-minutes buffer for ongoing Design Activities.
- Know Yourself: too much of anything is, by definition, too much. Too much design will therefore be bad and get in your way (or simply make you waste time). However, among other things, Software Design is a way to lay down ground rules and foundation. It allows us to explore possible solutions to the problems at minimal cost. It’s not for free: the more resources (people, time) you put into the Design bin, the more it costs, of course. So it’s fairly easy to calculate its cost, but can we quantify the value added by the Design activities? If you do one extra day of Design in your project, how much more value will be added? As we are very well aware by now, there is an issue of diminishing returns so that the cost of gaining more value out of your Design activities increases exponentially. This tells us intuitively that the first day of Design will be much more valuable than the 100th day (and, within that first day, the first 10 minutes much more valuable than the last 10 minutes). But to quantify the value we must look at the skill level of the people involved. One day we may break out of this analogy between software engineering and civil engineering, but for the time being… design is like drawing the blueprint. The best master carpenters in the world may be able to build my lodge without a blueprint, based solely on their experience. But we have plenty of research showing us that most people are not in the Expert range (take a look at Alan Stevens “Coding in Public” talk for a quick and entertaining summary). Most people are somewhere between Advanced Beginners and Competent. No matter what activity we look at, we find that people in the lower levels of expertise need more rules in place to be effective. So, if I gather a team of carpenters for my lodge, I am very likely to get an average team, which will benefit and probably need a good set of blueprints.
Good friends, I hope my message is clear: be careful of what you do even with the best ideas, since they may not be the best fit for your particular scenario. Make sure to ‘read the manual‘ (through and through, no cheating!) and understand the limitations of these Best Practices and Guidelines before you rush into production with them: running with scissors is dangerous, after all. Also: you must make sure everyone involved understands those limits, or you may find yourself in an Pickle (and no: it won’t be the process’ fault).