Bringing Software Projects Under Control
One of the jobs that Code Wizards often gets is to help a software project that’s in trouble, and there’s a pretty standard list of things that we do each time to establish and baseline and see what we can do to help.
Identify the movers and shakers - who’s the head developer? who handles the builds? who developed the list of controls and processes (note: these don’t have to be documented, they can be anecdotal: “oh, Bob always does the builds then runs through a quick test before deploying it himself”)
- How long has the project been running? How long has it been in crisis?
- How experienced are the people on the project? Have they always worked at this location or a lot of places? Have they got formal training?
- How are requirements handled?
- What’s the technical infrastructure like? Is it all based around a windows SMB share where everybody deposits their code? Is there a bug ticketing system? Are bugs handled by an Excel spreadsheet?
- What’s the subject of the Project? From a personal perspective if you were asked to give a timescale for delivery (independent of what you see at the project) would it match those that the project has got or has atleast asked the business for?
- Is there a process for testing (at the Unit, Functional and Integration testing levels)? How is User Acceptance Testing (UAT) handled? How are user bugs and requests for change documented, triaged and executed?
By this point you should have a good idea of what the project is all about, what it’s trying to achieve, what’s in place and who’s in place. So it’s time to put it all together.
At this point your opinion won’t be perfect and it’s important to remember that, you’ve seen a small slice of the project and you’ve got a flavour and opinions but few definitive facts. I’ve seen bolshy and over-confident engineers examine projects and immediately announce who should be fired and promoted, and provide “concrete” steps that will “guarantee success”. Ignore them, they’re the snake-oil salesmen of the 21st century and they’re often dangerous (you can often identify these people as their CV/Resumes read like a Hagiography and they’ve never worked on a project that’s been canned).
First of all attack the basics; no requirements or documentation? then insist that some are put together regardless of whether you’re fed some line about this being “extreme” and/or “very Agile”. Input document packs should represent the basics: a mission statement (what you want to achieve), a general outline of strategy (how you’re going to achieve the mission), and an outline of technical aspects (what technologies are in use, why they were chosen and what’s forbidden).
Then look at configuration management and software management. In this day and age there is no excuse for not using source control and a ticketing system, and I mean that, there are NO reasons not to have those things in place. You’ll probably find that various people (including lazy developers) resent this idea, force it through anyway - i’ve never seen a project that runs better without source control and ticketing systems.
If there isn’t a specific requirement for source control then pick something that’ll work and is free (free is always easier to get into businesses than paid for software in our experience). If most of the source code is text then you can’t go wrong with Subversion, it’s got a good UI for Windows (TortoiseSVN) it’s very similar to CVS and it’ll integrate directly into a software management tool called “TRAC“. If you’re working in Visual Studio then go for Team System - it’s pretty good and it integrates into Visual Studio which will make the developers job easier.
TRAC should be an easy sell to the client, it’s free, integrates with Subversion (aka SVN) and reads the changelog, it’s open and extensible and includes a wiki that you can use for documentation. OK it doesn’t do everything, but it does most things, and it does it well and doesn’t encumber the developers. But I’ll blog more about TRAC in future.
Next establish basic processes and document the original and your revised versions (nobody else is going to do this for you - so put some headphones on and get your head down and get a basic set documented). This gives you a way you can show people why they’re different and what the benefits are (if you’re in TRAC then do this in a nice diagram and put the new processes on the first page of the wiki).
Then start creating tickets for functional implementation and bugs and start showing how you can assign them and have them worked on.
Lastly, present what you’ve done to a mixed audience of the business owners of the project, the project and programme managers, testers, developers and analysts, and get ready to be flamed, heckled, insulted and generally disliked.
The truth is that few of us like being criticised, especially when it’s from an outsider so it’s not going to be an easy ride. You’ll probably find acceptance comes from the business lead (who probably hired you to look at their project), then the programme manager, project manager, testers, team leads and managers, then the developers. It’s a fair chance that the developer leads (aka “Corncobs” according to Anti-Patterns) will never accept the changes unless you present the ideas as being partly their idea, so do this if it makes your life easier.
Before disengaging you’ll need to help them run the new processes and tools and ensure that everybody is keeping to the requirements of their roles (are analysts generating requirements now? are the team leads ensuring that developers are always checking in with defined ticket numbers? are testers entering and tracking their bug tickets? are managers handling bug/function ticket triage and assignment?).
You’re probably thinking, ok those are good points, but why does it make sense to use an outside party to do this? Well the reason is simple: you need somebody without affiliation to anybody in the project, you need somebody who doesn’t mind being disliked and asking difficult questions, and lastly you’re better off if that person can come in and do the work then leave - so then the team can act like it was all their idea anyway and collectively bond while moaning about the person who came in about the work.
Do teams ever welcome you, acknowledge the things that are wrong and help you remedy them? Yes, of course but it’s few and far between and those are the managers, leads, developers, testers, and analysts that you should think of the next time you need to build a team to develop software as they’re worth their weight in gold.
Good Luck!