By David Tuffley, Griffith University
In the tech world there is a dynamic tension between needing to get products to market before the competition and the need to take enough time to make those products completely defect-free and user friendly.
It is a tricky balancing act. Cut too many corners and release a product too soon, and you risk a withering backlash. Release a product too late and your competitors become established on the high ground and you are left playing catch-up.
Finding the sweet-spot in the middle, now that is the trick. One only has to look at the recent past to see a litany of gadgets that went wrong when they should have gone right, leaving the company in damage control.
Something new … but does it work?
In the ultra-competitive billion dollar smartphone market the stakes are high and getting higher, while the price of failure can be brutal.
To the delight of its competitors, the successful debut of the iPhone 6 soon turned into a PR nightmare for Apple.
Bugs in its new iOS8 and the now infamous bendable iPhone 6+ have caused Apple stock to lose well over US$20 billion in the days following the incidents. The iCloud hacking scandal some weeks earlier has not helped.
Meanwhile, Microsoft is this week giving the world a taste of Windows 9, due for release sometime in 2015. CEO Satya Nadella must surely be hoping for a warmer reception for this version Windows than the much criticised Windows 8.
Leaked information suggests a good showing from Windows 9 – and it will need to be good as Microsoft has a lot riding on it.
Finding the sweet-spot
Hi-tech companies roll the dice every time they release a new product. If they have come up with a timely idea, brought it to the market in good shape, and for the right price, then all may go well. Maybe, hopefully.
But why does it sometimes not go well? There are a lot of variables, but there is one that is so influential that it is worth mentioning in an article aimed at a general audience.
Software developers everywhere will be familiar with the concept of “Technical Debt” even if they don’t know it by that name. Outside of the industry, few people will have heard of it.
Tight production deadlines on software projects often means that for the sake of getting the job done on time, short-cuts are taken. Putting development work off now that will need to be done later is what we mean by going into technical debt.
It might solve a short-term problem but it creates a more serious one in the long-term. Unless the technical debt is repaid by filling in the gaps, the rising complexity of the system makes further changes increasingly difficult.
As time goes by, and the unpaid interest becomes compounded, the debt grows larger and deadlines are inevitably missed. There is now more accrued technical debt than there is time to complete the work necessary to repay it. This is the crunch facing many software project managers.
This is not to suggest that software developers should never go into technical debt, only that before going into debt, there needs to be a practical plan for how the debt is to be managed.
Software engineering is the answer
Reducing technical debt and raising the quality of software can be achieved if developers think and act more like engineers. That means using a model to approach the whole process in a more disciplined way.
This is bound to raise the ire of some, but the fact is, anyone can call themselves a programmer. While there are many good ones around, there are also those who will cut corners and take the quick and dirty path.
Real software engineers on the other hand, like engineers from any discipline, approach their work by applying reliable, proven methods. If the method is rigorously applied, then a quality outcome will be the result.
When there is a bridge to be built, the civil engineer applies a tried and true method to design a bridge that will not fall down. The same is true of any other kind of engineer as they go about their work. We need software to be done this way too.
With so many aspects of our lives being controlled by software, it is time that IT developers came into line with every other profession whose work has real bearing on people’s lives.
If the car you drive or aeroplane you fly in was as unreliable as much of the software that we use every day, there would be a public outcry and rightly so.
It costs money, takes time and disciplined effort to produce good quality software; there’s no magic formula. Programmers everywhere could learn a lot from software engineering practice. In the end, everyone wins.
Microsoft is pinning its hopes that Windows 9 will find ready acceptance by an increasingly sceptical and difficult to please market. For their sake, let’s hope they got it right this time.
From 2000 to 2008 I was affiliated with the Software Engineering Institute at Carnegie-Mellon University in the US as a Capability Maturity Model Integration (CMMI) Instructor. During that time I did training on behalf of the Australian Defence Materiel Organisation for the purpose of raising the software development process maturity of its suppliers in the and Defence Contracting industry. During that period, I also earned CMMI consultancy income from non-Defence-related organisations seeking to improve their software development processes. I am not currently engaged in this business and have no plans to be in the immediate future.