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.
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.
Through our research and insights, we help bridge the gap between technology buyers and sellers.
Have You Read This?
From Barcode Scanning to Smart Data Capture
Beyond the Barcode: Smart Data Capture
The Evolving Role of Converged Infrastructure in Modern IT
Evaluating the Potential of Hyper-Converged Storage
Kubernetes as an enterprise multi-cloud enabler
A CX perspective on the Contact Centre
Automation of SAP Master Data Management
Tackling the software skills crunch