“How do you design software?”
This is a quote from a talk by Simon Brown. I saw the talk on youtube and I liked a lot, I really recommend watching it (you can find it here). It is a good question and it got me thinking. A lot of questions started popping up in my head. Like… how do you design software?
As developers, we write code on a daily base. We implement features, start new projects, new ideas, drink coffee and write some more code. Every once in a while we meet deadlines and do meetings. We are happy when our code works. We don’t really think much about the how’s and the why’s of our code.
Do we as developers still know all this design stuff? And I am not talking about drawing boxes and arrows on a whiteboard. I am talking about the decision making process. Personally, I don’t think we do. Whenever you ask around about software design, you usually hear the ‘drawing boxes and arrows’ story (like Simon says in his talk) or you hear the same excuses over and over again:
- “I don’t have time for that, we need to go fast!”,
- “It’s only a prototype anyway”,
- “I didn’t think of that”.
Most developers have heard of some design principles. For example the SOLID principles. They either know about the acronym and can name a few of the principles or they have heard of some of the principles in a different context. Every now and then you will find one who can somewhat explain what these principles are about. Rarely you’ ll find somebody who actually understands these concepts, knows what it is really about and who can apply them!
What is software design anyway? Is it drawing boxes and arrows? Nope. Software design is a process. It is the process of defining a software solution for a particular problem. There is a need for automated processing or reporting. And you are going to come up with a software solution to fulfill that need. You need to take into account requirements on what it is supposed to do. Sometimes there are requirements on how it is supposed to be done. Generally we end up with … boxes and arrows on a whiteboard (which is fine! I am not against drawing boxes and arrows on a whiteboard btw. It is great to visualize your plan of action and it really helps explaining it to other people as well).
But is that all? When you start coding your solution, will you put all of your code in one file, one class, one method maybe? Probably not. Why not? And how are you going to split up your code and why? Many developers don’t even know why they write code the way they do. You see, software design is also thinking about the structure of your code, so that when requirements change or evolve, the next developer will not curse you to the depths of hell (oh and by the way, there is a big chance that the next developer working on that code is actually you again!). Designing software is thinking about and understanding the consequences of the code you just wrote. It doesn’t matter if it is brand new code or an extension of an existing codebase.
Why would you need design? Do we still need this? Yes, absolutely! Bad designs cost time and thus money! I am sure that many of us can remember at least one ‘code-change-struggle’ where you only had to look at a line of code to break the application. Coding new stuff is fun. Changing or adding things in an existing codebase not so much. Let’s face it: change is the nemesis of many developers. We don’t like changes into a codebase because it usually means trouble and frustration.
We curse at badly designed code when we need to change something in it, yet we don’t seem to know or to care how to write code that can deal with change. And that is exactly what software design is all about. It is the science of change in code. Both about dealing with change in an existing code as anticipating change when you write new code. Software design is the bundled wisdom of many developers on writing code that can easily be changed, with the lowest amount of frustration and cursing. That is amazing, right?
These days it feels like everything needs to go fast. Features need to be ready yesterday, it doesn’t matter how, as long as it is out there. Along the way, it seems like we forgot why we need software design and more importantly, how to do it. I think that is a bit of shame and I intent to do something about it.