Many times, I hear business people (such as Product Owners) bemoan how expensive software development is. And the brutal truth is that for anything non-trivial, software costs a ton of money to develop. I happened upon some numbers for a fairly simple but elegant iOS app called “Twitterrific”. Twitterrific is a client to the Twitter network, uses a well defined interface created by Twitter, and does not require any backend development. It runs on the iOS, which is a well defined, well documented, well supported, and stable environment for both development and use. According to an article published on the PadGadget site, Twitterrific was developed by a single person (Craig Hockenberry) in about 1100 hours. The article goes on to do the math at $150/hour, adds in design, testing, and so on, and comes up with a number of around $250K. That’s just for labor. No costs for a workplace, infrastructure, developer tools, and so on. Once you start adding in enterprise costs for offices, management labor, etc., and start building multiple tier complex applications, It’s easy to see why business people would look at the finished work (knowing how they interact with computers, which has become easier and easier over the years) and wonder “How hard could it be?”
That burning issue perplexes many organizations. It isn’t usually an issue with companies with disruptive products – when margins are huge, things become profitable quickly and easily. It isn’t usually an issue with a young, well funded company – if there is a long enough runway covered in money, and you aren’t accountable for showing profits until sometime far down the road, costs are not the issue. However, it is a huge issue in many enterprise IT settings, where capitalized expenditures are rigorously scrutinized to see what work can be done under the funding constraints that exist. So, why is software such an expensive thing to create?
Here are four reasons that I find compelling.
- For anything other than trivial software, the potential for failure due to complexity and development risks is huge. Back when mainframes ruled the earth in the 60s and 70s, the average program was thousands of lines of code. Today, it is very common to see applications that are tens of millions of lines of code. And, since any line of code can potentially affect any other line of code through side effects, a program that is 10 million lines of code is one million times more complicated than a program that is 10 thousand lines of code (a so called “n squared” problem). The care needed to create code that works at all, and the potential to have bugs emerge is astronomically high. While we have better tools now than we had forty or fifty years ago, they aren’t a million times better. Trust me! I developed software on machines back then as well as now.
- Programming is more like an art than it is engineering. Engineering and building large and useful things on schedule has become commonplace nowadays, and people count on it. For example, Tommy Lennhamn (from IBM), states that “Examples of successful engineering projects, at least with respect to schedule, are all the construction projects for Olympic Games — as far as I know, all Olympic Games have started on time, on fundamentally new premises.” The secret is that with engineering problems for things like constructing buildings, components to build from are well known, assemble together well, and don’t create too many unknown side effects when bolted together. In that type of situation the hard part about the project is agreeing on what to build. With software, many times the business doesn’t know what to build until they build something to see if it solves the problem. But that operates in a doubly damning world where developers don’t have the components that assemble together without knowing for sure if their construction in one place has affected something else (and someone else) in the code base. Not withstanding the efforts of TDD, we can never prove correctness in software to the same extent that we can with mechanical construction.
- Not all developers are created equal. The barrier to enter the field is relatively low. This attracts a lot of people to compete for relatively high paying jobs. But, as people like Steve McConnell point out (in IEEE Software, Vol. 15, No. 2), “…differences of more than 20 to 1 in the time required by different developers to debug the same problem” exist. Does it make more sense to hire one awesome person for $200K or 10 mediocre people for $90K each? Remember, once you hire 10 people, communication issues will slow you down (Fred Brooks “Mythical Man Month” stuff, but I digress). While there may be a glut of cheaper labor today relative to the salary requirements of the awesome developers (due to such factors as geographic outsourcing), the reality is most enterprise IT settings would never hire the really awesome developer at a relatively high pay grade, due to political issues. And, even if they could, they would be hard pressed to find talent willing to work in the stodgy environments that many enterprise IT settings have become.
- There is still a wall of disengagement between business and development that needs to be broken down. The Agile movement of the last 13 years has done a lot to publicize the need to have “Product Owners” engage on at least a daily basis (with continuous engagement being the best), but it is still very common to see business people physically and geographically separated from development. Worse yet is when enterprise business people complain about how much “more important” work they have to do, and how they yearn to return to the days of yesteryear, when they could ask the Project Manager for a status update, and then complain when things were behind schedule. Lean thinking tells us that faster feedback loop cycles will create less waste, and therefore more and better product. Given the realities of 1-3 above, and the cost associated with those items, I implore such business people to stay with the development teams and help them help you reach the enterprise’s goals.
It’s a shame that software is so exquisitely expensive to make, as the opportunities to enrich our lives by using relatively cheap hardware is everywhere. Everything from smart thermostats (such as the “Nest”) to smart light (such as the Philips Hue) to truly personal computers (such as Samsung Galaxy Gear and Google Glass) surrounds us. And it all takes programming computers in one way, shape, or form. Unhappily, programming computers is anything but easy. But if you consider that humans have been building houses, roads, and bridges for thousands of years, and are still faced with colossal failures from time to time, it sort of puts things into perspective. Programming will continue to evolve into something more of an engineering practice someday, and programming may eventually become something relatively simple. Of course, we’ll have to find something else to complain about if that ever occurs!
Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.