Should software developers do it for themselves?
We don't need no stinkin' management
Reg Reader Workshop On March 7, 1992, a little-known Finnish software developer called Linus Torvalds issued version 0.13 of his open source operating system as version 0.95. It was a bold move, which took place (according to the FAQ) because "Linux is very close to a reliable/stable system". By moving the numbering system from incrementing from zero, to awfully close to 1, he set the sights of those involved very much on the goal.
Few today would have any doubt that the move paid off, but it is a fair reminder of Linus' hands-on role, which continues to the present day. Indeed, however touchy-feely one may consider the world of open source to be, the secret of its success can often be ascribed to a level of centralised control. "Normally the people you find at the core ... know how to run software projects," said Mark Taylor, president of the Open Source Consortium, recently.
The management of software development has always been beset with challenges regarding how to balance innovation with control. Too little control, and those pesky developers start writing their own stuff with scant regard for project deadlines (I remember, back in the day, one chap writing a programme to decide who should go down to the sausage roll machine at break time). But meanwhile there is the perception of overbearing management, who tie software artist-engineer-developers up in layer upon layer of Gantt charts, waterfall lifecycles and apparently unified processes.
It was to counter such views that modern Agile methodologies (such as XP) were first created. Rather than seeing project managers as the masters of the universe, they aimed to put more control in the hands of the developer. The idea was that developers, if allowed to innovate in a structured fashion, will get to an answer faster than being micro-managed through some long-winded process.
But perhaps it doesn’t matter a jot what level of control structure exists. Maybe it's the kinds of measurements in place that are going to make the difference, rather than who is doing the measuring. It's highly likely that ‘lines of code’ or ‘bugs fixed’ are not going to be the best metrics ever, but are they the best that some organisations have got, in the absence of any decent value measures? Perhaps agility and structure exist like a sine wave, rubber-banding from one to the other through the decades to maintain a common direction.
Do we need managers at all? Most probably we do – one can only imagine the lord-of-the-software-flies environments that might evolve given a complete absence of managers. Perhaps you’ve already experienced such a thing, in which case we’d love to hear from you, as we would if you believe the absence of structure is the root of all that is wrong about software projects. Do let us know your views. ®
Some good and insightful comments so far. Additional thoughts:
Regarding manager to employee ratio: At a company I worked for with approx. 150 employees, I and the rest of the engineering department mortals waited outside one of the conference rooms for the management briefing to end. When it did it was amusing and kind of disturbing when one third of the company, all managers, filed out of the room. Oddly enough this was the only company I've come across where the number of employees continually shrank over the years (mostly due to retirement) and this was seen as A Good Thing.
Regarding QA: As usual there is good and bad QA. Good QA of course fends off worthless feature requests et al. However bad or poor QA either simply have no presence (what the hell do they do all day?) or simply bog you down with ensuring that your documents have the correct references and compliance matrices. Ok great, but that QA person is not checking for information accuracy or completeness, nor software functionality or reliability. They're just checking that it really is release 2 and not 2A and that document A has the correct reference number for document B.
Poor QA also seem to hound you to provide the audit trail behind the inclusion of feature X with scant regard for any time constraint or deadline "yeah I put that feature in cos Joe Bloggs the salesman insisted on it at the last minute and that it would clinch the sale, yes the back-of-a-fag-packet he wrote the request on is filed correctly'. Maybe QA should sometimes go after the people actually causing the QA problems rather than those trying to patch it all up?
Ooops this turned into a bit of rant. On a positive note, where I am now allows more free reign over development, more trust and more focus on getting features and stability right with reasonably loose deadlines. This has made me much more inclined to support the sales and QA people and be more flexible to their requests. It's not always perfect but it's better than it has been.
In defence of managers...
We shouldn't overlook the fact that actually it's really, really hard to do it well.
There are so many people with a vested interest; developers, customers, shareholders, wife...
Since they all pretty much have conflicting interests and most managers have managers themselves, it ain't simple.
@It only works.....
I have to take exception to the comment that most developers are 'mediocre to average'!!! The vast majority are useless to poor.
To be fair however the poor ones do get weeded out quite quickly to management positions where there inepitude can really shine.
@Who Pays your Salary .....
Yes or maybe it is FOSS.
Why do some many mangers not even fall into the union, never mind the intersection?
What of course really helps these projects are the business analysts. God knows how anybody got anything done with a clear spec from these guys.
Oh yes developers always had to do it themselves, however this is down to their personality nothing to do with project management.