It's all in the tension. As tightrope walkers make their way across the rope, balancing delicately above a precipitous fall, it's the tension in the rope that enables the journey from one side to the other. Of course, another tension is crucial to the act. In watching the acrobat take one step then the next, we too are tense, hoping the feat is accomplished without incident. As the funambulist (yeah, look it up) finally steps on "solid" ground atop the small platform on the other side, we exhale. The tension makes the act.
Like tightrope walking, software development is in a state of perpetual tension. And much like the tightrope, the tension makes the act. Our "rope" is the constant demand from the world to have software do more and more. Our balance comes from our intuition and our innovation, both in the technologies we apply to help us write and manage more and more code as well as the innovation we receive from advances in hardware capabilities. But without the tension, we would not progress. The demand for new software to solve problems will always be at odds with our ability to produce the amount of software necessary to meet those demands.
Unfortunately, many software development projects run the risk of losing their balance. Last year, Intel fellow Shekhar Borkar said, "The software has to...start following Moore's Law. Software has to double the amount of parallelism that it can support every two years." For the last 60 years, we've relied on faster processors and more disk space to enable key technology innovations like the compiler, the IDE, source code management, continuous builds, and so on; now, rather than a blessing, "more speed" adds to the tension. Not only do we have to add more features, we must figure out how to make both existing and new applications work across an ever-increasing number of cores on a single box.
Compounding the tension, the market has also stepped up its demand for software. The pervasiveness of software cannot be ignoredit's not just about having software on every PC or the Web. It's about having software everywhere, from your cell phone to your car to your alarm clock and probably even in toasters (the things that make your breakfast and those pesky Cylons). This new level of pervasiveness means that whatever business you're in, you're probably also in the software business.
The question we face today is, "How can we maintain (or regain) our balance in walking the tightrope of software development?"
Because of the exploding complexity of software development, the demand for more software and the advances in hardware that require even more sophisticated applications, it's time for the software development world to respond with innovations that can restore a natural balance to our endeavors. But what will that innovation be? Well, I can't see into the future, but I think we can take a look at many of the new tool vendors out there to see the direction we are headed. The analyst community has already begun discussion around the concept of ALM 2.0, with the notion that ALM is not sufficient to the task. I agree with this sentiment. The smaller companies that are innovating to fill in this ALM 2.0 picture (like Coverity, the company I work for) all have one thing in common. Each one of us is fundamentally digging deeper and deeper into the inner workings of the entire software system, including the source codehow it's designed, assembled, tested, and released. Some of us are looking for defects and vulnerabilities with sophisticated analysis of the source itself and the runtime of the resulting system. Some of us are enabling productivity through better understanding of build systems. Others are enhancing the way we test by analyzing the code to automatically generate tests or developing ways to instrument binary code to make it more hacker-proof.
The common thread to all of these next-generation tools is the deeper dive into the software system. The innovation that will help us regain our balance as developers is not just in this deeper dive, but in treating the entire software system holistically. It won't be sufficient to just analyze the source, or the assembly process, or the tests that exercise the software. We'll control the tension with technologies that are not just process oriented (like the current ALM suite), but with tools that fundamentally understand and communicate what's happening in a software system at various stages of development. This will enable us to optimize our coding and testing to improve software quality, as well as the productivity of every developer. After that, the crowds will cheer as we reach our platform, ready for the next development challenge to present itself.