Doing Support When You Should Be Coding? You Didn't Finish Properly

While I was on a training course recently, we were going through the lifecycle of a project and looking at the transition from implementation to support. I realised that I often see people (and find myself) dragged through this transition. Why is this?

The only answer I can come up with is that finishing the implementation stage properly (designing and writing our software well) is key to keeping developers developing and empowering customer service and support to do all of the support and servicing. To discuss what I mean by "finishing" effectively, it's probably easiest to reverse engineer it by looking at what it is us developers are asked to do by support and service people, and even the customer:

• How does something work under the hood? This is applicable if you make scientific, mathematical or engineering software, because someone's going to want to know exactly what the frequency response of that band pass filter is or whether you've included radiation terms in your transport equations. Make sure it's documented (and unit tested to prove it does what you say). Even a well written pithy tool-tip can cover this kind of thing for the simpler cases, but it's most often going to need some comprehensive documentation. Of course, if it already exists in the public domain, reference it.
• How do I achieve my goals? Basic "user guide" stuff this, but if you haven't effectively communicated implicitly in the design or via the help and documentation, then people will keep coming back to you for this. You need to put the knowledge in the world for people, and documentation is the weakest form of this: better, make the way to use your software obvious in its interaction design.
• Does it do X? If it isn't obvious what the user can achieve with your software, then you're looking at the same problems as in the previous category. If you've implemented features that aren't in the specification and documentation, then perhaps you've just been doing the things you like, rather than what the product manager asked for. If you've done something good and it hasn't made its way to the headline, then you've denied the project manager the timely opportunity to get something into the documentation/help and make a fuss about it as a headline feature.
• Why doesn't it Do Y? This is perhaps a bit more of a product management issue as a development issue, but a strong product vision that covers all the bases of a users needs in a cohesive manner, coupled with conscientious implementation will not suffer these problems. If you keep getting asked, then find a way to get it done: campaign to your product manager to get it in the next service release or the next major upgrade.
• What just went wrong? Where's my data gone? Now this is even worse: if your software's making mistakes that people have to come back to you to unpick, then it's unstable and not worthy of release status. Recall it and test it before releasing back into the wild with a clean bill of health.

Every time we don't finish off and hand-over effectively, we burden ourselves with a few more support duties. At first it's OK, in fact it's flattering when someone comes to ask you something that only you know sometimes, but after a while it gets tedious. Is a quarter of you day too much to be spent answering customer queries and supporting the customer service team? Half of your time? Ask your manager and they'll probably have something to say about it.