It has come to the point where 4 out of 5 developers are full time dealing with maintenance or support issues.
This is mainly due to the total lack of accountability (read:reviews etc) during the development process and having dozens of small in-house legacy applications everywhere which everyone is scared to replace.
Management is hitting dept hard about little progress and projects are way behind so things like 'reviews' and 'testing' are seen as a waste of time.
How would you even begin to reduce this huge overhead?
You've just described the situation common in most IT shops!
Is there a Manager in the House?
There have already been some good suggestions here. I agree with those that have said that it's a management issue. You can try all you want, but it's management that needs to understand the situation and management that has the power to set the direction for the company. Management has to decide that there will be a development freeze, or that addressing the sins of the past is a higher priority than the project of the moment, or that a rewrite is needed, or that a better approach is justified, or that perhaps some people need to have their keyboards taken away.
Right now, better coding is needed, certainly, but communication is the skill needed most. If management is beginning to feel the pain of past mistakes, perhaps it is ready to listen but then again, the managers might be the same ones who got you into this mess by making the common mistake of assuming software development is easy. So you have your work cut out for you.
We're on our Own
If management doesn't change, then try some of what many of us in IT-land have to do:
- Take incremental steps and sneak in refactorings gradually when a project to rework the code isn't authorized.
- Utilize the benefits of some specialization. You appear to have several developers at your disposal? They're not going to like it, but to gain some efficiency, a few of them are going to have to be assigned as primary resources on the support end, especially if you are in a position where management won't change and expects you to do support and projects at the same time. Support work will interfere with projects and projects will interfere with support; the difference is that the project can be managed while support is unpredictable. You have to isolate them to reduce the productivity drain caused by the frequent context switches. If you really want to be as fair to your devs as possible about it, then let people rotate between support and projects when appropriate. Take a good look at your team's skills; everyone will say they want greenfield projects, but certainly some are better at it and others may be better at working with existing code.
- Learn from your mistakes. It appears your shop authorized lots of custom apps but didn't do a great job with business analysis and testing, leading to the support load you have now. If you can't completely correct the existing code base, at least you can try to do a better job of requirements and testing (and development) to limit the increase in support new stuff will bring.
- Get users involved. Users will be valuable if your shop doesn't have access to formal business analysis and testing resources. They can also assist with communicating to management about wanting things to be better.
- Unpaid overtime. I know, just reading that phrase sucks. Based on your description, I have to assume you're already quite familiar with the concept. But if you're happy where you are working and want to stay, you may have to make what is hoped are temporary sacrifices. Example: in my shop we used to do builds manually through our IDE. But I invested time on the side to research the build script language that comes with our development tool and although we still don't have continuous integration with automated testing, the process of making and migrating builds is considerably less involved; a monkey could do it. It saves time and makes the task easily transferable to any team member regardless of their skill level (as Totophil said: automate). Those are the kinds of things you can do to help the team save time. Creating a team wiki or better user documentation are other examples of things that reduce support or the hassle involved in doing it (although management doesn't appreciate these things and might not like use of regular working hours for it). Ask yourself: is the company one you want to stick with? Do you like your team and your users? If so, some sacrifices may be worthwhile. If not, then start looking.
Several of the other suggestions are great and Totophil's post is awesome, but it sounds like you're already in a deep hole and working for questionable management; it would be difficult to do all the best practice recommendations.
Menu
738
