7 ms·

While I agree that under-engineering can be a problem, it's generally very easy to fix by doing what's now clearly identified as missing/needed. Fixing over-eng

by mainde 2y ago

While I agree that under-engineering can be a problem, it's generally very easy to fix by doing what's now clearly identified as missing/needed. Fixing over-engineering is always a nightmare and rarely a success. IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently. Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.

gfairbanks 2y ago
> throw imaginary problems in the mix Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: all of you thinking you can use waterfall to figure it all out up front are deluded. By getting started right away, you make mistakes and you avoid working on non-problems. I can fix the mistakes with refactoring but you can't ever get your time back. Most teams live in his world now. Few do too much up-front design, most suffer from piled up tech debt. I hope you give architecture another chance. Focus on the abstractions themselves [2] and divorce that from the process and team roles [3]. [1] https://news.ycombinator.com/item?id=40616966#40624446 https://news.ycombinator.com/item?id=40616966#40624446 [2] Software Architecture is a Set of Abstractions, George Fairbanks, IEEE Software July 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1OAJv5H4jew https://www.computer.org/csdl/magazine/so/2023/04/10176187/1... [3] JESA section 1.5, https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft... "Job titles, development processes, and engineering artifacts are separable, so it is important to avoid conflating the job title “architect,” the process of architecting a system, and the engineering artifact that is the software architecture."

by mainde 2y ago

gfairbanks 2y ago

> throw imaginary problems in the mix Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: all of you thinking you can use waterfall to figure it all out up front are deluded. By getting started right away, you make mistakes and you avoid working on non-problems. I can fix the mistakes with refactoring but you can't ever get your time back. Most teams live in his world now. Few do too much up-front design, most suffer from piled up tech debt. I hope you give architecture another chance. Focus on the abstractions themselves [2] and divorce that from the process and team roles [3]. [1] https://news.ycombinator.com/item?id=40616966#40624446 https://news.ycombinator.com/item?id=40616966#40624446 [2] Software Architecture is a Set of Abstractions, George Fairbanks, IEEE Software July 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1OAJv5H4jew https://www.computer.org/csdl/magazine/so/2023/04/10176187/1... [3] JESA section 1.5, https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft... "Job titles, development processes, and engineering artifacts are separable, so it is important to avoid conflating the job title “architect,” the process of architecting a system, and the engineering artifact that is the software architecture."