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.
I really feel like you have missed the point here.
I hope I did, but even after reading your comment and the article again multiple times I can't see it.
They are not talking about an engineer creating solutions without considering the code base.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.