DEV Community

Marcell Lipp
Marcell Lipp

Posted on • Originally published at on

Plan before coding (why software design is needed?)


I’m quite often facing with the situation that developers are starting directly with coding when they are getting a new task. Beginners as well as developers with long years experience, even at well-known, famous companies. And to honest it is pretty strange for me, I think it is very unprofessional and risky. Let’s see why?

Advantages of creating software design

I really like the parallelism between building a house and writing a software, because both of them is the result of a complex engineering work. At a house you need to take care about a lot of things: choosing the correct walls, the correct size of rooms the correct roof, correct electricity and water system etc. In case of a complex software you need to pay attention on several things as well: runtime, memory usage, ergonomy, security, scalability, modularity, compatibility etc.

It is physically possible to build a house without a planning phase, but only in simple cases and most likely it will have poor quality, it can collapse anytime. But I have never heard about any bigger building which has been built without planning. And in fact: would you like to live in such a house? I don’t think so.

Then why would you use such a software? Of course it is possible to implement a software without planning, but only in non-complex cases and for sure it will have a poor quality. Simple you won’t be able to take care about all the points without a design.

An other advantage is: during the design phase you can identify a lot of possible problems which can come up in the future. So you can avoid making code which will be never used and you can save a lot of time with that.

The other important point is the life cycle of the software: most of the programmes have multiple versions. That means: someone did something. Later on new needs came into the picture, so new implementation was done, quite often by different developers. Then bugs are appearing in the code, someone needs to fix them urgently. In practise that means if there is no design document and all the developers needs to figure out on their own how it is working and what was the concept of the previous developers they will loose a lot of time, they will repeat the same mistakes what the others already did and they will miss-interpret the concept, so they will follow an other way at the new implementations and after some iterations it will be a big chaos. So the number of bugs will be higher and the duration of fixing each of them is getting higher and higher as well.

That means: at the beginning you are saving some time by missing the design phase, but later you will loose much more time because of the lack of design.

What is the write level of design?

Of course it makes no sense to design every small function and small detail for each simple software. You need to find the write level of design to find the most effective way of working and you need to find the right toolset. And it is always up to the project. The following questions are always important: Is it a team-work or a one man show? Is it a software with long term support? Is the software part of a bigger framework or it is stand alone? Is the functionality safety relevant? Would we like to support multiple running environments? Do we have limited resources? Who will use the software? After answering these questions you can write choose the right method of design. If it is a small one-man project, only for internal usage a paper and a pen can be the right tool. But even in this case, do a design! Think about the architecture and main components, main interfaces, main functionality, corner cases etc. and draw some diagrams, write some notes. Of course if you are preparing a safety critical application for serial production then you need to create a really detailed design with static and dynamic software plan, diagrams, well-formulated requirements, use case analysis etc and you need to use some really proper tools. So this is really up to the situation. As you are getting more experience you can always figure out easier the right level of design. But what I think as the most important points: even in case of a minimal design specify your main components and the main interfaces between them. Assign main responsibilities to you components and describe the interfaces with some sentences. You should describe the main use cases with you own worlds in some sentences as well. I think this is the minimum level of design in case of a team work. And as your software getting more complex your design needs to get more detailed and more formular. You can use tools like UML as well.


So to not loose time with unnecessary rounds you need to create design, but the right level of design is always up to the situation. In the future I plan to write a post about “How is a good software architecture?” But in the meanwhile you can share with us your habits regarding software designs!

Best regards,


Top comments (1)

kspeakman profile image
Kasey Speakman

I agree. Our team gets a lot of value from talking through features before implementing them. Doing this sometimes brings us to the conclusion that we don't really understand the request. Then we have a dialog with the customer to gain more understanding. If we had started coding first, the code would have been thrown away. Or if we had pressed on and finished it without really understanding, the customer's request would be implemented in a way that probably does not solve their underlying problem. It is still wasted work, because the customer will just keep requesting more features to solve the same problem.