Blueprints for Code

Design is still on my brain, and rightly so, since a lot of consideration needs to be put into it. The word “design” for me conjures images of drawings and art, maybe a slick user interface layout. What does not immediately come to mind is core software code.

Come to think of it, design is featured predominately in all other engineering practices. Civil engineers design roadways and bridges, mechanical engineers design tools and engines, aerospace engineers design airplanes and missiles. You get the picture. None of these professions just say, well I can’t really get to that part of the design, or make that decision until I start building it. Sure, there are prototypes that help finalize the design, but every bit of a prototype is still designed ahead of time. You could even argue that the core of engineering work is design. The building is just that, building, fabricating. It cannot happen with a quality design to work from.

However, in the software industry there are a lot of people that forgo design in favor of “just coding it”. Beginning to build with the plan. Software has the luxury of this being possible, and coding can certainly be the more enjoyable part, since we get to see things come together, however “just coding it” can lead to a whole host of problems down the line. Without being properly designed before keys are mashed into correct syntax, you run the risk of not considering all of the angles, not building all of the correct modules, or having the modules interact in a way that supports the requirements.

This mind-set often results in code that “works”, but only just, and only for a time. More bugs will likely come up, since all the use cases might not have been thought out ahead of time, and there was no plan to follow.

Software can be immensely complex, with many different bits of code from many different places working together to manipulate data in various ways. On even a moderately sized project, having a plan in place is essential, in my mind, to having a consistently successful product produced. Design is the key difference between the mindset of a true “software engineer” and a “coder” or “programmer”. The later can confidently and correctly input code to complete a task. The former can understand the complexities of the system as a whole and how everything works together. They can design and construct a competent, efficient system using the right technology and structure from the get go.

Having no design, or a poorly thought out design leads to mounds of technical debt down the line. Technical debt is something that I could write a whole other blog post about, so we won’t get into that too deeply. But, it is essentially the idea that a poor choice that “just works” and is the quick way to get something done now, can cause issues to come up down the line that are harder to fix later on. These can pile up on each other to make an insurmountable pile of debt that makes maintaining a piece of software incredibly difficult.

So, to wrap up, be an engineer, design your projects! Take the extra time and write it down, draw it out, understand the problem before coding the solution. Then, have someone else look over it, make changes and corrections, then when everything looks good, start coding. You and your project will thank you for it.

Print Friendly, PDF & Email

Leave a comment

Your email address will not be published. Required fields are marked *