David Bell, director of the Management Forum for Excellence in Software Development, recently returned from an international conference regarding management and its development.
There Bell sought out the views of a wide variety of manager delegates present on what they thought about software development when it is experienced by their own organisations.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
"Opinions on software development were not hard to find. Most were only too ready to share their views."
Depressingly, the conclusion Bell reached was that there is a deep lack of understanding between those inside and those outside the software development sphere and this applied to general management most of all.
Developing software is often critical and organisations rely on software developers being successful, but dealing with software firms was seen as frustrating. So why is this?
Perhaps it stems from the fact that software development is such an "invisible" task that outsiders find it difficult to appreciate the consequences of what they ask software developers to do.
Many people don't recognise that what they are asking may be impossible or even onerous. "People aren't aware of the issues we face," explains Bell.
He acknowledges that software developers must look at themselves and analyse what they themselves must do if a greater understanding is to be achieved.
Bell says one problem is that many software development teams have not formalised any kind of performance metrics.
If they themselves do not fully understand how they are performing or how they should be performing, how can they deal with everyone elses' expectations ?
In which case, "developing a clear understanding of the way in which the development department should operate would seem to be high on the list", he says. "Add to this the availability of data on the actual operation - including what happens when, for example, we take on late requirements. This should all be combined with the ability to explain these aspects in simple terms. If all this is achieved, then the basis for removing the lack of understanding should be in place."
"Of course," he warns, "it does assume that we know what we are doing and that we have the necessary data."