Three recurring conflicts born of well-meaning but often diametrically opposed IT forces keep haunting IT systems development.
Over the past few months, I have been involved in scenes from either “Groundhog Day” or “Dawn of the Dead,” depending on where your movie preferences lie.
Specifically, I have been involved in situations where the issues that surface are all well-worn conflicts that I have faced many times before. Thus, as in "Groundhog Day," you keep facing the same issues again and again. Or, in the case of "Dawn of the Dead," zombies just keep coming at you even after you think you killed (or resolved) them.
These issues surfaced in different venues, including a system's critical design review, meetings over standardization, and security assessments. A more accurate description for these recurring issues is “systemic tensions,” as they recur because of an unsettled conflict between strong opposing forces. Many times, in and of themselves, a particular force is seen as a good thing, depending on the circumstances. In such cases, a systemic tension is created (and lingers) when two forces — both considered similarly useful — are in opposition.
Speed versus quality
Performance has been at the center of IT debates for longer than I have been alive. These debates normally surround the performance of hardware, the performance of software applications, and, more recently, the performance — or speed — of the development process.
Speed of development is a particularly important issue for government IT management and was even a major target of former Federal CIO Vivek Kundra’s 25-point plan to reform federal IT management. Even so, it can be taken too far. As I’ve said before, you don’t fit “agile” software development; agile must fit you. In other words, don’t force agile when you are either not set up for it (in terms of customer involvement) or the demands of the system require more up-front design.
In a recent critical design review, it was interesting to witness a self-proclaimed agile development team choose a dynamic programming language, benchmarked at 30 to 50 times slower than traditional alternatives, because it fit into their “agile mindset” in direct contradiction to the systems performance and complexity requirements. In other words, in that decision and several others, they chose speed of development over system quality. For mission-critical systems, I never choose speed over quality. As is evidenced by Apple’s success, the catchphrase “It just works” should be the top priority.
Standardization versus innovation
In the eternal standardization battle, I recently witnessed a zombie slugfest between the forces of interoperability (via standardization) and the forces of “leave me alone to do my own thing because I know better and you don’t understand my ‘special’ circumstances.” A key tipping point in the tension between these opposing forces is the understanding that the maturity of the technology should influence where the scale tips. In general, the greater the maturity, the more you lean toward standardization. For less mature (or stable) environments, innovation is needed.
Security versus productivity
My company recently completed a security architecture for electronic reporting, and currently I am performing some cybersecurity research. In both cases, another obvious and systemic IT tension arose. Simply stated, security measures are costly. They are often in direct conflict with productivity. By their very nature, they slow things down. On the other hand, we all clearly see that the threat is real and growing. For the government’s part, where to fall in this tension between forces is easy — you must err on the side of security.
Systemic IT tensions are both interesting and unfortunate phenomena because they can cause you to waste many hours retreading old ground. Understanding their root causes and where the scale should tip in your particular situation can short-circuit the tension and allow you to move forward.
NEXT STORY: 10 tricks of the social media trade