How to get out of the support rut and start repaying the technical debt!

Question

I have a "friend". Yes good start I know but honestly this isn't me!

Basically he's been working on a successful project for about 4 years now, the difficulty is the technical debt has caught up and he's finding it almost impossible to stop supporting the product (tweaking this and that) and actually move on with real development.

I've made various suggestions, log all of your time, create tickets, don't answer emails etc etc. The problem with this is that it seems to only serve as a reminder that he's not getting anything "useful" done.

The technical debt has largely occurred because in the first instance it was a big benefit to the product, to take requests and phone calls from users and just quickly implement them.

What I would like to know is does anybody have any suggestions for how he might get out of this rut, a large part of which would be changing the perceptions of the users so that they don't think they can just ring and expect something to be done then and there.

It's all very well saying plan better, though I understand it's very difficult to plan actual development given the requirement for support and the relative pressures from users (see above).

Answer 1

Your friend's organization desperately needs someone to do change management. This person or group would take change requests and bug fixes and prioritize them according to business impact and amount of effort required. That way, tasks that are more important for the organization as a whole would be done first, as opposed to tasks that are more important for whoever is bothering your friend at the moment.

EDIT: As an example of how this would work, most organizations have a severity scale. The highest severity level is a business-critical application or function that doesn't work. If there's something the business can do to work around the problem, that lowers the severity to the next level. If the application isn't business-critical, that makes the severity even lower. Requests for new enhancements are normally prioritized separately.

Answer 2

Make someone else take the calls, and have the line change from

We'll get to that right away.

to

Very good suggestion. I'll create a feature request to begin work on it as soon as possible. If you'd like to follow the progress on your request, you can track it here: [link to case tracker ticket]. In the future, you can also submit requests for futures in the same way as I am here: [link to case tracker]

That's probably the simplest and most effective way to do it in my opinion. The last bit tries to reduce the stress on this person answering the calls over time.

The problem you're seeing with the current 'priority' system is that when everything is a priority, nothing is a priority. For that, your friend desperately needs to heed the advice of @Larry Coleman - people separate from development that manage change requests. Ideally your friend shouldn't even know about a feature request, until that separate group agreed that it should be prioritized for work. That could even be this new person who's answering the calls now that prioritizes them - as long as they understand the business, and understand the development.

Answer 3

I've been through a similar situation myself. The product was built on shoe strings and was first in the its market on launch. It was initially successful (for a solo-preneur business), but I suppose anything worked from 2003-2007. I sought to staff it but learned the hard way that hiring good staff is expensive and by no means easy. I take it your friend is in a similar situation.

In my case it became clear early on that things would head downhill at some point. The business was still growing, but competition was rearing its head, the market was looking as if it was going to shrink, there were early signs (mid-2006) that an economic slowdown was coming forth, etc. Basically a number of factors led me to decide that the product would die eventually; the later, the better (for the customers, and myself).

In retrospect, I probably made as many good decisions as I did bad ones, but here's a brief takeaway:

1. Staff it properly and early. Get funding if you need it. (Not seeking any was my biggest mistake.) If you've sales, you'll find money.

2. Use version control/unit tests/all of the best-practice related hoopla. They all look silly/ludicrous/uninteresting when taught at university but they're usually best-practice for good reasons.

3. Hire at least one sales/marketing guy, especially if you're tech oriented. (Because if so, you'll have a natural tendency to spend more time on tech matters than on marketing, even if you've got an affiliate network).

4. Crowd-source your support. Set up a forum, so that users can help themselves out. Set up a ticketing system and invite your expert users (typically frequent forum users) to dive into a special section as virtual assistants. Let them take care of the multitudes of customers who need this/that small task done for a few bucks, so you can focus on the bigger picture.

5. Maximize your efforts into reducing the amount of support you're delivering. The less support you have, the more time you'll have to do more interesting things. By the time the product is dummy proof, customers will be grateful and so will your sales and your support staff.

6. Have the actual devs do some of the support (an hour or two per day, so they don't lose touch with reality) and give them a free hand to suggest any re-engineer/change the product (UI, functionality) if they identify anything that will make them spend less time on support. The idea is that, if they're nagged by users over and over for the same reasons, they'll want to fix things asap so they can get rid of the support calls. And the smarter ones actually do so, and that's exactly what you want.

7. If you feel the product is going to die, decide to kill it here and there and work on the next step. Let it die, really. A cash cow is a cash cow; when it has served its purpose, send it to the butcher. Do so gently (for the customers), but by all means don't let its extended survival gobble up too much of your time if the maintenance overhead is such that your competition, with the benefit of being latecomers and your having accumulated some technical debt, will implement new features faster than you can anyway.

Answer 4

One line at a time. Take slightly more time for each fix, cleaning up hacks and adding automated tests as you go. Often, doing something right ends up being much faster than adding yet another hotfix. If management pushes your friend to work faster, as management often likes to do, he should grow a thicker skin and go into "when it's done" mode.

Answer 5

The key is what kind of development methodology does he have around him to shield him to some degree? For example, in Scrum there is the idea that what work will be done doesn't change during the sprint usually. Thus there is some rules about what is going to be done and what may not be done right away. The other question is to what extent does management support his wanting to not be in a support rut? This is could also be important as an apathetic management can be a bit of a death knell for your friend's project.

Answer 6

The best thing to do is to stop the bus and take a look back. Your friend should

• Draw up a report of each problem in the system and the reasoning behind why they are bad. Design problems should be highlighted, and the amount of refactoring necesary.
• Rough timelines should be given to fix the problems
• The report should be given to his managers, and then to stake holders in the system
• All feature developments should be halted during the fixing period.

Many projects do this. If management can't be convinced it is a lost case, but if they agree the system could be brought back into shape in the long run.