Insights into how technology and the outsourcing of R&D are changing the software industry

Forrester’s Lisa Visitacion and Mike Gualtieri wrote an interesting report a few months back entitled “Seven Pragmatic Practices To Improve Software Quality” (subscription required). The crux of the report is that development teams are constantly and consistently under pressure to deliver software faster and therefore don’t have the time to implement a true best-in-class quality program. So in lieu of making fundamental changes to your teams’ existing processes, they suggest seven changes that can help you ensure that your software is good enough.

The report provoked a few thoughts from me, which I’ll break into two posts.

First, while each of the recommendations is individually valid, they are also sort of a cop out. I worry anytime I see the word “shortcuts” in a document.   You need to know whether the short cut is saving time and effort (good shortcut) or, to use a construction analogy, is akin to using baling wire and duct tape in structurally important areas (bad short-cut).

Now I do not believe that Forrester is arguing against using fundamentally sound software engineering and testing practices. They are merely trying to provide helpful guidance to make incremental enhancements to existing processes, acknowledging that we don’t live in a perfect world where R&D organizations have the luxury of all the time and resources they want to release perfect products. But, going back to my construction analogy, I think it’s important to know whether you’re adding these improvements to a strong foundation or a house of cards.

One might think that adherence to good software engineering principles is de jure in the technology companies we buy software from. But as a company that works with leading technology companies R&D organizations on product development initiatives, not only in the travel space, but also in the ERP, CRM, BI, Storage and Life Sciences space, I can tell you there is wide variability in the maturity of their engineering processes (in a CMMI-style context). One company’s process is not necessarily better than another’s, they’re just different.

It’s also important to realize that the level a company’s software engineering practices is not as much a reflection of the team’s skill or knowledge, but often a by-product of their collective experience. It’s just human nature – more often than not, you do things as you’ve seen them done before, especially if you’ve achieved successful outcomes in the past. But that does not necessarily make those practices best in class.

Having worked with such a wide community of technology leaders, Ness Software Product Labs has developed best practices around architecture, development and testing and helped our clients improve the effectiveness and efficiency of their software engineering teams and define effective metrics and measures to track their progress.

So while Forrester’s recommendations are good tweaks, they don’t replace the need for a thorough and rational review of your software engineering practices which can measurably and materially enhance the performance of your software engineering organization.

I understand that pushing change through an organization is hard and cannot be implemented overnight, but it’s important that when you undertake any change – major or minor – you understand the projected impact of those changes, and measure them to know whether those expectations are being met.  Will modest enhancements to your process achieve the objectives of the business? If so, great. If not, then you’re wasting energy and need to re-evaluate whether you have to embrace more significant changes, no matter the short-term pain.

In part 2 of the post, I’ll look at each of the “7 Steps” and add a little commentary.