An accidental feature has just bitten us in the butt. I thought it worth a quick mention because it’s one of those things that happens quite often in the software industry and it’s more complex than it might first appear.
In this case it’s the ordering of a list – the customer had noticed that the list was always in a particular order. They wrote their training notes and indeed their operational procedures based around the fact that this list was always in that order.
We didn’t explicitly program the list to be in that order, we didn’t declare it as a feature that it’d be in that order, nevertheless it so happened that it was. Then we fixed a bug and as a result the ordering of the list changed slightly.
Now we have a bug report complaining that we’ve broken the list.
There are certain elements of the software development world that now would be waving their in-depth specifications at us crowing about how bad Agile is at this kind of thing and how if we’d “done it properly” then it would have been clear from the start that the list was in no guaranteed order.
They would be mockingly waving those specification documents if a) they could move them without a fork-lift and b) they hadn’t been put out of business years ago by Agile software houses like Seed.
Would it really have helped though? Perhaps – maybe the customer wouldn’t have relied on the ordering of the list or maybe they’d have spotted that it wasn’t ordered and asked for a change in the specification before the initial delivery.
Actually that isn’t so likely. Such specifications are often so complex and confusing that they never get much distribution within the customer organisation and if they do the number of people who understand them is limited (often to zero). The likelihood that the people who needed to know that the list was not in a guaranteed order actually knowing this is rather far from 100%.
Naturally there is also the risk that no matter how detailed the specification that particular detail was omitted.
So it is by no means certain that having an in-depth specification would have prevented this from happening. The only thing it is likely to do is make the contractual situation unequivocal.
That’s not the real question though, what we have to consider is what the result of us batting it back to the customer with the comment “well we never said it would do that in the first place” would be. Even with a water-tight contract such a response would have to be carefully considered.
The software industry today relies on good customer relations, repeat business and reputation. We want the customers that are using our software to continue using our software, not least because they pay an annual licence fee. Even if you’re an app developer for smartphones you have to be careful – if you annoy your customers they post bad reviews and there’s only so many bad reviews you can face down before you app dies in favour of someone else’s that has better reviews.
From a purist software development point of view this list ordering is a feature request, indeed that’s what we’ll call it internally. The relationship with the customer however is a far more complex matter – every customer tries to get at least some of their feature requests through as bugs in the hope that they’ll either get them for free or that they’ll be treated with a higher priority. If you let the customer walk all over you then you’ll be in trouble. On the other hand the age of profiteering has long passed and if the customer thinks your trying to charge them unjustly to fix genuine bugs then you could find your reputation damaged and your business will suffer as a result.
We may think of Computer Science as a logical, scientific profession but the reality of being a good software developer is that you not only need to understand logic, but you need a good grasp of politics too.