Downtime Pursuits When You Don't Have Much To Do

This was published previously in this blog back in 2010. I'm re-publishing it for any benefit which others can find from it I'm happily and honorably retired now.

In IT there can be some times when a developer doesn’t have much to do. For a consultant, this is often during the ramp-up time for a project, when the project is first starting, or during the cool down phase, when the project has been elevated to production, and it’s mostly production bug fixes for a while. When I’ve been an in-house developer, this has usually been times between projects.

I’m persuaded that the wise use of this time can make a huge difference for one’s own career progress and the good of the department and corporation as a whole. Unfortunately, there’s often a dearth of good ideas on what to do during this time, and seemingly irrational pushback if someone tries to do something which does not originate in the mind of a business sponsor who is an upper level manager. I think that the pushback comes at least partially from an unarticulated question, “Where we will charge the hours for this idea?” And I think that otherwise pushback comes from the unarticulated question, “Who will get credit for this?” And finally, I think that pushback comes from managers and supervisors who seem to think, “I don’t have time to supervise this or the political capital to get this done.”

Here are the five basic uses to which this time can be put:

• Process improvements

• Project or departmental infrastructure projects

• Documentation

• Personal R & D time

• Peer training and assistance.

In short, these are the five things for which there are common complaints that there is no time for these things to be done when a project is actually underway, and managers, project managers and team leads are worried about making a due date and adhering to a project timeline. The truth is that these kinds of activities can actually reduce project timelines if they are chosen wisely. They come under ‘working ahead’ and ‘working smart' activities, rather than frenetic ‘I’m working as hard as I can’ activities. And if anyone is worried about charging time for these activities, someone needs to make sure that there is simply a bucket to charge these activities.

The key is that unlike a project for a high level business sponsor, these activities can be:

• Low priority: Production issues or business projects take priority over completion of these projects.

• IT centered: Directed to the greater efficiency of IT (developers, testers, business analysts, system administrators).

• Automate minor manual business processes (1-2 users) such as repetitive data entry, credit inquiries or faxes of incoming information.

• Left temporarily incomplete to be taken up by others to complete when time and availability changes.

Here are some ideas that I have for these kinds of activities.

• Developing Visual Studio template projects for the kinds of projects which are anticipated in the near future.

• Implementing internal documentation websites for development teams or projects.

• Developing code generation utilities for future projects.

• Developing an automated build system.

• Developing other departmental or IT utilities.

• Developing guidance recipes for future projects.

• Documenting existing systems.

• Updating existing documentation for existing systems (lots of existing documentation contains omissions and errors, and degrades over time).

• Serving as a scribe to take meeting minutes to make sure that decisions and action items are clearly documented (lots of meetings end with no one agreeing on what was actually decided and who would implement the decisions).

• Internal cross training.

• Performance monitoring existing systems (lots of existing production systems, particularly those with a  mid to small number of users, never receive any monitoring once in production).

• Looking through event logs for avoidable and fixable errors (lots of fixable problems never are found and fixed even if sufficient information is logged).

• Cleaning up bloated error logs and event logs.

• Evaluating and upgrading existing error logging functionality.

• Reviewing existing code for possible improvements.

• Reviewing existing databases for possible improvements (lots of existing databases are never evaluated after being put into production).

• Review of existing systems and databases for security bugs and user access (lots of existing systems and databases retain access rights for transferred or terminated employees or too high access levels for non-administrators).

• Developing archiving solutions for existing databases (lots of existing databases never archive outmoded or obsolete information).

• Developing ETL solutions for existing databases.

• Developing automated unit tests for existing code modules (lots of existing code modules never get regression unit tests developed for them, and may break when enhancements are added).

• Cleaning up source control projects and archiving outmoded code and projects.

• Preparing and delivering peer training presentations, such as for a Lunch ‘n Learn or departmental meetings.

• Conducting research on new technologies which could prove useful.

• Developing prototypes for new technologies which could prove useful.

• Automation of minor business processes.

• Development of a process improvement suggestion site.

• Development of a departmental wiki.

In short, the tunnel vision that sees any useful activity as having to be initiated by a person who is an IT or business unit manager can miss out on many possible improvements which can be pursued in the time when developers are not dedicated either to production support fixes or major projects. And yet these minor improvements add up over time and add to the bottom line value and efficiency of an IT organization and the corporation as a whole.

Here are some ideas to help this take place in a department or IT organization.

• Encourage and reward the initiative and courage it takes to envision and suggest process improvements and to make wise use of down time.

• Serve as an ‘angel’s advocate’ for new ideas and process improvements rather than as a cynical devil’s advocate who commits infanticide on the ideas of others.

• Allow developers to get close enough to end users to develop the kind of trust to where end users can share their process improvement ideas.

• Allow developers to see end users at work enough to where they can spot opportunities for process improvements.

• Allow developers to explore new technologies early enough to find possible implementations.

• Make sure that ‘idea theft’ is not rewarded either in the short term or long term.