March 1st, 2008
Design documents are such a hurdle. Why couldn’t I just sit at the computer and write the code? Hey, isn’t the software made from code? Shouldn’t the code be the best way to create a concept and test an idea? After all, when you’re done with the planning you’ll have some code ready and you can continue building from there. It’s a time/money saver.
I suppose that such view on a software design process is very common. There are many reasons why programmers think like that:
- Whenever a project has a short deadline, designing is the first thing to fall out of process to save some time.
- Design document can look as overkill when project is developed by only one or two programmers. It’s easy to think that he or they wouldn’t need a design document because they are making the standards themselves.
- Project can be too small to have it’s own design document. What’s to design when project have only three windows and few self documenting functions?
Those reasons are often used to skip designing the project. They are actually good reasons to save time and immediately start coding. Only problem in them is that projects happen to look different when they begin and after some while. What was one guy project in the beginning, soon can be developed by a whole team. Small projects can serve as a base for a larger ones. Without clear standards they can only be base for troubles.
So, what should a hard-working, deadline-pressed programmer do regarding the design document? Only smart thing you can do about this is not to distinguish projects to those which need the design document and those which do not. Rather, for small projects make small design documents. Few pages with goals, ideas and important names and terms are better then no document at all.