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.