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.
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.
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.
It’s not the estimate that is valuable. It’s the estimating and seeing how/why the estimate changes over time that is valuable.
Estimate changes over time: surfaces underlying issues e.g. too many urgent bugs/fires/triage, product changing priority constantly, etc...
readthenotes1•6mo ago
the_arun•6mo ago
papichulo2023•6mo ago
makeitdouble•6mo ago
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...