 |
Articles Area
Home Login / Register Browse Articles Search Articles Submit an Article Get RSS Feeds Add Free Article Content Most Viewed Latest Articles Article RatingsGuidelines
Authors PublishersPartners
ArticlesAreaSoftware Product Development--the Unsolved Mystery of High Tech Part II
Submitted by Phil on Sunday Oct 22, 2006 and viewed 2280 timesTotal Word Count: 965
Author Rating: NA
Rate this article
|
Publisher
|
Print
We've covered a lot of what goes wrong in the software development process in Part I. Let's continue that discussion, and look for some answers:
We've covered a lot of what goes wrong in the software development process in Part I. Let's continue that discussion, and look for some answers:
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, post a comment--this is a discussion worth having.
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, post a comment--this is a discussion worth having.
ArticleSource: ArticlesAlley.com
| About the author |
Phil Morettini is President of PJM Consulting, Management Consultants to Tech Companies PJM provides assistance in Management, Product Marketing and Biz Dev. More Articles at http://www.pjmconsult.com/philsblog.html "> Tech Management Blog . Contact Phil at http://www.pjmconsult.com"> Software Management Consulting |
| Additional articles in Programming |
|
| Please Rate This Article |
Number of ratings: 0
Rating: 0
Rating: 0