This is an issue that either infuriates software professionals or causes them to dive under the table with their fingers in their ears, saying: “I can't hear you; go away, I'm working, naa naa naa.”
Should the software industry formalise, regulate and licence, or carry on the way we are: a mix of Wild West, Swordfish, sweat shop and skunkworks?
A number of figures in the local software industry have commented on the points raised by Professor Moshe Kam in the earlier piece on ITWeb - most agreed that he had many valid points, but that they were not enough to sway their opinion that regulators, academics and do-gooders should keep the hell away from programmers.
I think good programmers bring value, not from their degree of compliance to an arcane standard, but their ability to execute a problem. This requires creativity and insight.
David Hislop, CTO of Korwe Softwa
Says David Hislop, senior member of the IEEE, an organiser of the SE12 conference and CTO of Korwe Software, which specialises in personalisation technology and context intelligence: “Prof Kam's approach is very good in that he recognises the importance of professional associations and the early engagement of industry and business. He also observes that we need status and influence to organise and drive policy.
“I think moves to give structure to the software industry are worthy of support. I also have been 'burned' employing particular programmers, who profess to be expert, but fail dismally. These people looked ok on the box - even if they had gone to Tuks (which is an accredited university), we would never have known they were actually useless bastards with no sense of ownership - in fact, no sense whatsoever. The only way you can really know someone is to put them in the real world under fire. Of the Top Ten risks my company faces, employing accredited engineers will not make it onto the list.”
There was a fundamental challenge that observers had to the proposed requirement around companies needing accredited software developers if there was a security or public safety implication: there are already many tools, standards, regulations and even laws governing this. These cover both the development process that higher-end software development companies need to adhere to, as well as the contractual law that the seller of the system is subject to.
“In my view, there are a lot of corporate standards assurance mechanisms to ensure the right software is written: ITIL, SOX and more. Not only that, but there is some personal certification already such as CSDP. We also have CMMI, Scrum and an acronym cast of thousands to aid us,” says Hislop. “And then there is the contractual law.”
Boeing or Arivia or Siemens have to ensure that the systems they sell their customers are fit for purpose - that the plane won't fall out of the sky; that the nuclear power plant won't go into meltdown; that the trains will run safely. If they fail in this, they will be sued, possibly even prosecuted. There are already very good reasons why companies will want to ensure their developers - and development methodologies - are safe.
Why put all the onus on individual developers to manage standards?
Says Hislop, comparing software development to professions like medicine or law is not terribly useful: “Medical practitioners, lawyers and accountants typically practice their profession as individuals. While body shops do sell individual skills (to some extent) and consultant engineers act as individuals, it is normally development teams that work on a service or product.”
A factor that sticks in the craw of many developers when talking about regulation is emotion: many software people take fierce pride in their independence and their intellectual creativity - as well as their freedom to be what they want to be, and do what they want to do, whatever their formal qualification.
“I am not an engineer, yet write software. Many of the best professionals I know are not graduates, but are fine programmers,” says Hislop.
“I concur that to be a good programmer goes beyond a particular tool. But I think good programmers bring value, not from their degree of compliance to an arcane standard, but their ability to execute a problem. This requires creativity and insight.
“From a South African software company's point of view, surviving and prospering is the primary concern right now in a very tough, very competitive global market. What we really need (beyond good programmers) is access to international markets - if accreditation will give us this, then great.”
The old bugbear of anyone (especially small and medium-sized businesses) that trains and certifies highly skilled people in a developing country rears its brain-drained head: “However, it seems more likely that our good programmers will use their accreditation to work elsewhere for richer companies.”
The arguments on both sides are persuasive - some are clear and logical, some are emotional and even reactionary - but that does not make them any less powerful in the minds of SA's software industry.
The next years will be a tipping point - conferences such as the Software Engineering Colloquium will let the issues be thrashed out, and three or four scenarios may emerge: that things keep on their current chaotic way; that the industry swings heavily towards regulation and professionalisation; or that it forks - software engineering becomes a profession with practitioners wearing suits and drawing fat pay cheques, and programmers become guns for hire, living on the edges of industry, going where the work is, feat or famine.
But there's a reason why the Wild West fascinates us. It sure looks interesting. And fun. And that's what software people like.
Share