|
|
| Home - Industry Article - Jul 06 Issue |
Reinventing the Software Development Strategy |
By John Seybold, Chief Technology Officer, Guidewire Software, Inc.
In 1964, Toyota introduced a new car, the Corona, to the American market. In that year, the company, which had previously been known primarily for its Jeep-like Land Cruiser, managed to sell a paltry 2000 units. But sales soared over the next few years as buyers flocked to the new product, and the rest is history. Who would have predicted that this obscure Japanese company, selling a cheap car in tiny numbers into a niche market, would one day come to rule the automotive world and push aside its far more powerful American competitors? Of course, we know now that there was something going on below the surface: Toyota was busily re-inventing the whole way cars were designed and made. As an investor, wouldn't you have loved to know then what everybody knows now? Well, wake up, because the same thing is happening, right now, in the business of writing software.
If you’ve spent much time working on software projects, you probably bear the scars from a “death march” release. This is the kind of release that just won’t come together in a shippable state. You work and you work, but you keep finding bugs, and as soon as you fix one problem, you find another, deeper issue that was previously hidden. The main cause is usually that the team left a huge backlog of known and unknown problems to be fixed at the end of the release. Learn how to overcome the problem, and think from a broader perspective of reinventing your software development strategy.
The backlog always turns out to be larger than you thought it would be, and you wind up in a dispiriting slog to the finish line. This kind of release is awful for the engineers, who fix bugs until their fingers bleed, dispiriting for QA, who find layer after layer of problems, and harrowing for product managers, who have no information to estimate the eventual release date.
One of the difficulties with this kind of release is that you keep on breaking things as you try to fix the problems. You hammer a board down in one place, and sproing! The other end pops up. Even if you have great engineers who are extremely conscientious, most products now are so complicated that it’s almost impossible to predict the long-range impacts of a particular change to the code. Even worse, if every change runs the risk of breaking something new, it becomes virtually impossible to get a sense of progress.
I’ve spent hours in meetings, with product managers asking very reasonable questions like "When is the release going to be shippable?" The QA guys and I would look at each other and shrug. We didn't know. Nobody knew. And that, of course, leads to the kind of agonized scenario planning ("OK, if we have to delay a month, how many customers will be affected?") that's as much fun as breading your hand and sticking it into a deep fryer.
What's New
None of this is new, at least not if you've been around Silicon Valley for a few years. Most companies go through a death march sooner or later. Some survive, some don’t. But what is new is that we are finally, maybe, seeing a glimmer of hope in the form of new developments in tools, process, and product design. These trends are coming together into an integrated development strategy that promises to make software development faster and more predictable.
The general term is “Agile development”, and it’s designed to speed up the development cycle, shorten the feedback loop for market input, reduce the incidence of bugs, and provide greater visibility into the progress of the release. Agile development has been around for a while, and has long had a devoted following. What’s new is that we’re starting to see significant adoption of this approach, and some real evidence that it can make a big difference when applied well.
When I helped to start Guidewire Software, my current company, we vowed that we would find a different way to build products that would reduce the risk of a death march, and we’ve been enthusiastic adopters of the new agile methods. I’ll say more about the results in a minute, but I’ve become convinced that companies that make effective use of the new strategy will prosper relative to their competitors. Like Toyota, they’ll make better products at a lower cost in a shorter time with greater flexibility. Before I explain how it works, let’s go back to the world of car manufacturing for an analogy.
Suppose you had to go back in time to advice the big three automakers how to counter the threat from Toyota. You could try to explain the whole concept of lean manufacturing to a (probably) sceptical audience. But what if you tried to boil it down to a single practice, such that if they really put all their effort in that direction, they’d wind up doing the right things overall? You might try setting a simple goal: "Eliminate all inventory". If you can't carry an inventory, you need to produce cars in a single, seamless, end-to-end process. You have to work with your suppliers to implement just-in-time delivery. The parts that are delivered have to be perfect 100% of the time, because you're not allowed to have any spares hanging around.
The cars have to come off the line perfect because you're not allowed to keep them around for rework. You’d better treat your employees as partners, because one disgruntled guy can wreck the system in a minute. The point is that you can derive the whole strategy from one simple goal; what’s more, everything works together to deliver the result. Note that this prescription, while easy to say, is incredibly hard to achieve, and it requires you to rethink every aspect of the entire manufacturing operation. Which is why it has proven so hard, even after decades of trying, for other manufacturers to match Toyota’s levels of quality and productivity.
No More Death Marches!
What's the corresponding driving principle for software? What’s the goal of the new strategy? Just this: be able to prove the correctness of your system at any time. And when I say "prove", I mean it. I'm talking about proof at the level of a mathematical proof – a logical argument that the code does exactly what you think it should do. Leaving aside the question of how, why would you do want to do this?
First of all, if you could really achieve this goal, you’d have the ability to ship the product any time you wanted to. No more death marches! You’d also have a great sense of progress in a release, because you’d know that what you had already built was actually working. And you’d have much more flexibility to make changes whenever you want, because you would have a way to verify that the changes didn’t break some other part of the system.
How would you actually produce such a proof? The answer is by developing, along with your product, a set of automated, code-level unit tests that exercise every component of your system for every possible combination of inputs and internal states. "But," you gasp, "that's impossible! Our systems are much too complicated!" Well, I didn't say it would be easy! Obviously, for starters, you'll have to figure out how to architect your system so that you can actually prove the pieces correct before assembling them. Think of building a car; it's made of individual pieces, each of which has known characteristics that can be independently verified.
|
|
|
