The Seven Voyages Of SteveOne of the things I loved about software development was that we were always trying to get better at it, and there was no ceiling in sight for that. Using LLMs to make code is the opposite of that - learning to use them is more akin to learning rituals than it is to intellectual development. And don’t give me that nonsense about it being like using a compiler to move up an abstraction level; it’s not, any more than becoming a manager is coding at another level of abstraction.
I lived through the era in the noughties when the only promotion available outside management was to become a “software architect”. This was supposedly another level of abstraction over development and these experienced developers would level up the whole process by being dedicated architects. And you know what happened if those architects didn’t still actively write code too? Their designs were absolute garbage.
Martin Weber@sinbad no software architecture survives the first contact with code.
The fun thing is that when I was talking to guys at construction sites about the plans they receive from architects, they always needed to “compensate” to be able to actually build the thing.
We saw the same thing when doing architectural visualisation based on 2d plans. And 99% of architectural plans were only 2d.
So it’s not just a software issue.
@martinweber when we renovated our house I deliberately hired an architect who was also an engineer, so he didn’t just do the high level stuff but all the structural/technical engineering detail as well. There were still detail things to resolve but I think it was far more practical
Robert Kist 🇦🇹🇩🇪@sinbad @martinweber at a certain size you NEED an architect. I've seen so many "organic" codebases that were never refactored, but also where nobody had a clue about the big picture. Every engineer just had a view of their own specialized sub-domain, with nobody to effectively coordinate them and plan the systems evolution for 6, 12, 24 months onwards.
Those folk were all very clever people. But the lacked the overview but also sometimes interest for the big picture
@kwramm @sinbad sure, you need to plan for the big picture. It often is more of a social exercise than a technical one.
This also requires constant refactoring to adapt for changing and growing requirements.
It is a hard sell though. Why rewriting code that is not even 3 years old?
With my previous team we improved overall comprehension, reduced build times and increased decoupling to avoid side effects of changes. Delivered major features faster.
Engineering. Not just programming.
Andre Weissflog@kwramm @sinbad @martinweber if a project is so big to require an "architect", the project is too big and needs to be split up. also, the "architecture" is what you get after the project had survived a year in production, anything before that was just "a concept of a plan" ;)
@floooh @kwramm @sinbad yes, the need for an architecture often only arises once you had code in production for a while. Then it is often much clearer what’s needed.
On a whiteboard most things look good. Some of it is either not meeting reality, is not needed, or will just fail.
So I prefer to move fast, see what works, and then quickly refactor. With a clear goal set out first.
The territory is not the map. Better walk some distance through the terrain before using the map to plan.
@floooh @sinbad @martinweber when you do game engines you definitely want an architect. not a 100% UML guy but someone who can guide sustainable, long term development so e.g vfx render codets, water render coders, general render coders, platform specific render devs get properly coordinated. same for other specialized teams. otherwise your engine code is just idiosyncratic spaghetti salad
@kwramm @sinbad @martinweber I've written a couple of game engines since around 1992 (culminating in Nebula Device 1...3), used in a couple of dozen released games, and I stand by my opinion that 'architecture' is what you get after a couple of years of real world usage and several rewrites :)
A dedicated architect is entirely useless for such projects since it's impossible to predict long term requirements (you can plan ahead maybe for 3 months, but anything beyond that is pure guesswork).
@kwramm @sinbad @martinweber FWIW though, I'm not a fan of the extreme specialization that seems to have become common in game development. Ideally, every dev on a game team should be able to work on every feature, and if there are dramatic knowledge gaps the team should try to overcome that problem instead of the 'experts' trying to defend their moats.
Josh Simmons@floooh @kwramm @sinbad @martinweber yeah I think it's a common mistake to try and separate architecture because "architecture" is made up from the small decisions at the leaves rather than from a high level partitioning of the code. Trying to do it "top-down" is nightmare fuel imo.
@dotstdy @floooh @sinbad @martinweber I think you need to meet in the middle. Bottom up often ends up in idiosyncratic, disjointed code on larger projects (think: distributed teams, 30+ people) whereas top down often ignores technical and implementation related things on the ground where the code is written. Both extremes aren’t ideal imho, although I often saw the mess and confusion of the former, cuz game’s ‘ship & forget it’ mindset isn’t great for refactoring (and time pressure too!)
@kwramm @floooh @sinbad @martinweber yeah it's tricky. I do think that if you have a dysfunctional organisation you're basically never going to be able to architect it back into alignment, and I feel like a lot of these issues kind of hark back to organizational dysfunction more than they do to a lack of technical planning, so trying to solve it with more planning is a bit of a fools errand.
@dotstdy @floooh @sinbad @martinweber oh yeah. I met many well meaning people but often it's how production is set up that stops them.
Lack of time, lack of mandate (sorry, that's not your job, can't make a jira for that!), lack of access to people in the know (they're on another team now, they all left), lack of standards/docs (the guy who knew it had it all in his head, sorry no docs), lack of time (sorry, the current project is more important than long term...) all plays into this.
@dotstdy @floooh @sinbad @martinweber generally, I would also say good architecture is less the result of long lonely planning sessions in the ivory tower, rather than building alignment and creating a shared understanding of the code base together: of its requirements (for users, and for fellow devs - i.e. "developer experience") and anticipating risks and potential extension points (Kent Beck in "Tidy First"), and then ensuring this understanding is kept current and evolves with the product.
toerror@kwramm @sinbad @martinweber A lot of organisational, and architectural problems can be resolved by having product pass tickets through the tech lead who can then have architectural oversight, rather than throwing them out direct to the headless chickens.
( Often unpopular due to internal politics, but there it is. Beats adding another lame duck flapping round the periphery after things go wrong. )
( Often unpopular due to internal politics, but there it is. Beats adding another lame duck flapping round the periphery after things go wrong. )
@kwramm @sinbad @martinweber And yea.. Agile is sposed to solve that stuff, and maybe given the right team everyone cooperates and gets things right all the time, but ... A problem that is everyone's responsibility is very often, no one's responsibility. Or at best, down to fortune.