Surviving IT: It’s a Gas, Gas, Gas

No, we weren't born in a crossfire hurricane, nor schooled with a strap right across our backs; we have other crises, mixed priorities, and resourcing deficiencies to cope with. But it’s all right now. In fact, it’s a gas. There is little choice for those who wish to survive in the IT trade. Either one copes with an ever-changing landscape, or one moves on to another industry. Technology shops across the nation, if not across the world, are in themidst of a crisis. The only problem is that this crisis has gone on for a couple of decades or more.

Business needs solutions that get rolled out immediately; budgets that need to be cut back, endlessly; brand new tools, that no one knows, become the answer and must be implemented. IT teams everywhere face an unvarying backdrop of constant change. Waiting for the current super-important-immediate emergency to pass is not a strategy for success—because tomorrow promises to be just as chaotic as today.

Agile database designers must know how to jump; they must decide what things can be left undone, or addressed down the road. In order to muddle through, every solution designer should make sure he or she has solid foundation knowledge on which to build. But architects must also do what they can to hold their management team accountable. Projects or enhancements are not “one and done.” These solutions must be maintained, and these solutions are expected to be refactored. When management assumes refactoring is “not their problem,” such unaddressed work remains an organizational problem, and organizationally, there are already enough problems.

The agile data modeler must turn work around in a flash. But being agile and responding to current needs efficiently does not mean one should do the absolute minimum at all costs. In other words, you can’t just eliminate any idea of documentation, or discard any concerns over standards. Although speed is important, with resulting structures and code expected to be production ready, that should also mean standards and practices still are being followed. Being fast does not mean being sloppy.

Being efficient actually does mean doing the needed documentation, as well as following standards. If one can’t follow standards and be agile, either the standards are bloated and should be optimized, or the developer isn’t up to the task. Agile approaches allow designers and developers to be creative in addressing solutions, determining how to be thorough in the job without being excessive.

Ultimately, perspective is important. If one chooses to see events as bad, then, as if by magic, here is a boatload of bad for you. No one is suggesting that anyone embrace sub-optimal decisions and undesirable circumstances as good things, but at least one should be willing to accept them as the “way things are”; they are the conditions that must be navigated. One must consciously seek the means to get through the current issue and onto the next one. Be creative, be engaged, and find some fun where you can. The challenge is in leaping through the hoops while doing the tasks at hand correctly. In IT, we are all Jumpin’ Jack Flash and it’s a gas, gas, gas.