Five ways to reduce IT's software maintenance work

By Mary Shacklett

CIOs might not be able to control all of the factors that lead to continuous software maintenance, but they can follow these best practices to cut down on how much time IT spends on these tasks.

Software maintenance is a major issue for most CIOs because over 50% of IT time is spent on it -- a daunting figure that hasn't changed much though the years. It's also one of the least favorite topics that CEOs and other C-level executives want to hear about.

It's easy to avoid the topic of software maintenance, given the focus on today's problems and pressures that are brought on by a constantly changing business environment. In this high-pressure situation, which relentlessly continues its advance, the idea of going back to "fix things" or to even see why they haven't been implemented, seems pointless.

Nevertheless, CIOs have to care about this, especially when IT budgets continue to remain flat and when half of IT staff is deployed on maintenance every day. These CIOs see their project loads burgeoning, knowing that only half of their staff is free to work on them.

The vicious circle of continuous software maintenance is fueled by various factors, which include the following:

• In many cases, age-old legacy systems that are characterized by difficult to maintain (and to diagnose) "spaghetti code" that was written in the days when code was free-flowing and unstructured and yet continue to run mission-critical systems. It takes time to untangle this code and to fix or embellish it. The task is rendered more difficult because the code is usually undocumented, and the original writers have long since retired.
• New code is not as technically solid as it should be -- the reason is enterprise pressure to deploy the code, even if it is imperfect. Consequently, the organization lives with the imperfections until they become so overwhelming that the software maintenance team has to go in and fix it so it can get back into production.

CIOs cannot buck these circumstances, but some are beginning to take steps to reduce the amount of IT time spends on maintaining imperfect and broken systems. Here are five best practices to consider.

1: Use the cloud version of software to sidestep a legacy system

Some enterprise have actively deployed cloud versions of internal systems (like their enterprise resource planning systems) when they bring on new companies through acquisition. The reason is simple: By moving a new organization to the cloud, personnel in this business at least get used to using the same software that the acquiring enterprise uses. Over time, a decision can be made to transfer the acquired organization into the in-house enterprise system.

However, as more enterprises use this strategy, more are rethinking their approach. The result has been a change in thinking to where the ultimate goal becomes moving everyone (including the enterprise) to the cloud-based system. The idea is to push software maintenance to the cloud provider, thereby eliminating most of the time that internal IT has to spend on it.

2: Replace a custom system with a generic package

It sometimes makes sense to replace a custom system in favor of a third-party generic package that has more contemporary capabilities. In a situation like this, IT can also eliminate most of the software maintenance it incurs with the old software. The key is getting users -- and the business -- on board. Many times the customization that has been built into a system over decades can't be replaced with a more generic solution because of the competitive advantage the custom solution provides.

3: Invest in more quality assurance (QA) test bench automation

QA is one of the functions that many organization shortcut in the interests of getting software into production quickly. This isn't likely to change, but new automated testing tools in QA that run automated scripts and check for software deficiencies can change how well software runs and reduce software fix time.

4: Retrain and redeploy software maintenance personnel

As much as CIOs don't like to admit it, there is a pecking order in IT. The employees who often get placed on software maintenance teams are older IT programmers, new employees, or programmers who do not demonstrate proficiency in new app development. If software maintenance is to be reduced, these workers will need to be retrained and redeployed. Despite budget limitations and work commitments, CIOs must demonstrate a commitment to adopt these measures.

5: Set a metric for percent of personnel engaged in new projects

CEOs and other C-level executives might not want to hear about software maintenance, but if the CIO presents (and starts measuring against) a metric that shows the percent of IT staff dedicated to new projects and explains how software maintenance can negatively impact this, others are bound to take notice and view the effort more strategically.

10 low-cost ways to develop and improve applications

Enterprise developers are being asked to do more and to do it more quickly. Luckily, a number of cost-effective tools and time-saving approaches can help. 

Enterprises are being asked to develop more applications than ever... and in less time. Here are 10 tools and techniques to help jump-start your application development.

1: Cloud-based application development and testing

To economize soaring data center costs, companies are moving their application development and testing to pay-for-use platforms furnished by public cloud providers. The practice helps sites avert costly data center hardware and software upgrades.

2: Virtualized databases

Ten years ago, sites began cutting application development and data center costs by virtualizing servers and then storage--but few thought about economizing their softwarecosts through virtualization, with the exception of operating systems. Today, new solutions in the marketplace assist sites in virtualizing expensive software like databases by generating multiple virtual databases that can quickly be deployed for application development and testing.

3: Point and click app configuration

Rapid application development tools are now available in the cloud that allow you to target the hardware and software you want to run your app on and to define the type of app (e.g., "mobile app") you are writing with the click of a mouse. The technique frees programmers from worrying about the underlying hardware and software the app must run on, and it enables them to focus on the business.

4: Virtual operating system automated deployment

A substantial number of sites use manual scripts to deploy new virtual systems, running the risk of introducing human error and modifying scripts so the resulting operating systems being deployed are no longer compatible with the vendor's version of the OS. Now there's software that automates this process and verifies that changes to the operating system stay within the supported range of the vendor. The automation streamlines application deployment, reduces risk, and eliminates the manual effort involved when "homegrown" app deployment scripts are modified.

5: Scrum

