Those of us with grey hair and long memories will remember the dread word of computing in New Zealand: ‘INCIS’. INCIS was the ill-fated, all-singing, all-dancing, uber-solution commissioned by the NZ Police in the 1990s. Vastly over budget and over time, it finally sank when it was revealed that it was obsolete before it was commissioned and couldn’t run on the then-current version of Windows. Heads rolled, politicians and experts pontificated and, from memory, $92 million was lost.
Which you might have thought would put anyone off custom software development.
Certainly, all-encompassing super-projects were looked on with trepidation by the sane, and it was perhaps not entirely coincidental that around the same time, ‘Agile’ software practices starting evolving. In a nutshell, ‘Agile’ says that rather than getting bogged down trying to do the entire project in one go, it can be managed in stages with a sort of ‘OK-this-is-where-we-are-at-where-do-we-go-next’ review at the end of each stage.
Agile can be a big improvement on all-in-one-hit, in as much as it can deliver a superior result with a lower impact on operations and staff, and potentially at a lower overall cost. It is also much better at supporting evolving requirements than a cast-in-stone specification.
However, Agile projects can also be perceived to be never-ending, with an attendant cost over-run. This is trickier, because it can have a lot to do with managing expectations rather than any real shortfall on the part of the developer.
Whatever methodology is deployed, the real question is whether Passionate Software Development is being applied. Passionate SD isn’t a methodology; it is a culture and not every software development house has it. You can see the evidence of it by the pleasure a developer takes in being able to exceed a specification requirement. Sometimes this is going to be under-the-bonnet stuff that will mean nothing to you. Sometimes it is going to be more obvious.
To take one of our favourite examples of 2010: one client had a problematic spreadsheet provided by a third party that they had to analyse on a weekly basis. It was repetitive, complex work and consumed about 10 man-hours per week. They had asked as part of the project specification, if we could import the spreadsheet into the solution so they at least wouldn’t have to duplicate the data entry. We thought we could do a bit better than that.
When we demonstrated the prototype in our office to their office manager, she sat there for a moment and her jaw dropped and her initial response was a single word: "S**t”. Then she frowned and we asked her what the problem was. She responded "I’m trying to work out how this will fit in with our processes, but it replaces them!” Our solution pretty much automated the entire analysis process for them and we delivered it within budget for the simple import.
A few weeks later we demonstrated it to the General Manager. He sat there, shook his head and quietly smiled, "****!”
In another case, we managed to improve user speed on a project by 20% simply by shifting two buttons on a screen. Incredible, but true.
Getting paid for what we do is nice, and we think we offer fair value for what we do charge. But what really motivates us is the moments like these, when we know we’ve made a difference. Management consultants call it the ‘Surprise and Delight’ factor.
When you next look to engage someone to provide a software solution for you, make sure they can tell you some stories like this and provide the verbal referrals to back it up.
If they can’t, you might be facing the sort of situation our newest client faces, where after four years and a bill well into six figures, they are pulling the plug on a third-party front-end to MYOB. As you read this we will be working on the first phase of the replacement solution. We only met the client at the beginning of December and the Agile method will deliver the complete solution from scratch by March 31st, at a fraction of that cost, or I will eat my hat.