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.
The industry is convinced that the way forward is that everyone should be a manager / architect, and direct a gaggle of pattern matching machines that assemble a pastiche of previously written code. Because it’s faster to do that than to actually do the work yourself. I’m sure it is, but we’ve ceased to learn anything new, or even try anything new. It might seem new to you, but none of it is - not even accidentally. And even on a personal level you’ve learned nothing except summoning rituals
I’m channeling Miyazaki here in that I find this approach to be an insult to life itself, or at least to everything we used to value as an industry. It offends me on a visceral level such that I find it hard to understand people who don’t see it.
Iker@sinbad I think it's in part the natural endpoint for the "Everyone should learn to code" moment. Programming became the career shortcut to "success" and money, not a discipline and craft that people who were particularly interested in the problem space chose consciously. Inevitably, what you have is a lot of mediocre programmers who get excited at the thought of being able to close Jira tickets faster, even if the underlying quality is shit. And management is ecstatic that they get to point at how much more "work" is being done, even if they end up eating shit in the long term. Rarely has management been interested in training/retraining/teaching employees, so investigating the possibility of using tech that DOES remove a lot of the busy work from traditional tech stacks gets turned down. To say nothing about inefficiencies incurred due to bad management in general (but of course, if the disinterested mediocre programmer goes on to become the manager, what else should we expect?)
poetaster
ghosttie@sinbad I didn't think it's actually faster if you're checking every line and getting it to fix every mistake it makes, so you only get the speed benefits if you lower the quality and maintainability
@ghosttie oh they’re definitely lowering quality and maintainability, that’s been immediately jettisoned
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
@sinbad smart.
I understand why management wants architects. They don’t think about the small details that will break. So they do not start asking the difficult questions during meetings.
I have an engineering mindsets. And I have been on investor and board meetings. This does not mix well, especially when they came up with “brilliant” strategies and I had to ask a few simple questions. They don’t like that. Solving problems is not positive enough.
Happy to be writing code again.
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.
@sinbad yeah, "spec driven agentic engineering" is basically a return to the 1970s when waterfall and separating architecure and implementation was all the rage. The Wheel of Reincarnation keeps turning.
It's a nice honeytrap for architecture astronauts though ;)
@sinbad also "I don't even look at the code" is the new "I don't even use a debugger" ;)
Stefan Reinalter@molecularmusing @sinbad credit goes to @TomF, IIRC I had read the term "architecture astronaut" in one of his older blog posts
Bartosz Taudul@floooh @TomF I believe it originally comes from https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
Michael Eggers 🇺🇦🇪🇺
Tom Forsyth
Craig P@sinbad it's been disappointing to watch an industry that was chasing quality and skill 180 into an industry completely uninterested in quality and skill.
Nerds are so fuckin' gullible.
@Craigp @sinbad I'm not gullible. I don't find LLMs that useful (I'm a better programmer) but they sometimes have a use. I recently couldn't find a DIV in a minimized document even after unrolling it. A local model found it. It was not doing coding, just the job I couldn't accomplish with grep. I like grep. I use regexps a lot.
@poetaster @Craigp I can possibly see a use for purely local models as validators or supplementary tooling - but they’re not as good as deterministic linters, or intentionally written scripts, because they can just be entirely wrong because randomness (by design). I hate non-determinism in my tech, the whole point of it is to be predictable and repeatable
Torbjörn Norinder@sinbad it’s also telling of the skill level of those who make compiler comparisons. I look at compiler output *all the time* to understand performance and catch bugs. Different representations are complimentary, not replacements.