[OpenDrapery]

I've been around long enough to see software development methodologies come and go. I worked for GE for a decade, and they tried to force Six Sigma on everyone. Devs put through training. Lean. KanBan. Single piece flow.

The thing that businesses don't want to hear is that software development is a skill game. You win by having better players. You cannot put blind process around every facet of it. I know you'd like to, so that you can then pay very little for unskilled labor. But the fact remains that you cannot, even today.

Wysiwig html editors and drag and drop UI builders for rapid application development were trending for a while in the 90's. Then everyone realized that giving these tools to monkeys resulted in a big pile of poo. So the trend reversed back to hand coding UI layouts using markup, separating business logic from display concerns, etc

I guess what I am trying to say is that if there is any hope in putting a lot of process rigor around software development, it will be enabled by tooling. Until then, skill and experience matter. And they aren't cheap.

Put another way, if the Cleveland Browns stole the New England Patriots playbook, they would still suck.

[narrator]

One interesting thing about software methodology that most people seem to like, such as testing and version control is that it prevents bad coders from screwing up a project too badly.

I also think that languages like Java have become popular in big enterprises filled with lots of coders because the language makes it hard to write difficult to maintain code by doing away with any features that would make it easy to obfuscate the intentions of code. This concern also had a big influence on the design of Go and all the features it left out.

The upshot of these coding methodologies that stood the test of time is that they protect the project from bad coders and they prevent really smart people from writing code that is too clever such that noone else can maintain it.

[lastofus]

Instead the really smart people write abstraction upon abstraction until they can achieve the level of cleverness they wanted in the first place. I'm not sure all that extra code is really that much better.

[engi_nerd]

> One interesting thing about software methodology that most people seem to like, such as testing and version control is that it prevents bad coders from screwing up a project too badly.

Effectively, these methodologies are a kind of bureaucracy. Besides self- propagation, the primary purpose of bureaucracy is to cover for incompetence. So testing and version control are (in part) a way to cover for incompetent coders.