Why does it take so long to build software? (2020)

Maybe because successful companies in tech got rich so quick that their leaders never learned how to code properly. None of the developers who work for big successful companies know how to code efficiently. Initially, they were hacking together all the code as quickly as possible (of course that didn't scale and had to be rewritten completely) and then they later got enough money to just brute-force development by throwing hundreds of developers at it.

Then they started pushing their naive ideas to everyone else (e.g. static typing, functional programming, 100% unit test coverage, Elixir...) and they put 0 focus on stuff that really matters such as keeping method parameters and return values as simple as possible, consuming events using for-await loops instead of event listener callbacks, naming variables well, separation of concerns, etc...

So now most of the industry knows two kinds of code: Dirty hacks or bureaucratic bloatware. Nobody knows how to code properly. There is nobody around to teach people the correct approach and there are a lot of people around to teach the incorrect approach.

I fundamentally disagree with the conclusions of this article.

It doesn't take long to "build software" - git was built in a weekend, Facebook a similar timeline. When the environment is right there's no upper bound on the pace of delivery, it's just that modern day dev is, in many places, less about quality of the output (in terms of product/market fit and user value, not code quality) and more about the satisfaction of ceremony. You couldn't product manage Google into existence, or any truly valuable piece of software, hardware, or any other innovation, but it's customary for organisations to create structures which feel grown-up in order to yield software.

The talents now required to enter the field are also different, which has naturally played a part in the perceived slow-down. Development is a new field, and research into what makes teams effective is limited - we're still using the ideas of industrial steel production to try and bolster the present manufacturing line. This means there are plenty of undesirable behaviours.

But ultimately, it's about what you're optimising for. If you hire outstanding people and give them an excellent brief, you can deliver incredible software at pace. Most modern companies don't optimise for this, it's more about satisfying sprawling teams, polishing egos, and chasing incremental gains. In that environment you can bet delivery is slow.

I kind of have the exact opposite in term of feelings.

Seeing Windows 95 or 98 going into a BSoD was far more common than today with Windows 10.

I also remember seeing Netscape crashing extremely frequently toward the end of the first browser war.

By comparison, today, a modern browser is doing a lot more things, but very rarely crashes in my experience.

Overall, in term of software quality, I think things have improved, specially thanks to:

* the maturing of tools like compilers, dependency managers, linters, unit tests frameworks, etc.

* the widespread adoption of development technics ensuring better quality (CI, unit tests, code coverage, automated integration tests, etc).

* the development of common building blocks such as libraries and frameworks, which enabled projects to not "re-invent the wheel" every time for low level stuff. These building blocks also being generally widely used, battle tested and more reliable than in house implementations.

* the development of OSS which drastically increase the accessibility of the previously mentioned building blocks to developers.

Both technically and methodologically, software development has seen tons of improvements since the late 90ies, early 2000.

Eh pointless gripe but if this is a blog/article should omit that intercom widget or whatever on that page.

I think focusing on this comparison to the real world assemblies and constructions doesn't yield much insight. The equivalent of a car being assembled is a compiler building an executable from source. You can consider factories to be just very, very long compiles, and forget about it.

The question of why software takes a long time to build pertains to the coding phase, to which real life's analogue is drafting/design phase. It is my impression that the drafting/design phase in "hard" industries can be just as messy and hard to schedule as software development is - we just don't pay attention, because for physical products, drafting/design is nearly free (capex & opex of the assembly phase dominates), whereas in software, the construction is nearly free (compiler time is too cheap to meter).

It's true that, on the surface, software is "always new". But after doing it for a while, I have this sinking feeling that a lot of it is old and repetitive work that we hadn't yet automated - there are deep similarities between pieces of code we're writing, but we don't have a language to fully capture them and abstract them away.