I will admit that I don’t have enough natural talent at coding that I can just sit down and code an entire application off the top of my head. So I use UML (and in the past the Booch method) to engineer my applications before I write one line of code. Design has always helped me get most of my issues worked out before I code so that when I’m ready develop, it’s all about execution; rarely do I have to stop to second-guess what I’m doing because I’ve already worked it all out in my head, and more importantly, created a map for myself to help guide my development. This practice is something I just learned on my own after failing so many times. Call me a little anal-retentive about going through this process, but I’ve had nothing but success developing applications in this fashion.

It used to bother me that for the most part, I’d be the only one designing my software before I actually built it. Hell! Everyone around me took their specs or mockups, sat down and churned out code! It used to make me uncomfortable. But it no longer makes me uncomfortable because those very same people are the ones who spend lots of time paying off technical debt. Now I think that if they just invested even a little time working out their design before they code, they wouldn’t have to spend so much time grinding their apps or components into submission. But that’s how it is with most of the software development world.

Getting to the crux of this article, almost every engineer I’ve spoken with regarding the virtues of design agrees that it’s valuable – and I’ve spoken hundreds on this subject. But only a handful have actually adopted the process of designing before you build. That doesn’t hurt my feelings though, because I figure if I can reach just a few, they’ll hopefully teach others. And those of whom I have taken under my wing to teach the process have gone on to be some of the finest software engineers in the industry, and sought after by many companies. The software they produce is bullet-proof, and it all started with design.

Despite the agreement that software design is a valuable step in the development process, overall, I’ve that that agreement ultimately is lip-service. I think many developers see it as a time sink that will take away valuable development time. I can’t tell you how many times I’ve heard something like this: “I have a deadline and can’t take the time to learn this.” But I always contend that if you start simple, the time investment is minimal. For instance, I always instruct people to start with a simple class diagram. That way they can identify the objects they’ll have to build. Doing that one thing can solve so many issues due to not knowing who the actors in your play are. Then, if they’re ambitious they can move into drawing sequence diagrams for the critical object interactions. And for the most part, unless you need use-case or state diagrams, you really only need class and sequence diagrams. In the end, it’s not much of an investment in time.

Admittedly, as with any new thing to learn, velocity will be slower. But as you get better at it, you’ll be faster. And I have found, as have all who have adopted this practice, that not only does design get faster, but development gets faster, and even more importantly, the time spent paying off technical debt is greatly reduced. For instance, I know of a guy who has worked and re-worked the same damn component for 6 months! If he had only taken the time to sit down and work out a design, he could’ve been done in two weeks – maybe even sooner. But he’d release his work, find that it was missing some key features, then rework his code. Talk about wasting time!

I think what shocks a lot developers I speak with is when I tell them the proportion of time I spend on various tasks when I’m developing. I spend about 5% on requirements review, 80% on design, 10% on development, and 5% on debugging and technical debt. Those are fairly loose averages, but I’ve measured these over time. Before I became a practitioner of design, those numbers were more like: 5% on requirements review, 10% on design, 50% on development, and 35% on debugging and paying off technical debt. What’s the implication here? Look at the debugging and technical debt numbers. With a good design, you just don’t make that many mistakes. Most of my bug tickets tend to be cosmetic fixes in nature. I don’t get too many functional error tickets; again, that’s due to having done a thorough design. Also, with the change in proportion, my overall development time, including all the steps has been reduced by 30-40%. What used to take me several days to finish, now only takes me a day or two or even a few hours! But despite sharing those numbers, and people getting fired up about doing design, most simply don’t execute. It’s really a shame.

Eventually people will learn. But in the meantime, there’s going to be a lot of crappy code out there…