Earlier this week, UK-based application modernisation technology vendor Micro Focus announced that it’s purchasing Borland, as well as the testing and quality management software assets of Compuware.
Bola Rotibi, our Software Delivery Principal Analyst, has a great piece on this over on our new Software Delivery blog. Please check it out – Borland acquisition: it finally happened – but not how we expected.
You can also subscribe to MWD’s Software Delivery blog feed here.
This is the fourth in our Software Delivery InFocus series of podcast episodes, starring Bola Rotibi – the Principal Analyst of MWD’s Software Delivery competency area. In this episode, she discusses the thorny issue of software quality. This is something the IT industry has talked about for decades – so why is it still so patchy? Bola’s guests are Madelyn Bryant McIntire, Principal Group Manager, PQO Product Quality Management, Microsoft; and Justin Spencer, Development Manager at Lend Lease (a large publicly listed international property group).
Producing quality software code is undoubtedly a desired goal of any software delivery team – irrespective of whether the delivered application is for commercial sale or internal business use. Software quality is regularly placed in the top five demand requirements of the software delivery team, yet the quality of software is regularly highlighted as a major failure point and the basis for much end user dissatisfaction. Here, Bola talks to her guests about the main points of failure in software delivery processes; the actions that Microsoft and Lend Lease take to improve the quality of delivered software in a business-driven environment; where the next challenges will come from; and what tools suppliers could do better.
You can download the audio here or alternatively you can subscribe to the podcast feed to make sure you catch this and all future podcasts!
Yesterday I spent the evening at a dinner in London as a stand-in for my colleague Bola Rotibi, talking about Application Lifecycle Management (ALM) and governing software delivery to a group of around 20 senior IT leaders. Due to my own disorganisation I’d not realised that this was a stand-up talk with no visuals or projection, and I’d created a slide deck for the talk. So, on the train to the event, I was frantically reverse-engineering my slides into a set of brief stand-up notes. Although it was a pain, it ended up being fortuitous because the act of having to reinterpret my slides made me see a couple of points worth making that I hadn’t spotted before.
The point I was making is that today’s industry interest in ALM represents an interest in delivering high-quality outcomes from software delivery work, but that’s hardly a new thing. However the need for ALM today is made more pressing by industry’s historic failure to consistently address quality as a concern. It’s what I called “industry’s dangerous flirtation with software quality” – kind of a perpetual “get away, come closer” posture that has by and large failed us. Although there’s now 50+ years of racial memory somewhere out there in industry about why software quality is important and how to achieve it, the problem is that fundamentally, the IT industry is a fashion industry – and each new fashion wave brings a new set of devotees, few of whom are particularly interested in taking notice of what the devotees of previous waves learned.
Let’s look at a picture.
What I’m trying to show here is how disruptions in technology platforms and architecture patterns typically lead to the baby being thrown out with the bathwater. As any given approach starts to have mainstream applications and matures, the importance of quality becomes more visible. Then, though, a new platform arrives and we start all over again. Think about how, in the client-server era, we started with hacking in PowerBuilder and VB; then, “second-generation” client-server tools took more CASE-like approaches and helped organisations deliver more scalable, robust apps more quickly. Then came the web, and it seemed that we suffered from a mass “memory wipe” before grabbing hold of the nearest Java IDE and hacking again.
We’ve been through this cycle at least three times: from mainframe to client-server; from client-server to first-generation web; and from first-generation web (simple consolidated server deployment; simple web-based client deployment) to where we are now (I’m desperately trying to avoid typing the web-two-dot-oh thing, but I’m referring to web-based services with multi-channel front ends, mashups in the mix, back-end web-based integration, etc).
Of course, so far I’ve really said nothing you probably hadn’t thought about already. But what also struck me yesterday was how each “turn” around the cycle has added more complications to the process of software delivery. There are three parts to this.
Firstly, consider that each time we’ve turned through the cycle, the overall IT environment has become more complicated. This has happened in two ways. Each new platform/architecture has brought more distribution, federation (moving parts) to the equation; and nothing ever dies – mainframes, client-server systems, and first-generation web systems still abound. They’re part of the operational and integration environment.
Secondly, each time we’ve turned through the cycle, there’s been a decreasing scarcity of “hard” resource – that meant that we naturally had less innate desire to control effort and quality than previously. Back in the early days of mainframe development, CPU cycles were expensive and access to those cycles was exclusive; it was absolutely obvious that the cost of the assets employed was so high that you had to get things right first time.
Today, for the price of a sandwich, I can get some tools, rent some server capacity, and build and deploy an application that might end up playing at least a bit part in the way a business works. The kicker is that although the cost of “doing stuff” is rapidly tending towards zero, the cost of software failure is at least as high as it’s always been – but the tendency in industry to perpetuate the artificial “wall” between software development and IT operations means that we can easily forget about the cost of failure – and the overall risk to software delivery outcomes – until it’s too late.
Thirdly, each time we’ve turned through the cycle, the distinction between “software” and “service” has become more and more blurred, as business services have come to depend increasingly on software automation internally, and be delivered to consumers through software-based interfaces externally.
These three factors all point to the desperate need for organisations to be able to better link activities across the whole of the software delivery lifecycle – from upstream activities like portfolio management, demand management and change management right through development, test and build all the way downstream to IT operations.
We need to turn software delivery into a business-driven service – and that means ensuring that business priorities are reflected in *what* work gets done; ensuring that business priorities are reflected in *how* work gets done; and ensuring that individual projects are carried out in the context of a “big picture” of business service delivery. That’s what ALM is all about.
If you’d like to read more about Bola’s thoughts on this subject, check out The dilemma of “good enough” in software quality.
I recently finished some research on the cost and quality benefits of upfront, automated code and design review (i.e. prior to and during the development and build process) through static analysis. One of my conclusions was that the case for “good enough” is no longer good enough in delivering software. But some might argue that this viewpoint is promoting the notion of static analysis as a means of perfecting something – “gilding the lily” – rather than an essential tool for knowing whether something is “good enough”.
Not so. In many fields, it is widely accepted that it is not necessary to apply a rigorous quality or testing schedule without first understanding what is at stake, what the risks might be in the event of failure and the severity of those risk. And from there deducing the level of, and appropriateness of, testing techniques, processes and tools to ensure that what is delivered is fit for purpose or “good enough”.
In software delivery I would argue that too often the desire to deliver something quickly – especially to meet a deadline, however ambitious or unrealistic – overrides the key question of (fully determining) whether what is being delivered is actually “good enough”.
The attitude of ‘good enough’ has been hijacked as an excuse for “sloppy” attitudes and processes and a “lets suck it and see” mentality. Surely such an attitude cannot continue to exist in delivering software that is increasingly underpinning business critical applications?
It is, you could say, a problem of managing expectations. A one star hotel probably offers adequate and “good enough” services for those on a budget. But this would not be sufficient for five-star luxury seekers. The key, though, is that customers of each know what they are getting for their money and whether it is fit for their purpose. There is a quantifiable means of grading what is delivered and matching that to what is expected.
Software technology advances allow varying levels of sophistication and capabilities and enable much more to be achieved. Software is increasingly becoming deep rooted in every aspect of our modern lives. New business models are being founded on applications and systems developed with many of these new technologies and approaches. If organisations start to restructure their working practices around applications and systems which rely on the new generation of communication and collaboration technologies and approaches, then failure due to poor code or application quality becomes even less acceptable.
The inclusion of rich media and visuals; the push for greater collaboration through the Internet; and unified communications for richer interactive social or work activities, means that any failure in such services would not only have the potential of creating higher levels of frustration – it would reduce productivity more sharply. On top of this, company brands become more easily exposed to damage.
Increasingly when people buy or use software they expect, if not 5-star performance, then performance and quality that is at least “good enough”.
How many companies can rigorously look at their testing programs and say that is what they are delivering?
If you set out to deliver something that is important then applying the sloppy, suck-it-and-see “good enough” mentality just doesn’t stand up.
What I find incredible after all this time – given the weight of evidence and eminent studies on the cost savings and the growing complexity and importance of software in our modern lives – is that the “sloppy” mentality and attitude still holds such sway in software delivery processes.
Many organisations don’t spend nearly enough effort on improving the quality of the software they produce. More often than not they pay lip service to the concept whilst secretly holding the belief that it is a waste of resources (time, staff and money). As I stated at the start, the reality couldn’t be further from the truth. In a future blog and report I will examine and discuss the evidence in more detail.
Clearly there is more to this debate: especially as we place a greater reliance on software and grapple with the growing pressure to release new features and functions more quickly both to differentiate in the market and to gauge users’ reactions and acceptance.
Is it better to just get something out there that is of reasonable quality and worry about more deep-rooted bugs later, since it is a well known fact that software is never flawless?
This certainly is the option taken by many in the business of delivering software who have met with varying degrees of success and, if you are on the receiving end, – frustration, disappointment and loss.
In the end it boils down to one’s interpretation of “good enough” and the answer to the intriguing questions: who and what should dictate what constitutes “good enough” software quality and how do you go about governing it?
If you are looking to answer these questions you will need to adopt a combination of strategies:
- You will need the support of good processes. Static analysis is certainly one way of improving the processes and being efficient with it. It is a tried and tested means for progressing software quality, predictability and lowering software costs. However, it is not the only tool for software quality. It is part of an arsenal of tools and processes needed for a wider and more lasting, cost effective approach to delivering quality software.
- You will need a clear vision, and an understanding of the goals (business and technical) to establish whether something is actually “good enough”.
- You will need to put in place a connected tools and communication framework to underpin and support your governance process.
