On Broken Software
Monday, September 17, 2012 at 09:28AM 
Both Scott Hanselman and John Batelle have been having problems with their software over the last week. Both their posts are well worth a read.
Years and years ago Gerry Weinberg wrote "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilisation". Not much has changed since.
It's always more fun (and more lucrative) to make and sell new stuff than it is to mend broken old stuff. And software lets you sell stuff that isn't finished. Unlike things like bridges: "Hey, that doesn't reach the other side!", and buildings: "Hey, where's the top floor?", many faults in programs take a lot longer to show up.
With a program you can leave out error handling, load testing and all the other boring bits that make a program properly useful and still ship a product that will sell by the boatload. With a bit of luck not that many people will notice. Of course, you could spend a lot more money and time getting it right. Snag is, I don't think that anyone would stay in business today making completely perfect software that took ten times as long to write as the current state of the art. People will go for new and shiny over old and working most of the time I'm afraid. I don't think I've ever seen an Engadget post about a new version of a product that is exactly the same as the old one, but works properly.
I’ve been writing software for an unfeasibly long time and some of it has wound up in the hands of proper users. I pre-date objects, Test Driven Development and pair programming. I wasn’t there when the loop was invented, but I I think I saw it in the papers. When I write a program I worry about everything, particularly what could go wrong. To me “The Happy Path” is an aside. I’m spending all my time fretting about “What happens if the response never comes back?” or “What if I get millions of these when I only asked for five?”.
It drove me nuts when I found out that the standard input/output libraries in C didn’t actually check the length of what was given to them, making the potential for buffer overrun part of the run time experience. I wrote my own input validation suite. I put it in all my products. I added timeouts everywhere. I didn’t particularly do this as part of a methodology, I just did it because it seemed sensible at the time, rather like a builder would make the ground floor before starting second floor. My programs hardly ever went wrong. Even the really big ones.
As a person who also teaches programming I try very hard to make sure that students take this approach when they write code. We start with defensive techniques and move on from there. As soon as you have a need for a number (say perhaps the age of your customer) then start to worry about how it might go wrong, become negative, very large, or change by more than 1 after a year. I don’t see this as tied to any particular methodology, I just see it as common sense, and I really want my students to have the same mind-set when they write their programs.
Modern development environments give you a lot more tools for making products that can be more reliable. Of course, the flip side is that the products can also do a lot more and that the demand for new, innovative solutions delivered in record time has never been greater. For me the only really good news is that where it is important to get code really right, for example in cars, airplanes and nuclear reactors, the software industry does seem to be able to deliver properly working systems, albeit slowly, and at great expense.
For the rest of us, I think it is as much our fault as anyone else’s that we are in this situation. We are keen to queue up for the next iPhone when the one that we have doesn’t actually work properly. Until we start only buying software that really works (and probably paying more for it) then this is how things are going to stay.
Rob
It seems only fitting that a post about software quality should hideously fail when I try to put it out there for the rest of the world to read.
First thing I did wrong was to use a poor title. Two reasons, one human and the other software. I'd copied the title from Scott's post (which is not very good etiquette and confuses search engines). I'd also included single quotes in the title text for the post, which stores up trouble should I ever be daft enough to edit it, as Squarespace then changes the title of the post, breaking the static link to it and making the page turn into a "not found" error. Of course I did an edit, so my plaguarized post is now impssible to find. And it is about how to write software properly.
Great. Conculsive proof that the universe has a sense of humour.
Fortunately I'm equal to this. Squarespace lets me create shortcuts to pages on the site, so I can put all the broken links back. I've fixed the title, made the links work properly and all is well with the world.
Except I can still hear laughter in the distance.......
Reader Comments (5)
On the one hand, you have project management: Indie developers, even, fail to *actually* test any of their code. "Oh, it works, I unit-tested everything, and it all passed!" They're not actually managing the project, they're just writing code. That's obviously a big part of writing software, but you see it shrink a bit when people start talking about writing *good* software.
On the other hand, you have People Managers in large organisations. They don't care if the product was tested, and they don't really care about whether or not the Testers or Developers care about what they're doing. All they care about is whether or not the project is cheap and the burndown looks pretty. If you take extra time or care *understanding* and properly testing things, that's often seen as a negative.
The solutions? There are none. There's always the flavour-of-the-week Project Management scheme or software, but that doesn't actually produce better software - it just produces better looking charts. It could be argued that management can be re-trained, but that's highly unlikely - the people most likely to be promoted are the ones who completely embody the principle of, and I'm paraphrasing a bit here, "Damn the Product Quality, full speed ahead!"
We're functionally forced to grin and bear it. At least until the entire world's infrastructure comes crashing down around our ears.
Recently I was talking to a leading embedded tools vendor who had logs of development cycles for the last 40 years and on successful projects the most amount of time spent actually coding was 18%. I'm surprised it's as large as this but it did include all aspects of bug fixing and updates.
I'm fortunate in that my marketplace is predominantly engineering firms who are pretty clued up and understand the importance of delivering properly designed, implemented and tested systems that have to run for years without hitch or update.
And yes, the standard C library unnerved me the first time I saw it too (1987). I don't think anybody who is a genuine software engineer should actually like the style of 'C' even if the efficiency of the final product makes it the pragmatic choice.
The Web based industry hasn't help either. Javascript and lack of strong typing have thrown out the pedigree in strongly typed Compiled languages. So now we have all teh hype of HTML/Javascript in preference to C# Silverlight.