Very few software engineers are working in novel design spaces. Even 1:1000 is probably being generous. FWIW, this is true of conventional engineering too, but even more so.
A software engineer having no idea how to build something doesn’t make it novel, it just indicates inexperience or ignorance in all but a vanishingly small number of cases.
In practical systems, you won’t find much novelty outside the rare frontiers of performance optimization, systems software architecture, the occasional bit of weird silicon with unusual computational properties, and some narrow algorithm domains that have never been adequately developed e.g. compression and AI. Almost no software development can justify even thinking about these types of things and they virtually never do.
Conventional engineering is worse because the laws of physics constrain almost everything to boring well-explored solutions. In some cases, we’ve pretty much done exhaustive exploration of what is possible.
> The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5
Google has something 25,000 developers. You think Google has 5,000 people working on novel design spaces? That number sound way, way too high. By at least an order of magnitude.
And Google at least has customer facing technology compared to the thousands of companies whose developers only work is, say, integrating HR systems or deploying SAP or maintaining some legacy billing system.
> You think Google has 5,000 people working on novel design spaces?
Yes.
Maintaining a bridge is in general not novel. There are clearly established best practices that have stood the test of time.
Maintaining a ridiculous tangle of millions of lines of code is novel. There are no best practices on par with other engineering fields. We are at the stage of rough heuristics in most parts of software dev.
One day there will be broad and consistent over time agreement on how to handle large software projects. But we aren't there yet.
Novelty is a byproduct of immaturity. To take another field that matured recently, mechanical and in particular aerospace. You can see a lot of crazy airplane designs from the 1920s through the 1940s. There was a lot of novelty back then and it was an exciting field to work in. Now airplane designs look very standard, and for good reason. The field matured and figured out the best and most economical designs. Novelty is a temporary state, and most novel designs are figuring out how not to do things.
> would have both required Ukraine to almost entirely disarm and also allow Russia to veto any future military partnerships Ukraine might have including non-NATO ones.
Ukraine now faces almost total destruction because they didn't take the deal.
It should be a clear lesson to other countries - don't be belligerent with your much stronger neighbors.
The US and Europe getting involved simply increased the death and destruction.
I'm not saying it is fair or right or just. It simply is.
That's a great point as well. "They've been doing it to us for decades, what's happening now isn't any worse".
The Project 2025 document is really interesting along those lines as well. It's close to 1000 pages, but you can skim pretty much any section that isn't about the military and get the idea. Politicizing the executive branch is an explicitly stated goal, over and over. And furthermore, the push to disband the department of education is specifically an overly political, not because it's ineffective in its mission, but because it's "a one-stop shop for the woke education cartel" -- and yes that is a direct quote.
> Is that just how CRM systems are? Is everybody just doing it wrong? What's the deal?
These kinds of tools cover 80% of what you want to do out-of-the-box.
For the remaining 20% to build it correctly you need to either hire expensive consultants or hire in-house staff to build.
Nobody budgets properly for this, and it isn't in the sales pitch, and so that last 20% is built as horrible spaghetti code by the cheapest possible devs / consultants.
Even if you wanted to pay good salaries and hire people in-house how many great engineers want to be limited to programming in Apex on salesforce?
In my experience, while there are some things in the backlogs that a developer can basically pick up and run with, others require input from other roles to actually address or implement properly. And then once developed, you need to test, document, and localize a feature. (Realistically, you probably want to market it as well.) Depending on your design and support model, your customer service teams may need to help organizations implement the feature effectively or may need to be trained on how to answer customer questions about that feature.
> I just don't seem to struggle, as others claim to, in measuring productivity.
Because you are measuring at a very broad and basic level.
Steve is more productive than Susan.
Great. How much more productive? Can you turn it into a number?
Can you still do it consistently when Steve and Susan are in different teams in different parts of the organisation trying to achieve different goals?
I've done DB upgrades that took 10 minutes and I've done DB upgrades that took 3-4 months. What changed was not my productivity but the nature of the problem. Yet from the outside they were both just DB upgrades.
If Susan had done the DB upgrade in 12 weeks could we confidently claim that Steve could have done it in 11 weeks? Steve hasn't even done a DB upgrade since he joined the company. Perhaps Steve could have done it in 10 minutes?
I don't think anyone can get numbers, but partial ordering is much easier.
If Steve and Susan are in different part of organization, the answer is "cannot compare". If they are doing different job, the answer is the same.
But every once in a while there is a scenarios when you can compare people easily.
There has a weekly rotation to be an support person for other team. During his week, John always answers questions quickly and to the team's satisfaction. Meanwhile James struggles to answer them and cannot troubleshoot product his team is writing. This has been going on for multiple months and hundreds of questions for each, so it's not "bad week" unlucky or fluke. We now know who is better at answering questions about product.
John and James are doing DB migrations, they did many dozens of them. The migrations are assigned randomly. But John is usually finishing his migrations with no problems, while James often caused outages or missing data. A few times James took over two months to migrate, so the task was taken from him and given to John. John had to discard everything James did and migrate everything from scratch. Now there is a migration for a very important client and CEO is fed up with random assignment.. who is he going to choose?
What your scenario doesn't address is that while John finished his migrations on time, James has designed the flagship order processing pipeline something that John could never pull off.
Or maybe while John is technically adept, he's also a huge jerk and belittles people at standup, while James is the quintessential communicator with jr devs, etc.
Real life is messy. I've seen more people get replaced due to attitude or teamfit issues than specifically due to technical incompetence.
Your first scenario: possible, but quite unlikely. If James cannot even perform migrations without causing outages or dropping data, the chances are that "flagship order processing pipeline" he made is similarly bad, and even if it works, it's likely has outages and missing data. I've never seen a developer who can only do hard tasks but is genuinely bad at simple tasks (They may refuse to do those, but if they start on them they'll do them well.)
Your second scenario is unfortunately very likely, people are jerks, and if they are also high performers (or high bullshitters) then can get away with it.
Either way I fully agree one one should be firing/promoting people based on a single metric, even if that metric is very relevant to the job description. That doesn't mean that "there is no such thing", or that if you really need to get that DB migration done, you want to choose a "quintessential communicator with jr devs".
> Great. How much more productive? Can you turn it into a number?
This is moving goalposts. OP's argument was "There's No Such Thing as Software Productivity", not "You Can't Convert Software Productivity into a Floating Point Number With 3 Decimals of Accuracy."
By that measure there also isn't a real dependable/reproducible scalar that measures athleticism. Nonetheless some people are clearly more athletic than others. Also within a single sport we can easily see that some players are better than others. Here too you could object that people who play offense should not be compared to players in defense. Or that it's not individual players that matters but the team as a whole. And yet, we can still figure out easily who the star players are.
Then I shall move the goalposts. Can you address my shifted goalpost?
I personally did not interpret the author as literally meaning there is no such thing as software productivity but I agree the way he wrote it was confusing and could be interpreted that way.
Even in his toy example he clearly stated Peter did a better job than Frank.
"What changed was not my productivity but the nature of the problem"
I think that's the source of the problem: it's impossible to measure the "work" required to solve most software problems. If you tell me to carry a stone up a hill, I can put that in a formula and know exactly how much work I'll have to do. But if you give me a ticket to do a DB upgrade, I can, at best, make an educated guess.
So by the time I close the ticket, how much work have I done, and how do I know whether the time I've spent it proportional to the work I've done?
> Don't you think that giving up after n=1 attempts at measuring software productivity might be a tad too fast to draw a generalized claim of impossibility?
Software developers should look at anyone claiming they can measure software productivity as a snake oil salesman.
We have seen hundreds of attempts over the years and they have all "failed". More accurately they all have large error bars and biases.
Researchers can and should continue looking into how to measure software development productivity. It is likely over the next few decades we will start to understand how to measure it appropriately.
Software is much closer to a competitive race where small improvements in ability give completely outsized returns.