The #1 Sign of a faulty architecture - Uncle Bob

#softwarearchitecture #softwarearchitect #cleanarchitecture #softwaredevelopement #unclebob #robertmartin #softwaredevelopmenttips
In this video, Robert C. Martin (Uncle Bob) the author of the books Clean code and Clean Architecture speaks on the #1 sign of a bad/faulty architecture. Thoughts?
Sources:
• Clean Code - Uncle Bob...

[@davidwuhrer6704]

It's not just software. There is an old film about a couple building a house. The wife casually mentions that stone slabs she saw would make a nice kitchen floor. So the builders tear down the first floor to reinforce the load bearing base to be able to support the weight of the new kitchen floor. Then she wonders how such a small cosmetic change could be so expensive.

[@EdKolis]

Maybe instead of struggling to fit new pieces into a "completed" puzzle, we should build puzzles that are intended to be incomplete so that they can be expanded upon later.

[@LeeHawkinsPhoto]

You cannot anticipate every single possible change or expansion in the puzzle. There are always going to be decisions made to simplify the architecture because it would be expensive and wasteful to model business processes beyond a certain point, and perhaps even with no benefit…until a change is requested that makes the additional modeling necessary. This is where small changes can have large ripple effects. It helps to keep the pieces simple and square to minimize interdependence, but it’s not always possible or feasible to design that way in every circumstance.

[@TheMindverse]

It's annoying how this guys speaks entirely in metaphor, never quite getting to how "keep all your edges square" translates into Real Life. Also, I can't tell you how many times I gave Stakeholders What They Asked For, instead of What They Wanted. And half the time they don't even know *what* they want. Try "architecting" for *that*.

[@KulaGGin]

It's not annoying. And he doesn't. You're just not listening. Or watching those small clips. This clip is a part of 1-hour talk. He has 2 books: Clean Code and Clean Architecture. He goes in very big detail on exactly how to write things with UML diagrams for a little bit higher view and class code examples for lower level view. Then he also has a site cleancoders where he has videos where shows in real time how he does things. There is like 200 hours of highly loaded with content videos.

[@anonymous49125]

or... we should demand that stakeholders actually plan what they want, and prototype the things they don't know if they need. Instead you turn everything into squares by lobbing off knubs, which takes time and effort, and rarely actually mitigates any of the changes chosen by people that are not programmers and not even competent people wishing to spend the time and effort to actually 'think' and 'plan' what the final product should in fact be at the start.... your puzzle pieces can be perfectly square, but if the picture of the end result of that puzzle changes, then you're pieces need to be thrown right in the trash and all the efforts making them were a waste of money and time. If you just want to collect a check, without constantly being at odds with the stakeholders, then agile and scrum makes sense... you offload the burden onto the stakeholders and let them play all day with cards which hopefully teach them the value of a story point... however, it's likely the worst way to actually ship good software, as it creates unperformant, overengineered, slop that is confused and not fit for its specific use, but only fit for being swapped out with some other code at a drop of the hat... code that again is unperformant, overengineered, slop not fit for its specific use.

[@EdKolis]

It's unrealistic to expect stakeholders to be architects, though. They know what they need, but they don't know how to build it. That's our job.

[@anonymous49125]

@@EdKolis I feel where you are coming from on that, but even uncle bob says it best when he says "Businesses don't know what they want, they only know what they don't like" said in context as a justification for the need for scrum and agile and making software able to be changed 'easily' (I can try to find that quote if you want)... the trouble is those stakeholders don't know what they want the final product to look like, but if they did, then I would agree with you and they don't need to know 'how' to build it and build it well, as the skilled specialists can do all the heavy lifting and make something great and quickly exactly to their wants and needs. The realities though are they don't have a clue what they want, they want you to build some vague thing generally in the shape of what they want, then they change their minds constantly about what they said they wanted before and now want something different and the process repeats.... which making everything 'change tolerant' is the best way to survive in such a backwards and confused manufacturing process. I think that stakeholders shouldn't pretend to be architects... but that's what we allow them to do, because the best way to not get yelled at is to just distract them with playing with cards all day and allow them to speak vaguely about what they want to see, and just try and not think ahead and just build one sprint at a time... everyone gets paid at the end of the day so that's nice at least... but I have doubts it makes for the best software. Or to put it another way, when I develop software for myself... I go in knowing fully what the end result needs to be... if I don't, I prototype until I know what it needs to be and only then do I build it fully to that expectation... any time I just 'make it up as I go' with constant changes, that's usually when I get into trouble and the project never gets done and isn't even that good by the end of it. I also work in games, so this is the road to take to development hell - been there a handful of times, not a fun place to be.

[@factorfitness3713]

If the world was a static place, that would work great. But the nature of a business changes, as well as operational models, goals and KPIs. Can you predict the future? Yeah, neither can the business.