Friday, November 18, 2005

Is your sofware really that hard to support? Companies are a hive of different development activities. Occassionally you hear about a project and you think hey, we could use that. You contact the developers and they say sure, no problem, but talk to our manager first. It's with the manager where you splat against a stone wall. And the wall has graffitied on it "we can't support that." Or "you can fork the code but it's yours after that." The manager is just playing it safe. Nobody is paying them to make a general software package everyone can use. That would take more people, more time, and divert them away from the project that they really got funded for and against which they will be judged a success or failure. But wait, the company is paying for development, is it too much to ask for people to work together so we can leverage syngeristic and other manegerial aphorisms? Apparently it is. Locally maximizing a group's outcome does not lead to global company maximization. The manager is not being irrational. The manager wants to minimize risk and telling people to buzz off is an easy way to minimize risk. Does it really take so much effort to internally support software? And if it does, doesn't that indicate there's a problem? The easiest way around a problem is to deny, deny, deny. But what's the big deal? What can go wrong? Somone Has a Question Yes, lots of questions can "waste" time locally. There are ways around this however. * Create a community. Try an email list so everyone using a program can help with technical support. Create a wiki so common topics can be covered. * Document all answers to questions. Everytime a question is answered try to improve the system so it doesn't need to be asked. If it is asked then people can just say RTFM and here's the link. That takes about 30 seconds. Someone Has a Bug If there's a bug, fix it, add it to your tests, and say thank you for helping make my software better. If your community is active maybe somone might try and fix it. Often people will try and fix a bug if they are getting enough support in their efforts. A little encouragement goes a long ways. As does good documentation, clear program structure, and a comprehensive test suite. Someone Makes a Feature Request A user loves your software, but they need just one feature to make it perfect. This is a time sync waiting to happen. But if you say no, what will happen? They will move onto something else. Users will create a new group, buy a new package, and create a new process. That's why when you go into a company you'll see duplicate systems all over the place. People don't wait to solve problems because it slows them down. So solving people's problems promptly and well at a local level is really a global maximization strategy. You can handle feature requests by: 1. Talk with the people who need a feature. Don't blow them off. See if you can work their feature into your release schedule. If you can tell the user when the feature will be implemented then they may be satisfied to wait. 2. Maybe the feature is easy and you can knock it out quick. This is ideal. How can you make it easier to get in new features quickly? 3. Maybe people in the support community will work on the feature. 4. Maybe the feature won't ever happen and you can tell the user they will need to find something else. 5. Maybe you can have separate team whos job is to add new features to projects in maintenance mode. comment[] 5:33:32 AM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 12:39:09 PM.