How to Prioritize General Maintenance tasks when new tasks are always highest priority

Question

I work in a small company that is expanding quickly, as a result there are many high priority assignments that come up with very quick turn around. I can't complain about the assignments, they have very good visibility, I get the resources to address them how I think is right, there is generally enough time to address them, and I am not penalized for triaging tasks that cannot be accomplished in parallel. Most imporantly, it fits my working style, but they consume 100% of my time.

There are lowest priority general maintenance tasks that require my attention and are related to my work. For example development infrastructure maintenance, regular technical review, and addressing technical debt (bug burndown) that are being triaged away, always

At this juncture it is starting to effect my productivity because usually a delayed maintenance task that becomes a gating issue for a high priority task means high priority maintenance. Or I am spending my personal free time doing these background tasks. More troubling, however, are mistakes due to this maintenance debt has caused errors that require a lot of time to fix.

In addition to communicating the issues to the management team, what steps can I take to manage or incorporate the regular low priority tasks into a work day that is interrupted by high priority tasks?

Answer 1

You're facing "code debt".

This is the very nature of software engineering.

Every software project, and every software engineer faces this, continually.

It is the central nature of the industry, the science, the art, the technology of software.

In spite of trillions of dollars being spent over the 20 years of modern software on trying to solve this problem, there is no solution.

(There have been lots of hilarious attempts, which have amounted to: nothing.)

That's it. All you can do is

(1) constantly explain that you need another staff member

(2) juggle and balance

{Noting though that 1 is pointless. It would be like stating "breathe". Every single software team, group, enterprise, individual, constantly, 24/7/265/60/60, has the overwhelming problem that they are desperately short-staffed. So it' utterly pointless bringing this to the attention of your management.}

Really this question should be migrated to "software engineering", I think.

Answer 2

This is also an issue that needs to be measured, and discussed with project management. Keep a record of what you do each day – what requests come in, and how you spend your time. (Project Management software, including the ubiquitous Microsoft Project, is extremely helpful.) I use a simple time-keeping application which runs on my desktop all the time. I also use it to keep a "running log" for each project which I update throughout each day.

I'll stress the importance of gathering measurable data, because these data will not reflect "what you thought or remembered them to be."

Your present experiences obviously represent technical risk to your employer and to the projects that you are responsible for, and these risks need to be objectively and continuously measured so that project management and senior management can objectively determine where the risks are, how serious they are, and what ought be done about them. (Really, all of your co-workers should be doing the same thing. It takes a little practice to get used to it ... but the insights are priceless, and usually a surprise.)