One of the awkward conflicts of the software development process is that developers hate the processes used to manage software development and in many cases the better the developers are at their job, the more they hate imposed processes.
That’s the view of Steve McMenamin, a principal consultant of think tank Atlantic Systems Guild, who addressed the Software Development Conference, held in Wellington earlier this month.
Despite the friction, he says, developers and project controllers share broadly the same view, pride in their work and an appreciation of the complexity of building software. Both appreciate that the project should proceed in a controlled way.
“Where they differ is in what it means for a project to be ‘under control’,” he says. A good development manager knows this from information held in his or her head and thinks the repeated meetings and audit processes are just an annoyance. Annoyance, he says, is particularly strong when meetings are long and enlivened by “unanswerable questions from clueless managers”, such as “how long will it take you to find this bug?”
He compares the two approaches to IT project control to flying an aeroplane under visual flight rules (VFR) – checking the environment and location by looking out of the window – as against flying by instruments (IFR).
Developers tend to start by relying on VFR and have to experience for themselves a “conversion” when they realise the reasons for having a project “observably under control” or experience a project which exceeds VFR’s capabilities.
McMemamin recommends a “lightweight dev interface” which distances administrators from developers to minimise annoyance, but still, he claims, gets things done.
The key link-people are the development manager and the release manager, who operates the tracking and control process, chiefly by working with the development manager and less often individual developers, to keep track of progress. A weekly or two-weekly control cycle should be sufficient to evaluate the tasks to be done in the next period, the remaining effort and the resources to make changes as appropriate, McMenamin says.
The release manager runs the weekly or bi-weekly meeting with the development manager, representatives of documentation and quality-assurance functions and “product management” representing the users. The developers are substantially left alone to do their job.
Providing a good plan and records of progress are kept, and a realistic attitude is taken to the current status and future likelihood of success, this process should work well, he says.
Iteration is a fact of life, McMenamin says; if you don’t do it in a planned way, you will be forced to repeat steps in an unplanned way. Seeing the truth of the situation, being transparent in communications and putting out “small fires” promptly are important principles.
Prediction should always be attempted even in the absence of complete evidence: “bad look-ahead is better than no look-ahead” and “hysterical optimism”, the feeling that because so much has gone wrong in the past things are bound to get better, are definitely mistakes, he says.