The inconvenient truth of software development
I was just perusing a conference catalog for a major conference and it all of a sudden dawned on me that a majority of conference sessions were about creating this application with that featured technology. What’s more, this phenomena isn’t unique to this conference– just take a look at any development portal and look at the article titles– they’ll most likely reflect the same pattern. In fact, this pattern of touting the latest and greatest framework or technology for building software applications isn’t new. We’ve been chasing technology silver bullets since the days of mainframes.
Don’t get me wrong– I love learning about the newest framework out there and trying to ascertain if I’ll have an opportunity to utilize it at some point, but why is it that we as an industry appear to focus the vast majority of our attentions on creating applications when we actually spend a far greater time maintaining software applications?
It turns out, as Robert Glass wrote in “Facts and Fallacies of Software Engineering” that:
Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
Therefore, wouldn’t it seem that we’d see a lot more conference presentations on how to make that large maintenance cost as low as possible? Or when someone builds the next greatest framework for building these, that, and those types of applications, why is it that they tout how fast you’ll be able to do it. I, for one, would love for someone to tell me how easy it is to maintain that particular tool or framework, because ultimately, that’s where I’ll end up spending the most money.
If the lion’s share of money is spent after the initial application is built, it seems to me that the criteria for success then isn’t how quickly a high quality application was delivered to a customer. A more logical standard for success, it seems, would be that an application was indeed delivered quickly, but that it also is relative inexpensive to enhance and therefore will prove to be an economically friendly long-lived application.
Instead, it appears that the vast majority of us don’t want to admit that software is aeternum and thus go about learning how to build interesting applications with equally interesting new frameworks and technologies. I’ll be doing the same, but with the added realization that many of those interesting applications will indeed be built and will undoubtedly be spending the majority of development costs in maintenance.
May 1st, 2007 at 8:19 pm
Apropos of nothing, I really like The inevitable pain of software development.
May 2nd, 2007 at 6:03 pm
Your point is dead on, and I wish more people would wake up to it. The current fad towards runtime validation is powered by the claim that it lets you build software faster. Runtime validation is a powerful thing (even I was seduced by that power for a few years), but the result at the end of that road is write-only code like this. It’s super-powerful, but super-fragile: that’s not the kind of trade-off that is good for the long-term viability of code, which means that’s not the kind of trade-off which is good for business.
What’s extremely frustrating is that it’s very possible to get the duck typing and succinct code that people want while still gaining compile-time safety: inferred static typing is used to great effect in OCaml and Haskell.
May 3rd, 2007 at 4:53 pm
Just like the movie your post is titled after, this argument has several things that need to be debated.
First of all, all conferences need to be paid for somehow. Typically this payment is in the form of sponserships by companies that make software. In addition to this sponsorship may conferences still yet charge you admission. Even further yet you typically have to travel to attend the conference which costs even more money.
So since putting on a conference costs money and so does attending you need to ask yourself what generates the revenue in this industry as that is what the sponsors are out there to gain as part of sponsoring a conference.
Then you need to ask yourself what will a company that hires developers spend money on. When a developer is hired it is usually assumed that he knows how to do what is on his resume, if not he is usually fired. So then, what is the incentive to go to a conference to learn about something that is already on your resume. The same then is true for that company hiring the developer. If the developer does not get to put additional things on his resume then what is his motivation for staying in that job (other than a paycheck, which for many is enough).
So while I do agree with you that we do spend most of our money on maintaining software we cannot spend most of our money there as well. If that were to happen our industry would self destruct from within. Innovation would have less of an emphasis until it disappeared completely. I think we can speculate what happens to an industry that does not innovate, or even worse a society that does not innovate.
Now don’t get me wrong, I still think we need to do a better job of training people on how to better maintain code. But you first. I like to write code new code, and so does every other developer I know. So why then, when placed with a choice of going to new code or old code I would chose to do old code. Of course the smart developers will know how important that is which is why they know who Martin Fowler is. But these are typically not the people doing the maintenance. It is usually the junior/new guy or someone that has been around for ever and does not like change. Neither of those people will be at a conference unless their boss makes them, in which case they will want to do the new code while they are there. If for any other reason a change of scenery.
But I do welcome sessions on how to code smarter using what you already have in your toolbelt. So please do keep on fighting the good fight and I’ll do my part to keep you colder.