Software Maintenance
posted Sat Apr 28 19:35:53 +0000 2007 - permalink
Software maintenance can be a tricky piece of scheduling. On
the one hand, many managers would prefer to shove it under the rug
and pretend that it doesn't exist. On the other hand, they want their
changes to the existing codebase now. But ultimately there
will need to be some scheduled maintenance, and generally waiting for
'bugs that look the same' to crop up and then fix them all at once is
a tactic that although it looks good on paper, isn't all that great
in practice (if it affects a customer, it should probably be fixed
immediately).
In the first part on estimation, I advocate a 50% efficiency on
new software development at 4 coding hours per day,
partially due to maintenance (and meetings, code reviews,
specification gathering, QA, documentation, etc).
One thing that is crucial for team leads is to try to
understand the business environment you are working in, and work
maintenance into the schedule instead of shoving it under the rug.
For example, is it seasonal (do your people use your software at
certain times of the year)? Is maintenance by contract (and if so who
else needs to be involved when a maintenance request comes in)? When
will the first wave of users hit the software (when they do, you will
want to have time in the schedule for possible maintenance)?
Internally, along the same vein, are the setting the
maintenance priorities. This can be a bit more tricky, but being able
to have a company wide understanding of what priorities mean via
definition can be an invaluable tool in setting expectations. For
example, at my office, if a bug hits more than one customer we are
expected to try to fix the bug within the next 24 hours. If it
affects one customer (i.e., something special with their software
configuration settings), we will try to fix it within 72 hours (and
possibly have an engineer call the customer and walk through it
because I believe that if one customer has an anomaly, odds are there
are other customers out there that have the problem but haven't
spoken up). Internal requests, while generally good ideas, are placed
in the queue and fixed when we have time. All bugs and feature
requests go into the bug tracking system (you have a bug tracking system don't you?)
As a team lead, you must mitigate all of these issues to
ensure your team's success and provide your customers with the best
possible experience. In general, your communication with the staff at
your company, including escalation plans, and your understanding of
your company's business model will put you a long way towards
success.