Software design and coding are related, but they are not the same thing.
People (including programmers) like to think that programming is binary, there’s a right way and a wrong way, good or bad.
But in reality it’s all very subjective.
There’s usually a dozen ways to solve a problem, and that’s where design of the code comes into play.
GUI is of course literal design, but code is designed too.
The software designer will usually not write a single line of code. Just like a graphic designer does not usually write the website they have designed.
A software designer will look at the requirements. They will set up a functional specification so that they know what technologies they will be working with where. They will layout the data architecture and information flow. They will define the functionalities of the software. They will basically “draw” an image of the software that is to be developed from a high level perspective.
This is then handed to a team of programmers to actually write the code and make it happen.
Ideally you want a software designer who has coded and is experienced in data architecture and work flows. They need to be logical and have an understanding of the technologies that are to be used.
for further reading consider this article
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.