Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.
This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.
Why Does This Work?
The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.
As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."
Some of the most joyful technical challenges I experienced as a developer were solving application performance problems. Isn't it fun. You are Sherlock Holmes - examining the architecture, diving into the code for clues, and scouring through logs files to find the bottlenecks that are responsible for snail's pace. However, this job is a lot harder than Sherlock Holmes or CSI. It is more like Dr. Gregory House, because you are racing against the clock. For every minute of sluggish performance, you could be losing eyeballs and therefore revenue. Worst case: the patient, i.e., your website, dies.
Performance Problems Are Usually Elevated Because Of A Crisis
Your business just launched a Super Bowl commercial that confidently directed people to your website - #fail. More likely, a new release of software performs like a dog (with apologies to Greyhounds) because of lame coding and nonexistent performance testing.
Cosmopolitan magazine certainly doesn't publish articles such as "Seven Hairstyles That Will Make Your Man Yawn." Wildly desirable is more like it. And so too, is it with great software. If you want your applications to be successful, you better make them wildly desirable.
My latest published research has identified seven key qualities that all applications must exhibit to be wildly desirable, with our choices based on research and inquiries on software design and architecture; assessment advisories with clients; and interviews with leading experts, including both practitioners and academics.
Forrester defines the seven qualities of software as:
The common requirements that all software applications must satisfy to be successful: user experience, availability, performance, scalability, adaptability, security, and economy.
All seven qualities are important, but if you get the user experience (UX) wrong, nothing else matters.
The UX is the part of your application that your employees and/or customers see and use daily. You can do an exceptional job on project management, requirements gathering, data management, testing, and coding, but if the user experience is poor, your results still be mediocre — or even a complete failure.
DevOps is a term used to describe better communication and collaboration between application development professionals and infrastructure operations professionals. "Dev"+"Ops"="DevOps." The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure. I applaud the goal of DevOps to improve the process of deploying application releases.
The last thing many application developers want to do is have a sit-down with the ops guys. Besides which, they don't understand. Sure, the ops guys efforts are critical to our applications because they have to run on something. But, developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps. The goal of NoOps is also to improve the process of deploying applications. But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them. Of course, this is not just about getting virtual machine instances. It is also about release management. Ops can run this public, private, or hybrid infrastructure and give developers the tools they need to responsibly deploy applications faster.
Whoa. My post Java Is A Dead-End For Enterprise App Development received record-breaking readership and passionate comments. Thank you for reading, and thank you for your comments. Clearly it hit a nerve. Many of the comments legitimately called for an expansion of my arguments. Fair enough. I have done that in a 50 slide presentation that I delivered as a teleconference on January 24, 2011. Forrester is making this presentation available to download, free to anyone who registers at the site. Registration is free, so please feel free to register and download the presentation. I welcome your comments on the presentation here, at the original post, or on Twitter.