?Light Methodology? is like ?Lite Beer?. You need to drink more lite beer to get the same high as in regular beer. This makes light methodology a very shallow effort. ?This is what you need because a technician built it.? So what, if it doesn?t fit your business model. Change the model.
If you have to be so innovative that you sand the veneer to the parent material you have nothing. This sounds like more "no legal authorizing authority". There is no shortcut to good work just lack of motivation (laziness). This sounds more like I can name that tune in less notes than you can. The technophiles continue to attempt to produce a process that separates themselves from the company so that only shrink wrapped products are delivered with no need for any communication up front.
But, this is good. We must get to ridiculous so that we can return to the truth and those methods that work.
Discussion on:
View:
Show:
I'm not sure whether it's because Rick's short interview didn't bring it out or what, but plantogo is missing the point of Jim Highsmith's work, and the work of the other light methods folks, if he really thinks it is trying to separate itself from the company.
On the contrary, the light methodology movement is notable for its close contact with the folks with the need, and a continuous, iterative, testing approach to building what is really needed.
I'd suggest that interested parties check out Jim Highsmith's book, Kent Beck's, or even mine, to find out what light methods are really all about.
On the contrary, the light methodology movement is notable for its close contact with the folks with the need, and a continuous, iterative, testing approach to building what is really needed.
I'd suggest that interested parties check out Jim Highsmith's book, Kent Beck's, or even mine, to find out what light methods are really all about.
Just a quick note to remind readers that my interviews are not advocacy pieces - I chat wtih leaders in our industry to give all concepts and ideas a fair hearing, and let the readers and the TechRepublic community make the decision. Anyony who has read my book knows that I revere the gurus of structured programming like Yourdon and Orr, but new situations require new thinking. I'm gratified by the heat generated by this (although I hope we can keep the discourse civil), as it indicates the depth of our passion for delivering good results.
Stay tuned for part two of the Highsmith interview, which will reveal much more about the workings of this, its successes and its risks.
Stay tuned for part two of the Highsmith interview, which will reveal much more about the workings of this, its successes and its risks.
I read Adaptive Software Development during the summer. It was very interesting and easy to read. One point that was made, germane to this discussion, stuck with me. He stated/suggested (I'm not quoting) a necessary condition to make his approachwork was the use of top-notch people.
My experience is that a team of "top-notch" people will make just about anything work regardless of the approach. However, the reality of the work place is that the talent level is at best, a normal distribution.
Taking a "lite" approach with less than a top-notch team is risky. However, being risky does not mean some circumstances will not warrant doing so.
It all boils down to there is a time and a place for lite, but not always.
My experience is that a team of "top-notch" people will make just about anything work regardless of the approach. However, the reality of the work place is that the talent level is at best, a normal distribution.
Taking a "lite" approach with less than a top-notch team is risky. However, being risky does not mean some circumstances will not warrant doing so.
It all boils down to there is a time and a place for lite, but not always.
When people make up their mind and place their being behind anyhting they have to defend it even when they are wrong.
The custoemr must drive the process and a "lite planning" process excludes the customer. The supposition that involving those people that operate the system is the user is bolderdash and your book should cover that.
It is my opinion that IT continues to try and wag the dog and too may IT professionals think they and their process should run the company.
Gene
plantogo2hotmail.com
http://www.internetservices.bigstep.com
When a person makes up their mind and goes public, it is difficult (impossible) to get them to change their mind in light of another perspective. It ends up being an argument that no one wins.
Yours and the other persons you reference are wrong. The customer must drive the process and a "lite methodology" directed at serving the needs of the technical community (no matter how hard they try) doesn't meet the needs of the customer unless the customer is involved at a minimum through the seniormanagers of the company.
This thought process - using tactics instead of strategy - and especially IT processes (tactics) continues to be the reason for the 40% implementation failure rate.
Gene
plantogo@hotmail.com
http://www.internetservices.bigstep.com
Although I'm in Florida and the "light methodologies" expert is in Kansas City, I can still detect the pungent aroma of manure when reading his cop-out for not properly documenting a project. This is a battle I've fought throughout my career - pooror missing documentation, including source code comments. Documentation - before the fact - clarifies the design and uncovers fatal flaws before they're deployed. If you can't communicate the project's vision in plain English, how will you ever get a stupid machine to understand your coded translation?
In my not-so-humble opinion, the "light methodologies" endorsement is little more than a "license to hack."
//jm
In my not-so-humble opinion, the "light methodologies" endorsement is little more than a "license to hack."
//jm
I take exception to this methodology. Too many pojects have failed even with detail planning. Now we hear we must 'speculate' on requirements instead. I wonder how many projects which used Light Methodology have been implemented successfully. Lack of documentation is a major contributor to high costs in maintenance. Documenting every phase of the project along with quality control and scope control go a long way towards successfull implementation. There is no substitute for this.
Thank You, jgibbons, I couldn't agree more!
"Lite" methodologies are what the marketing-type spin-doctoring wishful thinkers believe will work. There is no substitute for good planning and up-front engineering. All attempts to shorten the process by eliminating good engineering practice actually adds time and cost to the project in the long run. These "get it done quick" people just don't get it. There IS NO free lunch.
Please, hypesters, leave the engineering to the engineers.
"Lite" methodologies are what the marketing-type spin-doctoring wishful thinkers believe will work. There is no substitute for good planning and up-front engineering. All attempts to shorten the process by eliminating good engineering practice actually adds time and cost to the project in the long run. These "get it done quick" people just don't get it. There IS NO free lunch.
Please, hypesters, leave the engineering to the engineers.
Good engineering isn't necessarily up-front engineering. Change requires continuous engineering--the extreme programming practice of refactoring for example.
Documentation isn't understanding. Just because there is a 100 page requirements spec doesn't mean the development team really understands what to do. Understanding comes from interaction, not merely documentation.
Having written, sold, installed, taught, and used "heavy methodologies" for 15 years, and having implemented 50+ light methodology projects over the past 10 years, I have plenty of evidence it's more than hype.
What my clients that are CMM level 3 & 4 are saying is that they will continue to use their heavy practices for many projects, but for those that require speed, quality, and frequent requirements changes as projects evolve, they will depend on "ligher" approaches.
--Jim
Documentation isn't understanding. Just because there is a 100 page requirements spec doesn't mean the development team really understands what to do. Understanding comes from interaction, not merely documentation.
Having written, sold, installed, taught, and used "heavy methodologies" for 15 years, and having implemented 50+ light methodology projects over the past 10 years, I have plenty of evidence it's more than hype.
What my clients that are CMM level 3 & 4 are saying is that they will continue to use their heavy practices for many projects, but for those that require speed, quality, and frequent requirements changes as projects evolve, they will depend on "ligher" approaches.
--Jim
First, Good Engineering, is, necessarily, up-front. It is correct to say that the engineering process is continuous but "refactoring" is simply a euphemism for "hack and fix".
Second, good documentation (and I stress the "good") is, in fact, understanding. Someone had to write it. In order to write it some understanding had to have taken place. But if the documentation is not read and understood then it is nothing more than a block of paper. Understanding comes not only from interaction but also from reading, understanding, and following writings like, for instance, textbooks, user manuals, and good software documentation. If I'm wrong about this, then Gutenburg wasted a lot of time. Didn't you just write a book, Jim? Do you findit necessary to go on the road and "interact" with your readers so they can understand what you wrote?
My 27+ years of experience has led me to, obviously, different conslusions about what works and what doesn't work as far as software development is concerned. Whether a project is a success or not very much depends on who is doing the evaluation. I have seen many a projects where buggy code was foisted upon the poor users but was declared a "success" by management.
The issues, I think, boil down to philosophy. What's more important, quality of code or minimum time to market? Everyone wants both but when the inevitable problems arise, which aspect suffers. The marketeers will tell you that the deadline is paramount, an engineer will say that quality is the most important thing. A decision must be made. What happens? The golden rule applies. He who has the gold makes the rules and we (all users of software) wind up with lousy software.
In the final analysis, I need not worry. I fully expect that the so-called "light" methodologies will die a death similar to RAD and we can all get back to taking our time and doing things right.
Second, good documentation (and I stress the "good") is, in fact, understanding. Someone had to write it. In order to write it some understanding had to have taken place. But if the documentation is not read and understood then it is nothing more than a block of paper. Understanding comes not only from interaction but also from reading, understanding, and following writings like, for instance, textbooks, user manuals, and good software documentation. If I'm wrong about this, then Gutenburg wasted a lot of time. Didn't you just write a book, Jim? Do you findit necessary to go on the road and "interact" with your readers so they can understand what you wrote?
My 27+ years of experience has led me to, obviously, different conslusions about what works and what doesn't work as far as software development is concerned. Whether a project is a success or not very much depends on who is doing the evaluation. I have seen many a projects where buggy code was foisted upon the poor users but was declared a "success" by management.
The issues, I think, boil down to philosophy. What's more important, quality of code or minimum time to market? Everyone wants both but when the inevitable problems arise, which aspect suffers. The marketeers will tell you that the deadline is paramount, an engineer will say that quality is the most important thing. A decision must be made. What happens? The golden rule applies. He who has the gold makes the rules and we (all users of software) wind up with lousy software.
In the final analysis, I need not worry. I fully expect that the so-called "light" methodologies will die a death similar to RAD and we can all get back to taking our time and doing things right.
The defining difference between light and heavy methods is that heavy methods focus on a single massive development pass, while the light methods rely on multiple, small development passes.
In a heavy method, you are trying to develop everything at once, with no recourse if any phase is less than perfect. You develop a complete requirements document and get it signed off by the user. Any additions, modifications, or clarifications to this document are extremely difficult to make. The document is viewed as being "perfect." This also has the effect of giving all requirements equal priority, so that implementation work on the most important capability does not begin until the requirements definition of the least important capability iscomplete. The same applies to implementation and test, until the least important capability is implemented, there is no system test for the most important capabilities.
The light methods tend to use an iterative approach. Put a high degree of focus on a small number of the most critical items and carry them to completion. Then repeat for the next most critical items. This allows everyone to sequentially focus on a small number of items at a time and ensure that the most ciritical items get tested proportionally more times than the least critical items.
Light methods aren't about getting "it" done quickly, but getting the most critical items done first. This is very customer driven because the customer can begin to review the real thing as soon as possible, not merely review an abstract paper document.
In a heavy method, you are trying to develop everything at once, with no recourse if any phase is less than perfect. You develop a complete requirements document and get it signed off by the user. Any additions, modifications, or clarifications to this document are extremely difficult to make. The document is viewed as being "perfect." This also has the effect of giving all requirements equal priority, so that implementation work on the most important capability does not begin until the requirements definition of the least important capability iscomplete. The same applies to implementation and test, until the least important capability is implemented, there is no system test for the most important capabilities.
The light methods tend to use an iterative approach. Put a high degree of focus on a small number of the most critical items and carry them to completion. Then repeat for the next most critical items. This allows everyone to sequentially focus on a small number of items at a time and ensure that the most ciritical items get tested proportionally more times than the least critical items.
Light methods aren't about getting "it" done quickly, but getting the most critical items done first. This is very customer driven because the customer can begin to review the real thing as soon as possible, not merely review an abstract paper document.
I couldn't agree more with the idea of doing the more critical items before the less important ones. This idea doesn't have anything to do with the "Lite" vs. "Heavy" discussion. Methodologies in both camps allow for this approach.
In my opinion, the "Holy Grail" of Software Engineering is to be able to produce error-free, working applications directly from the specification of the requirements employing bre-build re-usable components that will execute on any platform. We are much closer to accomplishing this than you might think. Read some of the recent papers published in the IEEE Transactions on Software Engineering to see what I mean. In order for this goal to become a reality, it is absolutely necessary to get good at requirements specifications. In this way, any changes in the requirements can be immediately implemented regardless of the time frame. These so-called "light" methodologies are not moving us in the direction toward that goal. They are, at best, only a stop-gap measure that can be used until the sophistication of software development grows into a true engineering discipline like electrical engineering is for hardware development.
In my opinion, the "Holy Grail" of Software Engineering is to be able to produce error-free, working applications directly from the specification of the requirements employing bre-build re-usable components that will execute on any platform. We are much closer to accomplishing this than you might think. Read some of the recent papers published in the IEEE Transactions on Software Engineering to see what I mean. In order for this goal to become a reality, it is absolutely necessary to get good at requirements specifications. In this way, any changes in the requirements can be immediately implemented regardless of the time frame. These so-called "light" methodologies are not moving us in the direction toward that goal. They are, at best, only a stop-gap measure that can be used until the sophistication of software development grows into a true engineering discipline like electrical engineering is for hardware development.
Hardware engineering over the last 30+ years has been going away from the thorough requirements approach and instead embracing a flexible design approach, even with added recurring costs.
The first push in this direction came from the microprocessor, allowing functionality to be defined afterwards via software. Then, backplanes to allow new hardware functions to be added. There has been a shift from mask ROMs to FLASH. The use of PLDs, FPGAs. The end result, is that detailed user requirements are no longer necessary to begin (or complete) hardware development.
The same forces that caused the shift in hardware design from thorough requirements definitions to flexible design are acting on software development. As software grows larger and more complex, it becomes more and more difficult to perform thorough requirements analysis. Instead, the focus needs to shift to flexible design and the addition of requirements on an as needed basis. This is what the light methods are all about.
The first push in this direction came from the microprocessor, allowing functionality to be defined afterwards via software. Then, backplanes to allow new hardware functions to be added. There has been a shift from mask ROMs to FLASH. The use of PLDs, FPGAs. The end result, is that detailed user requirements are no longer necessary to begin (or complete) hardware development.
The same forces that caused the shift in hardware design from thorough requirements definitions to flexible design are acting on software development. As software grows larger and more complex, it becomes more and more difficult to perform thorough requirements analysis. Instead, the focus needs to shift to flexible design and the addition of requirements on an as needed basis. This is what the light methods are all about.
The quickest and most reliable method to verify a requirement is to put the actual product in front of a user and ask "Is this correct and complete?"
Massive paper requirements documents have been problematic in this area. The more detailed the specification becomes, the harder it is to review. Making the document easier to review leaves much detail open to interpretation during development.
The economics of change in software are dependent upon the flexibility inherent in the software. This is usually described as the level of "coupling" within the software (looser coupling is better). Loose coupling is the primary advantage of first object oreinted programming and now components. The "reuse" argument is primarily raised by academics and is an approach which has no analogy in any other design endeavor. Why should it magically apply to software?
Requirement specification needs to be viewed as an ongoing activity, not as a phse to be completed. It is a slippery slope to believe that "if we only work a little bit harder, we can do a perfect requirements specification." It is much better to do micro-development iterations and get a true product level requirement validation as uickly as possible. This is the direction being pushed by the light methods.
Massive paper requirements documents have been problematic in this area. The more detailed the specification becomes, the harder it is to review. Making the document easier to review leaves much detail open to interpretation during development.
The economics of change in software are dependent upon the flexibility inherent in the software. This is usually described as the level of "coupling" within the software (looser coupling is better). Loose coupling is the primary advantage of first object oreinted programming and now components. The "reuse" argument is primarily raised by academics and is an approach which has no analogy in any other design endeavor. Why should it magically apply to software?
Requirement specification needs to be viewed as an ongoing activity, not as a phse to be completed. It is a slippery slope to believe that "if we only work a little bit harder, we can do a perfect requirements specification." It is much better to do micro-development iterations and get a true product level requirement validation as uickly as possible. This is the direction being pushed by the light methods.
Messrs. Freedman and Highsmith see the world from the same view.
Of the eleven comments only three with two of them from the authors were advocating a light methodology. Is this significant? I think so.
The observation that Mr. Highsmith works at the CMM level (I am guessing this is some abbreviation for corporate management at the executive level) and that maybe is why his light method works for him and doesn't work for the people who are providing comments and are in the trenches not at the corporate level.
We all know what corporate wants - to justify their existence. It is not my intention to make this exchange critical or abusive as suggested it might go in the second comment and if it is, I apologize for your opinion.
The conclusion here and there should be one, is that outside of one contrary opinion, the comments made were against a light methodology approach.
Even if Mr. Highstreet has had tremendous success, he cannot refute the comments made and after my own 30 years of experience am not prepared to start drinking ?lite beer? because it demands twice as much the calories.
Gene
http://www.internetservices.bigstep.com
Of the eleven comments only three with two of them from the authors were advocating a light methodology. Is this significant? I think so.
The observation that Mr. Highsmith works at the CMM level (I am guessing this is some abbreviation for corporate management at the executive level) and that maybe is why his light method works for him and doesn't work for the people who are providing comments and are in the trenches not at the corporate level.
We all know what corporate wants - to justify their existence. It is not my intention to make this exchange critical or abusive as suggested it might go in the second comment and if it is, I apologize for your opinion.
The conclusion here and there should be one, is that outside of one contrary opinion, the comments made were against a light methodology approach.
Even if Mr. Highstreet has had tremendous success, he cannot refute the comments made and after my own 30 years of experience am not prepared to start drinking ?lite beer? because it demands twice as much the calories.
Gene
http://www.internetservices.bigstep.com
Gene, sadly you are showing a fair degree of ignorance, and making generalised statements based on such.
CMM stands for the Corporate Maturity Model, a framework for rating organisations' ability to repeatedly produce quality output. CMM levels 4 and 5 are highly process-centric, and consequently organisations that operate at these levels are those that can demonstrably produce products of high quality, repeat previously succesful projects w/out repeating mistakes, and constantly measure and re-evaluate their own processes - all at a cost.
These high maturity levels are applicable to organisations that produce, for example, life-critical systems - military weapons, automatic flight-control systems, medical robotic instrumentation control systems - where requirements are stable and a high cost is justified.
Mr. Highsmith says that in such scenarios a light methodology may not be the most appropriate since usually requirements are constant and clear, and auditability of process is more NB than rapid delivery. In scenarios where the opposite may be true, a light methodology may be preferable to a highly process-centric methodology which tries to impose a predictable plan on an unpredictable environment.
The result (andI'm now talking from my own experience) is a disappointed client, cancelled projects, burnt-out teams and unmet business targets. By the way this view is rapidly gaining acceptance, and has proponents from technical, project management and businessmanagement backgrounds.
No one is trying to impose anything on anyone here, the LM movement is proposing an alternative methodology for delivering projects in a fast-changing business environment. YOU are free to reject it if you do not believe it will help YOU. Rejecting it on behalf of everyone, however, especially while clearly demonstrating how little you understand about it, is ungrounded.
- Menahem
CMM stands for the Corporate Maturity Model, a framework for rating organisations' ability to repeatedly produce quality output. CMM levels 4 and 5 are highly process-centric, and consequently organisations that operate at these levels are those that can demonstrably produce products of high quality, repeat previously succesful projects w/out repeating mistakes, and constantly measure and re-evaluate their own processes - all at a cost.
These high maturity levels are applicable to organisations that produce, for example, life-critical systems - military weapons, automatic flight-control systems, medical robotic instrumentation control systems - where requirements are stable and a high cost is justified.
Mr. Highsmith says that in such scenarios a light methodology may not be the most appropriate since usually requirements are constant and clear, and auditability of process is more NB than rapid delivery. In scenarios where the opposite may be true, a light methodology may be preferable to a highly process-centric methodology which tries to impose a predictable plan on an unpredictable environment.
The result (andI'm now talking from my own experience) is a disappointed client, cancelled projects, burnt-out teams and unmet business targets. By the way this view is rapidly gaining acceptance, and has proponents from technical, project management and businessmanagement backgrounds.
No one is trying to impose anything on anyone here, the LM movement is proposing an alternative methodology for delivering projects in a fast-changing business environment. YOU are free to reject it if you do not believe it will help YOU. Rejecting it on behalf of everyone, however, especially while clearly demonstrating how little you understand about it, is ungrounded.
- Menahem
Appologies, I made a small mistake in my reply above - CMM stand for the Capability Maturity Model.
See http://computer.org/seweb/dynabook/PaulkCom.htm for an enlightened look at XP (as representative of light methodologies in general) through the eyes of a CMM practitioner.
- Menahem
See http://computer.org/seweb/dynabook/PaulkCom.htm for an enlightened look at XP (as representative of light methodologies in general) through the eyes of a CMM practitioner.
- Menahem
Amen, Menahem!
I may be too late join this thread, but I'll write anyway. Just discovered this Web site and this "light methodology" this weekend.
Speaking from the "trenches", I agree wholeheartedly with the need for a more flexible approachto software development. I've
been designing/programming since 1961 and have lived through many a project under "heavy" methodology. I've produced
millions of pages of useless, obsolete documentation. I too have seen projects fail or be cancelled after too much money was
spent "up front", or be completed but put on the shelf because they were obsolete or did not actually have any use after all. I
have to admit that years ago I complained a LOT about "poor" requirements and design documentation.
The problem is that the heavy approach assumes that everyone knows it all. The user is not allowed to say "Gee, I don't know
exactly what I need." The software engineer is not allowed to say "I have no idea how to solve this problem. I'll have to just
get in there and figure it out as I go." However, in a very complex system where you're about to do something that has not been
done before, that's reality. Believe me, I'm not saying this because I'm stupid or lazy or can't write!
For the last several years, I've had the opportunity to "go light" because I've had to produce software in a tiny fraction of the
time one would normally allot. They were very successful. Perhaps this is possible because we have the tools and the power to
produce software so quickly. We can redesign large areas, re-use code, compile, link and test in minutes what would have
taken weeks or months in the 80s.
Using a light methodology should not imply hacking. Good coding and software engineering principles must still be followed.
From my experience the difference in good code and maintainability is not a function of how complete the design and
I may be too late join this thread, but I'll write anyway. Just discovered this Web site and this "light methodology" this weekend.
Speaking from the "trenches", I agree wholeheartedly with the need for a more flexible approachto software development. I've
been designing/programming since 1961 and have lived through many a project under "heavy" methodology. I've produced
millions of pages of useless, obsolete documentation. I too have seen projects fail or be cancelled after too much money was
spent "up front", or be completed but put on the shelf because they were obsolete or did not actually have any use after all. I
have to admit that years ago I complained a LOT about "poor" requirements and design documentation.
The problem is that the heavy approach assumes that everyone knows it all. The user is not allowed to say "Gee, I don't know
exactly what I need." The software engineer is not allowed to say "I have no idea how to solve this problem. I'll have to just
get in there and figure it out as I go." However, in a very complex system where you're about to do something that has not been
done before, that's reality. Believe me, I'm not saying this because I'm stupid or lazy or can't write!
For the last several years, I've had the opportunity to "go light" because I've had to produce software in a tiny fraction of the
time one would normally allot. They were very successful. Perhaps this is possible because we have the tools and the power to
produce software so quickly. We can redesign large areas, re-use code, compile, link and test in minutes what would have
taken weeks or months in the 80s.
Using a light methodology should not imply hacking. Good coding and software engineering principles must still be followed.
From my experience the difference in good code and maintainability is not a function of how complete the design and
The misunderstanding is that it isn't light versus heavy. Its light verus KISS.
It is evident that the positions taken are based on everyone's own impressions (assumptions) and they are not the same for everyone.
Light is a poor choice because it short circuits baic requirements. The heavy is not a lot of "stuff" at the process implementation level.
The answer is top level executive invovement and support operating from an enterprise vision with a strategy and leadership that delivers forthe customer what the customer wants and needs.
It is evident that the positions taken are based on everyone's own impressions (assumptions) and they are not the same for everyone.
Light is a poor choice because it short circuits baic requirements. The heavy is not a lot of "stuff" at the process implementation level.
The answer is top level executive invovement and support operating from an enterprise vision with a strategy and leadership that delivers forthe customer what the customer wants and needs.
You are right, I am ignorant and you have the light stone tablets that are saving the IT world. Congratualtions on being so brilliant.
By the way, did you die on a cross? You and Mr. Highsmith deserve each other.
With IT projects running at an 80% failure rate (I know yours never fail and you are part of the 20%) any light mehtodology is going to save the world.
Thank you again for your refreshing input and your insight.
By the way, did you die on a cross? You and Mr. Highsmith deserve each other.
With IT projects running at an 80% failure rate (I know yours never fail and you are part of the 20%) any light mehtodology is going to save the world.
Thank you again for your refreshing input and your insight.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
