Erik McClure

The Standards Problem

When people leave the software industry citing all the horrors of programming, it confuses me when they blame software development itself as the cause of the problems. Programming is very similar to architecture - both an art and a science. The comparison, however, falls apart when you complain about architecture and buildings having all these well-established best practices. The art of making buildings hasn't really changed all that much in the past 50 years. Programming didn't exist 50 years ago.

The fact is, we've been building buildings for thousands of years. We've been writing programs for around 40, and in that period we have gone from computers the size of rooms to computers the size of watches. The instant we establish any sort of good practice, it's bulldozed by new technology. Many modern functional programming languages had to be updated to elegantly handle concurrency at all, and we've only just barely established the concept of worker threads for efficiently utilizing 4-8 cores as we step into the realm of CPU/GPU collision and the advent of massively parallel processing on a large scale, which once again renders standard concepts of programming obsolete. The fact that software runs at all is, quite simply, astonishing. Windows still has old DOS code dating back to the 1980s having repercussions in Windows 7 (You can't name a folder “con” because it was a reserved device name in DOS). If they were to completely rewrite the operating system now, it'll be completely obsolete in 20 years anyway and we'd be complaining about NT's lingering 32-bit compatibility issues and old functions not being threadsafe on a 128 core processor and problems I can't even predict.

Standards can't exist if we can't agree on the right way to do things, and in software development, we can't agree on the right way to do things because nobody knows (and if someone tells you they know, they're lying). Just as we all begin to start settling down on good practices, new technology changes the rules again. This further complicates things because we often forget exactly which parts of the technology are changing. There's a reason you write a kernel in C and not F#. Our processor architecture is the same fundamental concept it was almost 30 years ago. Ideally we would have moved away from complex instruction sets now that nobody uses them anymore, but we haven't even done that. Language fanboys forget this and insist that everything should be written in whatever their favorite language is, without having any idea what they're talking about. This results in a giant mess, with literally everyone telling everyone else they're doing it wrong.

That's the software industry today. It's where everyone says everyone else is wrong, because we have no goddamn idea what software development should be, because what software development should be keeps changing, and its changing so rapidly we can barely keep up, let alone actually settle on a bunch of standards. Instead, individual groups standardize themselves and you get a bunch of competing ecosystems each insisting they are right, without observing that they are all right at the same time - each standard is built to match the demands of not only where, but when it is being used.

Luckily, I don't program because I want to write programs all day. I program because I want to build something magnificent. If you make a living programming for a bunch of clients that try to tell you what to do and always say it should be faster and cheaper, well, welcome to being an artist.



programming didn't exit 50 years ago? ignoring everything about automatas are we?

Erik McClure

Programming in the sense of modern software development did not. The mathematical foundations were there, but we had no idea how to practically apply them.

Jon D

Scotts article that you linked to is confusing manufacturing with design. See

Also, the mutability of the software engineering field is an inherent extension of the mutability of software. As we create new things and tweak existing ones we develop new languages, APIs, and practices to suit the needs of whatever is being built. Since there will always be some new need brought on by a customer request or business requirement there will always be a new "thing" brought into the field.

Chris Aitchison makes a good point that software engineering is not like any other form of engineering:
and I completely agree with it. If you show me a blueprint for a building and say "this is what it will look like forever" I will believe you 99% of the time. If you show me a software design and tell me "this application will always function this way and never change" I will walk away laughing.

Jon D

...I guess my point is that the changing state of software engineering and lack of standards is less because software engineering is immature and more because continual change is an integral part of the software engineering field.

Erik McClure

Continual change IS an integral part of the software field, be we can't know if this, itself, is what's making it impossible to standardize because the field is so immature.


When it comes to the user-facing side of software, we are developing some building criteria:

Erik McClure

The web seems to do a fairly good job of standardizing things. The problem is that those standards have often been completely ignored.



  1. 2021
  2. 2020
  3. 2019
  4. 2018
  5. 2017
  6. 2016
  7. 2015
  8. 2014
  9. 2013
  10. 2012
  11. 2011
  12. 2010
  13. 2009