iToto's Blog

A Montreal based full-stack web developer who loves learning and trying out new things. This blog is my attempt to document my work as well as a place to discuss ideas or topics that I find interesting. Feel free to follow me on linked social networks.

Take time to design

Software design; some developers take it for granted. In my experience, desiging your software before you implement it is one of the most important and helpful things you can do.

A problem well stated is a problem half-solved.
— Charles Kettering

I've been recently listening to an audio podcast called DeveloperTea by Jonathan Cutrell, I suggest you give it a go if you haven't already. It was he who introduced me to the quote above. In one of his recent episodes he touches on how to go about solving a problem. He states that in order to get a solution, you must first have a proper understanding of the problem. Then, you can begin to design how you plan on solving that problem. Well Jonathan, I couldn't agree more.

Photo by Krzysztof Zmij/iStock / Getty Images

Taking the time to understand a problem and design a proper solution is the best first thing you can do. During this process, you are essentially defining your program's logic and requirements. This will help you – and any other developer – a great deal when having to develop or use the software. It serves as a map, illustrating a high level picture of how your software works. Also, by exposing a design document before implementation, you will uncover any errors or mis-conceptions that you would have otherwise found during your implementation. Which would cost you more down the line. Finally, it will double as documentation for your software when you are done.

If you are one of those people that prefers to code before making some sort of design documentation, I want you to think back to how many times you had to re-do your implementation because your solution didn't fit the problem. You'd be surprised at how much lower that number would be if you had done a valid design prior to coding.

How Much is too much?

As important as designing is, it's also important not to spend too much time on it. There are certain things that you won't know at the time of designing. Therefore waiting to think of all the problems you might encounter can be a waste of time. At one point, you have to just take what you have and know and build it.

Here is my guideline for knowing when I'm done designing:

  • Does my design answer the problem/requirement?
  • Do I have enough modelled so that I know which objects, methods, data structures, etc. I need to create?
  • Do I know how these things relate?
  • Can someone new read over this and know how to implement it?

If the answer to each of those is a firm Yes, then it's safe to say that you can start your implementation. Now, this is not to say that there won't be any changes or refactors that may come up down the line. Requirements can change at any given time – especially if you're Agile. Which is all the more reason why you shouldn't spend too much time designing something that might end up changing next week. Once you have enough scoped out and written down, start the building phase. Otherwise you risk staying in the desinging phase forever and ever. And ever.