Scrum is part of the agile application development methodology that enables a joint development and end-user team to collaborate on app building and refinement. The team works as a unit to build the application, together ensuring that the app meets IT and business requirements. The upfront, joint development process might take longer, but it pays off in time saved time later because co-development significantly reduces the potential for app modifications and failures. These savings are important. Most sites spend more than 50% of their application time modifying and fixing existing code.

6: Prototyping

Closely related to scrum is application prototyping. With prototyping, the majority of the application program is not built, but a rough layout of a display or report is created that the end user experiments with. The objective is ensuring that the app fulfills the business need. Because only a limited amount of time is committed to prototype development, it's easy to create new prototypes based upon end-user feedback and to get user buyoff before developing the rest of the app. This saves time because the app is on target in the first place. The developer doesn't have to go in to make complicated fixes for functionality that was missed because the user wasn't involved.

7: Workflow walkthroughs

Applications are only as powerful as the business processes they support. Yet surprisingly, a majority of application developers have little knowledge of the end business environments their applications operate in. To gain this understanding, developers can meet with end users to walk through the actual operation the app fits in. This gives developers first-hand knowledge of the operational workflow and improves the quality of the application.

8: Standards

IT departments that use standardized routines and application libraries create consistency in their application development that enables new programmers who must take over someone else's work to do so easily.

9: Help desk intelligence

Application developers can improve their understanding about what works and doesn't work in applications if they gather intelligence from help desk calls. The help desk can tell application developers which apps are most troublesome and receive the most user calls. When developers analyze these problematic apps, they can pick out trouble areas and take this knowledge into new application development so that old mistakes aren't repeated.

10: DevOps

Many IT departments are breaking down the walls between application developers, system programmers, and network specialists. This approach is called DevOpsbecause it combines the efforts of developers and operations specialists into one project team. By grouping professionals from diverse IT disciplines into specific application teams (e.g., finance, manufacturing, sales), application deployments are accelerated and trouble areas are resolved faster.

6 Daily Battles In The Life Of A Programmers

Being a developer is hard. I'm not saying other jobs are easy, but being in the software business demands a pretty solid effort. In this blog post I'll describe some of the situations that I find myself in and that are probably way too familiar for many of the developers out there.

1. When you get excited

Just like a cowboy in a western your fingers start itching and you just get that buzz going. You know that whatever else you have planned will be ditched. Sooner or later you will drop everything and start coding the thing you are excited about. Most of the time it's a good thing. It's like a drop of nitro inside the fuel tank. You are really focused and stuff gets done fast. Sometimes though, you get excited about things that aren't a priority and that's when it's much more difficult to satisfy your curiosity about the problem.

2. When you get in the zone

As the Zuckerberg character in the movie "Social Network" said when Justin Timberlake tried to greet the hackers: "Don't bother greeting, they are in the zone." Sometimes you just get the ball rolling so fast that everything else becomes a blip on the horizon. You have postponed your lunch for hours and your eyeballs are turning yellow because you just haven't been able to take a minute to visit the restroom. You just code, and with every code execution and every error you feel like the solution is just around the corner. "If I just fix this error, then I can commit and take a break". For me this can go on for a full workday. In the evening I find myself hungry and tired, but mostly happy because I have slayed yet another bug monster or climbed another feature mountain.

3. When you refactor

From time to time you have an epiphany. You find some new technology or a better way of doing something. Eagerly you feel like this is exactly what needs to be done to make the code faster, cleaner and more optimized. Pumped up, you dig into it hard. Many times this does not end well, though. That doesn't mean that the idea was bad. But the thought that this is just a minor adjustment goes out of the window, when a week in to the refactoring you find out one of two things:

a.) this is too big a piece of cake to eat with one go, or

b.) this just isn't working out with the current codebase.

Sometimes however it works out, and it really does all the things you imagined it would – and for all those times it's totally worth it.

4. When you make custom things

Creating a custom bit of software is generally not considered a good idea, because updates to the main libraries are almost certain to break it. But even if you decide there aren't going to be custom elements in the software, sooner or later there will be. It's just because of the fact that cool things aren't built in the main library. Is it my fault that Cocoa doesn't have popups that shoot fireballs (and that we need it because the designers sold the idea to the product lead)?

5. When you finish where you started

These are not my favourite days. Actually they can drag on for some time. These are the days when you're working on something new or on some nasty bug. Whatever it is, it's just something you can't put your finger on. You dig around the internet, read the docs and try to find anything that could give you an idea on how to proceed. When the day ends, you might leave with nothing to show for your work. You've cracked the code for a whole day and tried several different versions. In the end, however, your commit count is around zero and the lines of useful code written is about the same. When you finally get that Eureka moment, you feel incredibly relieved. Most of the time, the solution is really elegant and simple, and it makes you wonder why didn't you think of it straight away instead of wasting days on cracking with it. Two days of work and one line of code to solve it all.

6. There are no easy things

The famous saying we use here at Toggl is "How hard can it be?!". When something seems simple, it's probably quite hard to execute. Last such thing I remember was my acquaintance with Constraints in Cocoa. We needed to change the constraints of certain elements at runtime. It seemed quite easy, if we click here we change the constraints. But what I didn't know was that the documentation for constraints was quite vague and there were few examples floating around the Internet. Anyway, with good old trial and error method I got it working, but this simple thing wasn't definitely as simple as it seemed at first glance.

Source: Toggl