We tolerate poor quality in software to a degree that would be unthinkable for any other kind of engineered product. People have wrestled with this problem since the dawn of computing, and as platforms and architectures evolve it continues to present a moving target.
In 2004, for example, "service-oriented architecture" edged out "Web services" as the preferred label for decentralized systems woven together by the exchange of XML messages. Whatever you call this approach to application development, it presents new quality challenges. As application boundaries extend beyond the enterprise to include partner services, it becomes crucial to monitor and debug your interaction with those services. Mindreef's SOAPScope (reviewed in May) meets this need in an effective way and for a bargain price. With its integration of the Web Services Interoperability Organization's testing tools, version 3.0 of SOAPScope made it easier for developers to create WS-I-compliant services that can work reliably with other such services.
As 3-tier systems increasingly federate with remote services, realtime analysis of system health and application response time becomes essential. So it's no surprise that application performance management products, such as ProactiveNet (reviewed in October), were in demand this year. That trend will accelerate.
...
But 2004 was also a year in which a venerable tactic, source code analysis, emerged in new forms. Agitar Software's Agitator (reviewed in August) reads Java source files, performs data flow analysis, and acts as an intelligent assistant to the developer who is already committed to writing unit tests but needs help formulating testable assertions.
In our November story on the new breed of source code analyzers, we showed how such companies as Coverity and Fortify are revitalizing analysis techniques that many programmers have long thought to be moribund. These tools will work with Java and .NET code, but they don't depend on the fancy machinery built into virtual machines. Their pattern-recognition alogorithms will also ferret out potentially troublesome inconsistencies in C, C++, or SQL code.
Throwing more software at the problem of software quality might seem ironic. But the reality is that high-quality software requires superhuman attention to detail. The right partnerships between computers and programmers will be the key to success, and we continue to find new ways to forge those partnerships. [Full story at InfoWorld.com]
While I shoveled snow for an hour yesterday, I listened to Kent Beck's terrific keynote from the Developer Testing Forum, which was sponsored by Agitar Software and SDForum. Kent makes the point that a healthy relationship between developers and their tools is a necessary, but not sufficient, condition for quality software. What matters more is healthy relationships among team members, managers, and clients. And those relationships thrive, Kent says, when there is pervasive accountability.
The tools mentioned in this article help render software accountable. The methods that Kent has pioneered -- extreme programming, test-driven development -- can help deliver a complementary accountability in the human realm. Here's the crux of the talk, at about the half-hour mark:
I thought accountability meant that if somebody could really call me to account for something -- estimates, functionality, quality of design -- that I was in danger. Somebody's going to put their finger under my nose, and I'm going to feel bad about it. What I've discovered, though, is that it's actually very freeing. Accountability is a way of creating trust.
...
Developer testing is a very simple, mutually beneficial way of being accountable. "Well, what problems were you thinking about when you wrote this software?" If you have the tests, you're prepared to be accountable. "Here's what I was thinking about."
...
Now you have a level of visibility that enables you to create trust in your relationships with your software -- programmers have relationships with their software, it's kind of a sick thing, but we do -- and trust in relationships inside your team -- if somebody changes software that you wrote and a test breaks, that's a whole different deal than if somebody changes software and then weird things happen much later. And you have an opportunity of creating trust relationships with managers, sponsors...and most importantly, with your customers.
It's paradoxical but true that we need more and better software tools in order to keep our software healthy. But as Kent reminds us, we need to be able to use those tools in the context of healthy relationships.
Former URL: http://weblog.infoworld.com/udell/2005/01/07.html#a1146