One of the most puzzling things in high technology, especially for executives on the business side of things, is the software development process. It's the high tech equivalent to the "Black Hole" phenomenon made famous in Astronomy. Endless resources can be poured into a software development project, yet there never seems to be an end in sight. Monitoring the progress of a software project can be like peering into the darkness of a seemingly bottomless pit.
And why is this so? It seems that in such a typically high tech, yet now familiar activity, we would have long ago figured it out. We're in an age where PCs, with the power of supercomputers from just a few years back, are slapped together like bicycles, and don't cost much more than a bike. You would think that the process of software development would, by now, amount to simply turning a crank--yet it seems it hasn't advanced much since the dawn of the PC age.
I don't mean to be overly dramatic here. But I have been in the high tech and software industries since 1983, and I have never been involved with--or even personally known of a software project--that came in on time and under budget. Never. Not even ONCE. That's pretty incredible. Now, I realize that there are almost certainly examples of on-schedule projects out there, but they are in the overwhelming minority of all software that is developed.
THEY ALWAYS SLIP
It's just accepted in the software business that projects will slip, particularly when the end result is an actual commercial product. The businesses I've been involved in have tried everything. When I've had direct responsibility, we've taken every approach imaginable. We've tried an approach of "No upfront planning"--starting coding as soon as possible. We've tried "extensive and laborious upfront planning"--with a detailed spec, and a prototype, completed prior to initiating production coding. I've seen many projects that tried using intermediate steps, falling between the two extreme approaches above. We've tried to start projects by purchasing as many "pre-written" modules as possible, used various languages and platforms, hired dedicated debugging personnel, tried code-generators, assembled both small teams & large teams, you name it--we've tried it. Project schedules have been written with the utmost conservatism, at the insistence of senior management. No matter. Across a number of different companies, EVERY project has slipped out beyond the wildest nightmares or everyone involved.
ONE LINE OF CODE, TWO WEEK DELAY
Once I asked our lead programmer to change ONE LINE OF CODE in a well-established product. He estimated it would take just a few seconds to make the change, and a few hours to test it. The change would be final by the end of the day, at the latest. Two weeks later I was still waiting for a solid product.
Now, don't misunderstand. I'm not writing this to bash software developers. While not every developer I've worked with over the years has been a world-beater, I've had the fortune to work with quite a number whom I consider to be outstanding. Many have been extremely bright, dedicated and hard working. But no matter how much thought, time and effort went into it, our projects always slipped. A lot. We usually ended up with a commercially successful product, but how much better we could have done, had we figured out a way to bring the product to market on time? The only saving grace was the competition had the same problem.
MORE ART THAN SCIENCE
The reason, I believe, is that writing software remains much more of an art than a science. This statement is a bit surprising, until you look a little deeper. There is certainly much methodology available to guide a team to use sound, time-tested practices in developing software. However, a software program is really just a document written in a foreign language. That's why C++ and Java are called Programming Languages. It's also interesting that many programmers who aren't classically trained in computer science come from an English, Music, or other language background. Just like in writing a novel you are guided by syntax, grammer and writing rules, writing a software program is very similar. In writing a novel you are essentially creating a unique work that has never been done quite the same way before. Also true for a software program. If you knew exactly how the writing of a novel or software program would go before you began, there would be no need to write it--it would have already been done. While there are plenty of rules (representing the science) to writing good software, at the end of the day it's a unique, written creation (the art).
COMPLEXITY OVERWHELMS EXPERIENCE
Another key reason why conquering the software development process has appeared to be impossible, is the vastly increased complexity associated with software projects today. Let's face it, the average piece of software today does a lot more, and is quite a larger in terms of the number of lines of code, than at the dawn of the PC era. The creation of graphical user interfaces really started the explosion in the size of software code. So much more code is needed, to bring the user-friendly products of today to life. And what enabled this, of course, was the dawn of the modern operating systems, especially the overcoming of the 640K limit that the original DOS operating system required PC programs to run in. Windows and other modern operating systems almost eliminated the need to write software efficiently, at least from a code size perspective. Today the embedded systems world is pretty much the last bastion where writing code efficiently lives on--it's pretty much a lost art to most of the software world. It's interesting to speculate--if we were still writing in the 640K box, would software development have evolved to a more predictable science today? Maybe, but the world would be a less productive as a result.
WHAT TO DO FROM A BUSINESS PERSPECTIVE?
As you can tell from this discussion, I don't have a great set of answers on how to bring software to market on time. It's one of the great frustrations of my career. I still strongly believe that getting the best people you can get will make the problem better, even if it can't be solved completely. I also believe in keeping development teams small, with the minimum of structure necessary to run the project. It's also wise, in my opinion, to structure your product releases to be more frequent, while adding fewer new features per release. This should at least minimize the pain of each release slipping, since the slip time of each release should be less. And knowing what you're going to be coding, developing a spec document and sticking to it (no feature creep!) is also sound practice, although I've found it to be no panacea. Beyond that, I'm at a loss. Maybe one of you has a strong opinion on how to bring projects out on time? If so, send me a comment--this is a discussion worth having.
Phil Morettini is the Author and President of PJM Consulting, a Managment Consultancy to Software and High Tech Companies. PJM Consulting executes special, strategic projects and can also supply interim senior management in General Management (CEO, COO, Division Manager), Product Marketing, M&A, Distribution Channels and Business Development. You can contact Phil on the PJM Consulting Website (www.pjmconsult.com) or via email at info@pjmconsult.com
0 comments:
Post a Comment