Recently I’ve become involved in a number of technology projects around the time they should have been wrapping up. Having to fix something late in the game is about as much fun as a poke in the eye.
These projects were well-executed most of the way through. A legitimate problem was recognized, requirements were properly analyzed and an overall good solution was designed and built. This left everyone very confused about why implementation was such an uphill battle, and why the customers were unhappy. In every case, it was the finishing work (or lack thereof) done on the user interface that caused strife. The bright side of my recent flirtations with disaster is that I got to know a very interesting customer — someone who has even more patience with technology than I do myself. He has a poster on his office wall that simply says “PUT THE BIG ROCKS IN FIRST.”
Maybe all we need to do is change our way of keeping score so the endgame is weighted more heavily. Instead of giving ourselves points for doing something cool with technology, we should give ourselves a point when someone else finds utility in our work. According to these rules, everything that matters to a customer matters to us.
Even when we make our best efforts to deliver a polished product, odds are there will be a number of requests for modifications shortly after its release. One example is an application I worked on that allowed staff to generate detailed sales history reports by entering a product code in a search field. There was a validation routine to confirm the entered product code using its check digit and cancel the search if it was invalid. This was intended as an elegant bit of finishing work — to prevent the wasted time of querying for something that didn’t exist and to prevent the user from being confused if no results were found due to a search string typo.
After the application launched, I heard from one user who was not able to find details on any of the products he was responsible for. It turned out that his department used product codes that didn’t conform to the company’s standard and wouldn’t validate using the check digit formula. Was this something I should have discovered during requirements analysis? Perhaps, but often no one thinks to communicate this kind of exception up front — it is discovered when the exception comes up in practice.
One could also argue that this was a larger data management issue; that an invalid product code should not be in the system. Still, the short-term solution was that my application needed to change right away in order to meet this user’s needs.
After several months of work on the application, its value would have diminished quite rapidly if I hadn’t been prepared to make this quick fix. The fact that I changed the validation code and got back to the user within a few hours impressed him so much that he became one of the most vocal supporters of the new tool and did a great job of marketing it amongst his peers.
It is absolutely critical for developers to be involved in the implementation phase of the project and to budget time for the user requests that are bound to come in after the go-live date. I’ll continue to put the big rocks in first, but I’m going to make a poster of my own: “MAKE SURE THE SMALL ROCKS FIT OR YOUR CUSTOMERS WILL THROW THEM AT YOU.”
