I feel as if a lot of multipliers have happened that he didn't anticipate, but I also feel as if the culture of software engineering has kind of decomposed, since his day.
We seem to be getting a lot of fairly badly-done work out the door, very quickly, these days.
- agile and devops both conspire to treat developers as replaceable standins
- we're not even really expected to hang around and see the consequences of our decisions
- on arriving in a new organization, we're presented with a heap of trash we're asked to just sort of keep it running, certainly not to fix it
- 'industry standard best practices' win over a well designed bespoke solution every time, developers are just expected to write a little glue at most
- managers aren't expected to know anything about the domain at all, but to track people to make sure they did what they said they were going to
- speed to feature is the only metric. instability can be papered over with bodies
- we pretty much stopped systemic testing a couple decades ago
I was there for almost 27 years, so had plenty of time to deal with the consequences of my decisions.
They were insane about Quality, so testing has always been a big part of my work, and still is, though I haven't been at that company for eight years.
There is a lot of irony in that since the first plank of the agile manifesto is to put individuals in interactions first.
And I noticed you put the development process/structure first over the people who want to treat people as fungible.
Sometimes for good reason. "Well designed bespoke solutions" often turn out to be badly designed reinventions of the wheel. Industry standard best practices sometimes prevent problems that you yet know you will run into.
And sometimes they just are massively overdesigned overkill. There is a real art to knowing which is which.
Absolutely, but that “art” is really important, and also, fairly rare.
Many folks just jam in any dependency that is a first hit in a search, with more than 50 GH stars, and a shiny Web site.
One “red flag” phrase that I’ve learned is “That’s a solved problem!”. When I hear that, I know I should be skeptical of the prescribed “solution.”
That said, there’s stuff that definitely should be delegated to better-qualified folks. One example, that I was just working on[0], is Webauthn stuff.
I always liked the Manifesto, but it's really rather vague, and we engineers don't do "vague" so well, which leaves a lot of room for interpretation.
And authors.
And consultants.
And conference speakers.
Those are the ones that form what is eventually implemented. I'm not really sure any of the original signatories ever rolled up their sleeves, and worked to realize their vision.
It's my experience, that this is where the wheels start to come off the grand ideas.
That's one thing that I have to hand to Grady Booch. He came up with the idea, wrote it down, and then started to actually make tools to make it happen. Not sure if they really launched, but he did work to make his ideas into reality.
Such as? I think his essay still stands the time that no single multiplier is even close to an order of magnitude productivity boost, with the exception of already existing code.
LLMs are possibly the biggest change to how software is developed, but they are also nowhere near this magnitude - if any - in case of more complicated software.
I know that OOP was just getting its feet under it, when he wrote that. It turned out to have a huge multiplying effect on productivity, but also introduced a whole new universe of footguns.
Maybe if OOP had been introduced, along with some of the disciplines that evolved, it might have been a big multiplier, but that took time.
I guess, upon reflection, each of our big “productivity boosts” were really evolutionary movements, that took time to evolve.
He really was quite prescient.
In retrospect, I am highly sceptical that OOP has had any positive impact on productivity. Its popularity coincided with the advent of automatic memory management, the World Wide Web and relational databases, and later with dependency management tools such as Maven. It is much more likely that it is these factors that have improved productivity, rather than OOP.
I’ve been coding since we used flint knives, and can tell you, from personal experience, that it did.
However, when it was introduced, it was done so, with some of the most outrageous claptrap I’ve ever heard. It came out of the starting gate, hobbled.
Those of us grizzled vets, with hype-scars, ignored that shit, and did pretty well.