Software design and coding are interconnected, but they are not the same. While many people, including programmers, often view programming as binary (right or wrong, good or bad), the reality is much more subjective. There are usually multiple ways to solve a problem, and this is where code design becomes crucial.
Just as GUI design involves visual elements, code also requires careful design. A software designer, much like a graphic designer, typically doesn’t write any code. Instead, they focus on understanding the project requirements and setting up a functional specification that outlines the technologies, data architecture, and information flow. They define the software’s functionalities and create a high-level blueprint of the software to be developed.
This blueprint is then handed over to a team of programmers who write the actual code to bring the design to life. Ideally, a software designer should have coding experience and a solid understanding of data architecture and workflows. They need to be logical and knowledgeable about the technologies being used to ensure the design is practical and implementable.
In summary, effective software development relies on a clear distinction and collaboration between design and coding, with each role contributing its unique expertise to the final product.
Top comments (3)
I created an account just to comment here:
This is not good advise please don't follow this practice!!!
The software design is coupled to the code that exists and the code that needs to be written. Designing software without having contact to the codebase screams ivory tower architecture (oreilly.com/library/view/software-...).
Instead you want the engineer to have an understanding of the overall architecture so that they can make the best decision based on the higher level picture as well as the implementation details.
This article describes a software development methodology that we try to move away from for decades now.
Upfront design as well as throwing requirements over a fence to some one else can only lead to misunderstandings and unmaintainable code.
This practice adds another layer of abstraction between the user and the software engineer, which results in a bad experience for every one involved.
I really feel like you have missed the point here. They are not talking about an engineer creating solutions without considering the code base. They are just describing the importance of the solution architect role and the timing of their input.
Hey Joshua,
Thanks for your reply!
The article does not explicitly call out that the code base should be ignored but the article does literally say that the software designer does not write "a single line of" code. That is in my understanding very detached from the code base.
The article also states that the outcome from that software designer "is then handed to a team of programmers".
This divide between design and implementation has historically lead to many problems down the line. Which is why an upfront design is usually frowned upon in an agile development model and as mentioned above the example describe here sounds a lot like ivory tower architecture.
The whole approach in my understanding is describing an organisational disconnect between the design and the implementation that reminds me of a time before we had devops where application engineers would write their application which "is then handed to a team of" operations people, which is an equally bad disconnect.
If I am misunderstanding this article then for everyone else reading this by all means feel free to ignore my comments.
But I think it would help to update the wording a bit so that other readers don't come to the conclusion (like me) that the article is advocating these outdated practices.