The Six Mysteries of Software Lameness
As this series continues, I think it is becoming clear where it is going. Yes, I lured some folks in with some pretty attention-getting verbiage, but let's face it. If I had just come out and said "I am planning to do a series of articles about the value of Configuration Management in software projects!" you could have heard the wind blowing and crickets chirping as people avoided this blog like the plague. I might as well say I am doing a series on the value of flossing daily. Hopefully I have gotten the attention of some intelligent people who are really interested in the very real problem of why software is so bad and you will hang around for a while so I can present my views on the problems and what I see as the best solutions.
On the other hand, you may be a hard-core coder who really doesn't care whether or not users are miserable. After all, they are a really clueless herd and no matter what you do, you will never be able to dumb down your software to make it usable enough for them. If this is your view, then thanks for stopping by. I doubt anything here will interest you from this point on. However, if you are one of those programmers, developers, software engineers, or whatever title you have who wants to find the answers to the great mysteries of software lameness, please stick around and feel free to comment when I am clueless.
So what are the great mysteries of software lameness? As I see it, the major unsolved ones are:
1. Why don't users know what they want?
2. Why are requirements never any good?
3. Why does something I could code between midnight and four a.m. take development teams three months to complete?
4. Why does every software project I run across seem to run off the rails about 2/3 of the way through?
5. Why can't software be created like other products?
6. My is management so clueless?
I intend to shed light on all of these mysteries (well, #6 is questionable) with a single approach. As hard as it may be to imagine, I also intend to do it in a way that the phrase "Configuration Management" doesn't send you instantly into REM cycles.
Pretty lofty goals, I agree. But I know something that most "authorities" (meaning "people who have authored a book on the topic, not people who are experts) seem to miss. I did not learn Configuration Management by getting my MBA and studying process theory. I learned it by living years as an increasingly frustrated Software Developer (programmer, engineer, architect, whatever...I had all of those titles) who worked very hard to create good software only to have it changed beyond recognition and hacked up in a last minute panic because the requirements changed, the client ran out of time and/or money, or they suddenly decided that SQL Server was cheaper than Oracle two weeks before deployment to production.
For years I have been saying "There must be a better way to do this!". I believe now that there is. It is not a new development language; each of them have their own set of flaws and frustrations. It is not a new development methodology; I have tried them all and they all end in chaos. It is a simple process that is implemented early on and followed throughout the project.
Oh..I should have warned you before using the "Proce_ _" word. Sorry about that. But don't panic. Please, read on. I am not a Proce_ _ evangelist by any stretch. I believe that the ultimate end of any "Process methodology" is complete paralysis. What good does that do? I mean, if you aren't a government contractor on a cost-plus project?
I have had several readers ask me when I was going to get into anything of substance. The time is here. My next posting will lay the groundwork for what I believe is the best way to avoid the seemingly inevitable trap of death march projects. I promise.
M@
On the other hand, you may be a hard-core coder who really doesn't care whether or not users are miserable. After all, they are a really clueless herd and no matter what you do, you will never be able to dumb down your software to make it usable enough for them. If this is your view, then thanks for stopping by. I doubt anything here will interest you from this point on. However, if you are one of those programmers, developers, software engineers, or whatever title you have who wants to find the answers to the great mysteries of software lameness, please stick around and feel free to comment when I am clueless.
So what are the great mysteries of software lameness? As I see it, the major unsolved ones are:
1. Why don't users know what they want?
2. Why are requirements never any good?
3. Why does something I could code between midnight and four a.m. take development teams three months to complete?
4. Why does every software project I run across seem to run off the rails about 2/3 of the way through?
5. Why can't software be created like other products?
6. My is management so clueless?
I intend to shed light on all of these mysteries (well, #6 is questionable) with a single approach. As hard as it may be to imagine, I also intend to do it in a way that the phrase "Configuration Management" doesn't send you instantly into REM cycles.
Pretty lofty goals, I agree. But I know something that most "authorities" (meaning "people who have authored a book on the topic, not people who are experts) seem to miss. I did not learn Configuration Management by getting my MBA and studying process theory. I learned it by living years as an increasingly frustrated Software Developer (programmer, engineer, architect, whatever...I had all of those titles) who worked very hard to create good software only to have it changed beyond recognition and hacked up in a last minute panic because the requirements changed, the client ran out of time and/or money, or they suddenly decided that SQL Server was cheaper than Oracle two weeks before deployment to production.
For years I have been saying "There must be a better way to do this!". I believe now that there is. It is not a new development language; each of them have their own set of flaws and frustrations. It is not a new development methodology; I have tried them all and they all end in chaos. It is a simple process that is implemented early on and followed throughout the project.
Oh..I should have warned you before using the "Proce_ _" word. Sorry about that. But don't panic. Please, read on. I am not a Proce_ _ evangelist by any stretch. I believe that the ultimate end of any "Process methodology" is complete paralysis. What good does that do? I mean, if you aren't a government contractor on a cost-plus project?
I have had several readers ask me when I was going to get into anything of substance. The time is here. My next posting will lay the groundwork for what I believe is the best way to avoid the seemingly inevitable trap of death march projects. I promise.
M@
[0] Comments:
Post a Comment
<< Home