Narrow GapWhen the gap is narrow, the decision-maker is cognizant of how his or her strategy is working; he knows whether unforeseen factors have made executing the plan more challenging and is aware of how subordinates are carrying out the tactics in meeting a plan's goals.
Wide GapWhen the gap is wide, the decision-maker lives in a vacuum and tends to take credit for success and pass blame for failures often without understanding how results are achieved or missed.
Gap EffectsThis gap is a big factor in leadership, and most leaders seem to misunderstand or not care about it. It's not just in IT either, and dysfunction is visible within this concept across top leadership in all industries. And wide decision-consequence gaps often lead to poor empowerment ratios.
It's a harsh recipe especially in software development too, when functional owners and project managers are given strategic and tactical control over non-functional elements. Although not all will make mistakes here, under the duress of time constraints there is often a push to favor speed over quality. Non-functional concerns will be given little priority despite the advice of the developers presiding over the construction.
If you've ever supported poorly designed and poorly implemented software, then you are quite familiar with this already. The people that decide a team will cut corners to make a date are not the same people who have to support it and work the production support load.
The project manager's common refrain here is that if developers are left to their own devices, the product will never ship. I agree that developers who care and are perfectionists may draw the development cycle longer than is comfortable for the business. And it is often true too that developers, in the interest of pleasing management, will comply in promoting a shoddy release to make a date.
Cheap Fix for a Cheap MethodologyBut what I hope for in a better and more mature IT world is not necessarily perfection. It is that we collectively strive for something better than the C-minus level software most corporations deal with now. Can we maybe compromise and get to a B grade? The difference between a C-minus and a B would be perhaps that:
- Some routines feature hard-coding, but that routine is properly isolated in a method that can be easily tested and refactored.
- We put more eyeballs on our database structure so that common pitfalls don't make it into production and compromise future enhancement and refactoring efforts.
- We not short the concepts of testing and training, so that fewer "diaper change" type of requests get turned into weekly flurries of productivity-and-morale-sapping help requests.
- User interfaces aren't so awful as to make our users cringe when they have to work with our systems, or so confounding and unintuitive that it leads to more support calls or worse, bad data getting into the system, which leads to more data fixes.
None of the above suggestions are terribly expensive and a lot of it is good preventative maintenance and best practice. Yes, there will be a time cost somewhere. But you can't read a magazine article about agile and then decree your teams will start using it and expect immediate benefits if you haven't empowered them to write software that is properly objectified and can be tested or maintained without massive effort. And you won't understand any of these concerns if you suffer from a sizable decision-consequence gap.