Measuring Engineering

The point about task variability being normal, and attempts to reduce variability being destructive, is explained exceptionally well in "The Principles of Product Development Flow." Metrics folks want software engineering to have units of work so that it can be measured like an assembly line, or sales, or any other number of things that make sense to quantify. But the reality is that we build and make adjustments to interconnected systems, and that just can't be reduced to arbitrary units. Tasks are heterogeneous and work on different scales. When you try to cram them all into the same sized box, you are actually creating friction and making the problem worse.

“Plans are worthless, but planning is everything.”

It’s not the estimate that is valuable. It’s the estimating and seeing how/why the estimate changes over time that is valuable.

I get that a lot of us are attached to the job title “software engineer” (I prefer programmer, but whatever). However, this case is particularly egregious; in the very least the blog post title should mention that it is talking about software engineering (and not engineering in general).

Software is tricky because a software engineer is actually an architect, an engineer and a builder at the same time. Also, they're working on top of other people's work; often many other people's works. The constraints aren't fixed as they would be if doing engineering work for a building when you know the shape of the building and you know the range of tools and materials you have to work with, etc... With software, the shape of the system is changing and the tools and materials are changing, oftentimes, the foundation is being changed from under you. This poses unique challenges.

Personally, I think it was a mistake for many companies to try to turn software engineers into replaceable cogs in the machine instead of giving them managerial/ownership responsibilities. It kind of created this self-fulfilling dynamic where developers felt replaceable and not responsible; so they changed projects and companies at the drop of a hat whenever the complexity got out of hand. Everyone just piled complexity on top then dumped it on the next person who was even smarter (or more motivated) than the previous person and could stretch the complexity even further, creating more bugs and vulnerabilities.

I kind of understand why many big companies focused on raw puzzle-solving ability when hiring software engineers. As the mess became increasingly complex and people kept piling as much complexity as they could possibly handle before bailing out, companies needed to keep finding more people, increasingly skilled puzzle-solvers, who were able to work with the increasingly complex mess.

I think this happened because most companies basically got rid of the software architect role. Management just got used to having to recruit increasingly intelligent puzzle-solvers and tasks taking increasingly more time to complete. Nobody was being paid to ensure that the architecture would be fit-for-purpose, everybody got paid to add complexity to create as much lock-in factor for themselves as possible within the company.

I speak from experience because the last project I worked on was a 10 year old project which was built by a team of like 10 developers and after layoffs, it was reduced to just 2 developers (and I was a newcomer who had to learn everything). The complexity of the system was insane considering the relatively basic functionality... Just to run any code to debug, you had to launch 6 services in Docker inside VMs on Windows and they had to be launched in a specific order and there were all these config issues that would come up for each service. Every single feature or fix required updates to 3 to 5 different repos which had to be deployed to UAT and the two environments were sufficiently different that every single change or feature which "worked on my machine" almost never worked on UAT the first time... Always for a different reason. The deployment process itself was very complicated and not fully automated... I stayed there for almost a whole year but every day involved a lot of suffering.

The only thing which made this project bearable was that my colleague and I would chuckle between ourselves whenever we saw something that was unnecessarily complex to a ridiculous (amusing) extent; we would just chuckle while describing the many complex nested, intertwined layers of the problem or solution. I think the unspoken underlying theme of the joke was "Good thing we are paid by the hour. Good thing we're the only two people in the universe who understand this particular complexity."

IMO, the 10x developer is one who excels as an architect. Architecture is where the 10x or even 100x gains can come from. You can't have a 10x developer working on a poorly architected project. If you put a 10x developer on a project with a horrible code base, they might actually appear to be a 0.5x developer because they are not able to apply their architectural skills to their work and they are demoralized by what they see and the counter-productive constraints which are imposed on them as a result of poor design.

I wonder how civil engineers feel about OP's generalizations