After a hectic month or so, I’m finally getting around to reading.
I’ve been meaning to share this thoughtful piece from Scott Porad, CTO of Cheezburger (squee!), that does an excellent job encapsulating some reasons why software is so difficult.
His main points, or rather, those made by his friend are:
1. Software is entirely hand-made, and compounding this, software is distributed at very large scale. Looking back through history, machine-made goods have always replaced hand-made goods to account for large scale distribution. Software isn’t there, yet.
2. Software production lacks standards. Think about software projects, and you’ll find a variety of methods, e.g. waterfall, agile. However, even within an established method for running a software project, there is variance from team to team, even within the same company.
3. Everyone has an opinion on how long a project should take, an anomaly for producing goods that require high levels of experience and skill from the people doing the work. Project estimation is hard.
Scott’s second point about standards is similar to one that nags me, titles. Software uses titles like engineer and architect, but these jobs don’t require the same levels of certification and training that their namesakes do.
So, while it makes sense to use titles that mirror physical construction, this isn’t really a fair comparison.
I’ve noodled the reasons behind why software is both difficult and misunderstood for years, and this is the best encapsulation I’ve read to date. Even so, I’d add a few other points.
4. Everyone uses software, at home, at work, on the go, and software usually requires substantial learning investment. This tends to make everyone feel like an expert, and it tends to trivialize the effort required to produce this or that small tweak.
This is a scaling problem for producers of software, e.g. every time Facebook makes a chance, revolt ensues. It’s exceptionally difficult to make changes to software because of the investment in relearning. Plus, software is highly emotional to the end user, making the effect of changes impossible to estimate.
5. Software relies on hardware, which is an older, more mature production model. Therefore, hardware tends to advance more quickly than software can keep up, and replacements cannot be assumed. So, when software is produced, it must account for old hardware and new hardware, which compounds the all other problems.
I’m sure there are other points too. This is a good starting point, and I’m interested to know your thoughts, given that most of you are close to the problem.
Find the comments.
Totally agree on the titles. And terminology too. Especially critical that we (software publishers) do not set up software development or user experience for that matter (which software development brings artfully to life) as some kind of specially acquired artistry or Ninja-like skill that only the enlightened few can really fully understand or do to the fullest extent. Providing common sense guidance, resources, components and tools to everyday developers using open source technology (Java, etc) is the way to go for increasing our presence in the market through partners and customers developing and extending apps.
Oldie but goodie… My opinion is that software is hard because it’s more like gene-splicing than anything engineering or construction related:
http://bexhuff.com/2008/07/software-design-is-gene-splicing
There’s also the inherent problem that both good and bad developers have strong incentives to wring overly complex code. Bad developers do it to mask incompetence… Good developers do it because they’re bored with simple code:
http://bexhuff.com/2008/06/why-do-so-many-developers-love-bafflingly-complex-code
The code-as-art movement definitely underlines the point about software being hand-made. As learning to code becomes increasingly popular and more abstraction layers are added to ease the process, I see failure and innovation in the future.
Fewer developers w a ground-up (starting w machine language) understanding of what it takes to write good and efficient software will lead to a revolution in automation. New developers rely too much on frameworks, and as the old guard retires, something will fill the void.
Enter the machines.
Great points. You present a good example of why software does not fit the construction paradigm. Buildings are frequently torn down and renovated; part of the change of ownership allows for this.
Not so w software, especially paid software, bc customers will not allow it.
Another reason, building codes allow for upgrades and make them required. This prevents falling in love w an out-dated feature. However, as everyone in software knows, you can’t take away features.
Automation and standards will eventually begin to change this, as developers move up the stack to more “fun” layers, e.g. the iOS SDK, that abstract the guts and performance pieces and mandate usage.
Men who use the word “squee” deserved to be repeatedly slapped.