"Electronic Landscape 'Xeon'" by Jaypeg21 is licensed under CC BY-ND 2.0

The best thing about writing the CIO blog is hearing back from the Agencies when they have taken interest in a particular topic. We take an enterprise view of the technology infrastructure at the State of Nebraska, and it is nice to know that our blog is serving as a window to that vision. The biggest question to cross my desk this month was this... Does it ever make sense to throw hardware at an application development problem?  The road to a CIO position normally goes through application development and my journey is no exception, I began in Operations and Infrastructure so I am of the persuasion that throwing more hardware at a problem only masks it until a later time and causes a more costly and difficult problem to resolve when it rears its head again.

I have read many articles that say it makes sense to buy the hardware. The logic is economically based as, “developers are expensive and hardware is cheap”. Don’t tell my hardware vendors I repeated that. This is equation. The cost of hardware is only a fraction of the overall cost when you factor in the supporting infrastructure, storage, backups, and support costs for that hardware. Oversimplify and you run the risk of robbing the development team to pay the infrastructure and operations teams.

Looking at the specs of modern hardware is tempting because new hardware offers immediate scalability. I caution the impulse to buy, scaling your infrastructure is quick to do, but scaling your support staff is not so easy and it cannot simply be purchased. The right support teammates will be proficiently skilled in specific areas and have the required training on your system. Throwing hardware at a performance problem is not a substitute for developing the proper team to design your product in the first place.

Now let us consider ‘Technical Debt’. A poorly designed application acquires technical debt, like credit interest. Here is how it happens: A poorly designed application gets released because the programmers took shortcuts to hit deadlines and/or budget constraints. The developers were not allowed sufficient time to address the minor performance issues within the application. Then, over time, the issues failed to be addressed and the minor issues become expensive problems. There is not enough hardware to dig you out of that hole. We call the compounded problem technical debt.

Technical debt has other causes, but I see it more commonly in situations where developers are pressured to quickly build additional functionality into an application. This frequently occurs because the requested functionality was either poorly defined or missed in the requirements phase of the development lifecycle. 

Looking across the State I wonder how I can educate our product owners, the Agencies, on the true cost of hardware and help them invest resources and money to make their applications run efficiently. My goal for State technology is to help us make decisions that reduce our hardware processing costs and therefore the cost of infrastructure and total cost of ownership.

Take... for example, our ongoing Application Portfolio Management project. This year product owners within the Agencies made significant progress in identifying the applications that they believe we should invest in. As a result the target applications have been identified for modernization or transformation. 

However, this is simply the beginning of the journey. I have identified three steps I believe we must take in order to avoid or eliminate technical debt that could ultimately derail our mission:

1. Resist the temptation to call a project complete. When minor coding issues are discovered, do not ignore them or mask them with additional processing power. Take the time to address them appropriately before they become impossible to address. The sooner you begin to address the unsuitable code the better.
2. Identify specifically where the performance problems are and scrub only the identified areas that will make a quick impact.  Then rinse and repeat. In my experience, the problem is often inefficient interaction with a database or a poorly optimized database; nested loops initiating queries that initiate other queries; excessive table scans; etc.
3. The changes that you are making must ultimately result in lower rates. The customer must see this as a long-term win. It makes no sense to spend expensive development time with very little payback.  Ensure there are significant gains in performance before you begin.  Never optimize beyond your stated performance goals. Know when it is time to stop and move on.

 As always I appreciate the work you do each day for the citizens of Nebraska.