Measuring Engineering

https://fffej.substack.com/p/measuring-engineering

by mooreds • 12 months ago

37 13 12 months ago

fffej.substack.com

https://arxiv.org/abs/2503.05040

readthenotes1• 12 months ago

I wonder how civil engineers feel about OP's generalizations

the_arun• 12 months ago

Civil engineers build something "concrete". Right? There is no concrete stuff in software engineering. So everything is left to the imagination of the humans.

papichulo2023• 12 months ago

Not sure how many civil project that takes hundred or thousands of engineers working on independent teams. I think sometimes people ignore and what scale we are building software.

makeitdouble2• 12 months ago

That's relatively common IMO.

Building anything complex, from a car to a factory, would require at least hundreds, usually thousands of engineers.

An example of VW building part of its engineering in China, with 3000 engineers to design new cars:

https://www.nytimes.com/2023/12/12/business/volkswagen-china...

jongjong• 12 months ago

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.

thisoneisreal2• 12 months ago

Great reflections. Like Kent Beck said, "Software is a leverage game."

Stafford Beer would also agree with you by the way. His whole thing is that the computational complexity of any decently sized organization is mathematically overwhelming, and the way to cope with it is via organization (or as you called it, architecture). "Sphaghetti code" is basically what you get when you allow every signal the system produces to become embodied in your code base, which inevitably creates so much noise that it becomes almost impossible to modify efficiently.

makeitdouble2• 12 months ago

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's complicated. Some companies give managerial responsibilities, but that still is a hit or miss strategy.

Your points resonate a lot with my experience as well, though I think most people fundamentaly don't like complexity and want simple answers.

A project costing "3 man/month" is simple. Hiring 2 more people because only 1 engineer is available to that project is simple. You don't need to dive into why this engineer would better fit this project, or how the cost would change depending on the order you do it etc.

Throwing money at hiring or consultants is a lot simpler.

To solve that conundrum, you need someone high enough to both understand the complexity, wrap into simple enough terms for the higher ups, deal with the internal politics to protect the team, and yet enjoy that position well enough to keep doing it day in day out. That's a pretty rare breed IME.

foxbarrington2• 12 months ago

“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.

cassianoleal• 12 months ago

Why?

n4r9• 12 months ago

Yeah, I don't think "seeing how estimates change over time" is very valuable. The reason that "planning is everything" is that it makes a problem tractable.

foxbarrington2• 12 months ago

Estimating: similar to planning, thinking through the whole problem and surfacing early anything that seems like not a big deal on the surface, but actually is.

Estimate changes over time: surfaces underlying issues e.g. too many urgent bugs/fires/triage, product changing priority constantly, etc...

thisoneisreal2• 12 months ago

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.

bee_rider• 12 months ago

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).

Measuring Engineering

Related Stories