Sometimes making a plan for a new piece of software can be a real challenge. I found out about this, because some of the customers I’ve worked for in the past seem to have a pretty interesting way of planning a solution.
The most problematic area for customers in planning a software solution is the time factor. At least that is what I think. Some customers want it yesterday or even the week before that. This is totally impossible to do, unless someone has a time machine for me. I have to admit here that I never told customers that, because it’s not very customer friendly and gets you nowhere. I have however applied some pretty good strategies to make things work out.
Some time ago I sat down to take a look at solution for a pretty complex problem. One of the key non-functional requirements was that the solution offered more protection against user errors. We have made a solution to the same problem before, but that one didn’t work, because people stopped paying attention at some point and wreaked havoc on both test and production environments. This all lead back to user error and lack of error handling. Trust me, the matrix gets bend more often than one would like to know about and in some pretty weird ways when you build applications that aren’t protecting themselves and the system against unwanted bents. So I came up with a solution that took several hundreds of hours to build, had good error-detection and error-handling. On top of that it even had a manual for developers, so that they wouldn’t break it again.
When I went back to the customer and talked to him about the solution he was surprised to see how much the solution was costing him. When taking a closer look at the solution he didn’t start about the manual, but instead started talking about the solution itself. He asked me if I couldn’t do it in less time. I replied that I couldn’t, because I didn’t want to go back to the old solution with the problems that came with it.
Then the most interesting thing happened. At some point during the conversation we were talking about removing one of the core components in the solution, because the parts of that component took the most time to build. I have been puzzled before… But this left me pulling on the string of the virtual light bulb for quite some time.
In the end we scrapped the whole solution, because it simply took too much time to build.
For me this was a clear sign that it’s sometimes a good idea to not talk about the technical stuff in a solution. Or maybe bring spare light bulbs….