This is true. The difference, however, is that software development is often considered to be largely an art centered around managing complexity.

While we're generally OK at doing this in the scope of one piece of software, we suck at doing it in workflow terms, particularly where other humans, inter-organizational dependencies, money and existing systems are involved. What this article is really talking about is shifting the complexity of the varying development and deployment toolchains and processes adopted by each different project and organization away from the developer.

The author cites a fairly simple example from the commercial programming world. The complexities he refers to are version control systems, editors/IDEs, build tools, language selection, database/persistence layer selection, test deployment, bug tracking, release processes.

Let's assume learning basic git, how to use web-based issue trackers and a text editor are reasonably considered non-negotiable, per-programmer overhead. The author still has a fair point that IDEs can be a plague in some sectors (mobile and Java in particular).

He is also correct that build tools are numerous, but what makes them so painful? Doug McIlroy famously stated Keep it simple, make it general, and make it intelligible. Is part of the pain that many of them are language-specific, with zero or poor integration with external (eg. system-wide) software package databases / dependency trees? It seems that, today, every operating system distribution and every programming language running upon them generally has (at least) one half-baked, error-prone, cross-platform package management solution with its own versioning scheme, configuration overhead, network assumptions, poorly implemented caching system and probably a broken use of cryptographic primitives. They're not general.

Database/persistence layer selection is an architectural question that is easy to either delay or perhaps - if extensive performance tuning is certainly expected, or deployment environments will certainly be heterogeneous in their persistence layers - sidestep through a layer of abstraction (CRUD) to facilitate provider abstraction. These paths are considered good practice - Ken Thompson teaches us to Spell creat with an 'e' (ie. premature optimization is a fallacy), Eric S. Raymond restates Prototype before polishing. Get it working before you optimize it. and RFC3439 summarizes most eloquently Optimization considered harmful: In particular, optimization introduces complexity, and as well as introducing tighter coupling between components and layers.

The final points of pain (test deployment, release processes) are essentially process design and infrastructure interaction and management issues. While the author mentions the additional complexity of the cloud, in truth this area has become a point of pain so intense that many projects now write their code and internal test/release processes specifically targeting one infrastructure provider (EC2, docker, etc.). That's not very general either, now is it?

So where is there clear room for improvement? The build tool issues are mostly a convention versus configuration question, which is philosophical and not going away. The process/infrastructure issues do seem to be the main candidates for change, and this does appear to be the focus of the author's call for approaches.

Tesler's Law of Conservation of Complexity: Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it - the user, the application developer, or the platform developer? - Larry Tesler (ca. 1984)

One could take the same view of the development process itself. Well, then... who are we pushing the complexity to? Is it...

(1) a single cloud provider of choice (EC2)?

(2) a platform-specific virtualization wrapper of choice (docker)?

(3) a person or team within the organization who just delegates truth from above (BOFH-style)?

(4) Some lightweight, open source workflow solution that enables us to step beyond the provider/technology lock-in of (1) or (2) and remains painless and configurable enough for mass adoption?

I believe that (1) and (2) do not meet the complexity requirements of larger scale users, and that (3) is not scalable or efficient. I think (3) will exist, but focus more on policy, whereas (4) style solutions will appear in the same vein as the literate, simplistically ops-oriented command line interfaces championed most recently by heroku, vagrant and docker. Regarding (4), if we get it right, we don't even need to notice the implementation. As Minsky said: We're more aware of simple processes that don't work well than of complex ones that work flawlessly..