One of the dirty secrets of software development is that, even in relatively small organisations, the sheer number of users tends to stretch the usage of the software in directions that might not have been anticipated on the whiteboard.
The person (or people) with the initial itch face something of a paradox when designing a software product meant for mass-use. And that paradox boils down to two contradictory mandates when bringing the product into the real world:
- Commandment 1: Know Thy Itch.
- Commandment 2: It's Not About Thou.
In the earliest phases of product design, everyone--and I mean everyone--involved absolutely must understand the itch. Top to bottom. Backward and forward. Inside and out. No excuses. Why? Because misunderstandings make for bad assumptions. And bad assumptions solve the wrong problems (at best) or non-existant problems (at worst). And in either case, waste time and money.
In practical terms, that means that the everyone, including the designers and coders, need to be allowed to experience, first-hand, the pain-points. Even if it's in a shadowing capacity. Even if they don't actually work at the organisation. Actually, make that especially if they don't actually work at the organisation. Mainly because there's no substitute for first-hand experience. But also because the outside perspective can see past the politics to strip the personalities away from the actual problem to get to its essence.
After that point, it should merely be a matter of implementation, right? Not so fast.
Software development is expensive--let's not pretend otherwise. It's expensive in terms of the time the organisation spends on the development process as well as the quoted budget. Thus, the temptation is always there to leverage that investment by making it available for others. Those "others" could be different parts of the organisation. Or they could be working for companies in the same (or a similar) industry. I've seen it happen both ways.
That's the point where Commandment #2 kicks in. Maybe the software will do 95% of what these other folks need--but the catch is that the missing 5% is mission-critical. At that point, the original group has to decide whether or not to add that functionality and, if so, how to fund the additional work.
Even when the monetary cost is shifted to those requesting the changes, there's also a loss involved--namely a slight loss of control over the product. It's not logical, but this can be more painful for some than writing the cheque. But it's understandable--all the work that the original team put into researching, brainstorming, evaluating, testing, training, etc. is something to be proud of. Particularly when the product is useful enough that others are interested in it. But now these unappreciative barbarians want to change it!
Again, the reaction is perfectly understandable. Unshockingly, it even happens to your faithful blogger from time to time. But that reaction is also the warning that you've strayed away from Pride and wandered into Ego. See, the process of initially scratching the itch requires checking egos at the door. In practical terms that meant things like...
- Not taking "That's how we've always done it." for an answer.
- Not allowing office politics to shape the design.
- Not using information to play favourites.
- Not pawning off responsibility on those who have no authority.
- Not postponing tough decisions.
So, in the end, Commandments One and Two really aren't contradictory. They're both about zeroing in on the pain-points, and making the pain go away. The shortest route to that more often than not cuts through personality and power-dynamics and especially egos. Compared to that, the challenges posed by technology should be a breeze, right?
