Home > Archive > Software Engineering > April 2007 > Agile Development: "Think Big, Start Small!"
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Agile Development: "Think Big, Start Small!"
|
|
|
|
| H. S. Lahman 2007-04-08, 7:02 pm |
| Responding to Kelly.waters...
> Many software development projects fail simply because they are too
> big...
>
> http://kw-agiledevelopment.blogspot...tart-small.html
Using IID for development has nothing to do with project size per se; it
is just a standard technique for managing complexity that has been
around for decades.
When I started out in the '50s a 100 KLOC BAL application was virtually
unmanageable. In the '60s it was commonly estimated that a 1 MLOC 3GL
application would take 1K developers a decade to complete. Today MLOC
applications are the norm. So we have come a long way in our ability to
manage complexity.
The corollary is that project size inherently has little to do with
project failure. Projects fail because the available software
development processes are inadequate to deal with projects on the tail
end of the current project size distributions. That's a process
engineering problem, not a size problem.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| H. S. Lahman wrote:
> Responding to Kelly.waters...
>
>
> Using IID for development has nothing to do with project size per se; it
> is just a standard technique for managing complexity that has been around
> for decades.
If you had read the article, instead of just the teaser, Kelly means "big
requirements up front" is bad. Not "big projects are bad". Just-in-time
requirements are always better.
And it doesn't say IID hasn't been around for decades. Don't jerk your knee
so easily.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html
| |
| Gabriel Claramunt 2007-04-08, 7:02 pm |
| For me, the article seems to be about delivering software in small
incremental releases...(but I'm no expert in english :-) )
Anyway, they're very good practices, if people need to label them as "agile"
to use them, it's ok.
I just think it would be better if they know where those ideas come from...
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:k59Sh.6742$u03.5934@newssvr21.news.prodigy.net...
> H. S. Lahman wrote:
>
>
> If you had read the article, instead of just the teaser, Kelly means "big
> requirements up front" is bad. Not "big projects are bad". Just-in-time
> requirements are always better.
>
> And it doesn't say IID hasn't been around for decades. Don't jerk your
> knee so easily.
>
> --
> Phlip
> http://flea.sourceforge.net/PiglegToo_1.html
>
| |
|
| Gabriel Claramunt wrote:
> For me, the article seems to be about delivering software in small
> incremental releases...(but I'm no expert in english :-) )
> Anyway, they're very good practices, if people need to label them as
> "agile" to use them, it's ok.
When the "agile" concept was in early adoption, one of the cheap shots by
its detractors was "this isn't new; stop claiming you invented it!"
I have heard with my own ears bosses say, "Okay, we are going to do the
project again, and this time we will collect all the requirements first!"
If the word ain't out, then we need to keep saying it and saying it, in as
many different ways as we can: Just-in-time requirements are lower risk!
> I just think it would be better if they know where those ideas come
> from...
The software for the Mercury program was written nearly test-first, with
daily builds and a w ly iteration schedule.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html
| |
|
|
|
| Roy Smith wrote:
> I'm starting to think "Agile" is one of those words which has come to mean
> pretty much whatever somebody wants it to mean. For example, I'm working
> with a customer now who has recently drunk the Agile Kool-Aide. They've
> declared that they're going to use an Agile process on the current big
> hairy project.
Well, reliance on teamwork over planning might be "Agile"...
> Last w I was given a spreadsheet showing the project plan. The project
> is going to take 18 ws, using 2-w iterations. They've already got
> all 9 iterations planned out, with milestones for each one.
That's Big Agile Up Front.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html
| |
| H. S. Lahman 2007-04-09, 10:04 pm |
| Responding to Phlip...
I don't think you should have gone here. You hit a lot of Hot Buttons...
>
>
> If you had read the article, instead of just the teaser, Kelly means "big
> requirements up front" is bad. Not "big projects are bad". Just-in-time
> requirements are always better.
I did read the article; I just chose to ignore the mantras. IMO, the
article was very clear that projects fail because they are big and the
the answer is IID to break them up into more manageable pieces. (Note
that the OP and Claramunt got the same impression.) IOW, the article was
just putting a different spin on the Waterfalls Are Bad chestnut and the
BDUF mantra was replaced by the BRUF mantra.
[Just out of curiosity, does Scrum own BRUF while XP owns BDUF or has
BDUF been replaced by BRUF as the straw man de jour in the whole
OOP-based agile community?]
> And it doesn't say IID hasn't been around for decades. Don't jerk your knee
> so easily.
My point was that despite the mantras there is nothing inherent in big
projects that causes failure any more than there is something inherent
in waterfall models that causes failure. In both cases one addresses
problems as they are encountered by using standard techniques like IID.
More to the point, the same requirements always get resolved by the time
the product is released so there is nothing inherently wrong with having
a lot of requirements and IID happens to be one of several standard
techniques for managing a lot of requirements.
Phlip, there are lots of good things about XP in the right environment.
(I know the author was a scrummer; it is just easier to type XP than
"OOP-based agile processes".) But I have a lot of problems with the
people that market it like the article author. To paraphrase G. B. Shaw
on Christianity, the only problems with XP are the XPers.
One thing that annoys the hell out of me is this ubiquitous Marketing by
Mantras where straw men like Waterfall, BDUF, and BRUF are sloganized
and demonized. The XP community reminds me of sitting around a bong in
the '60s and someone brightens things up by saying, "Power to the
People!". To which everyone else in the Club responds, "Right on, Man!".
It also annoys the hell out of me that the XP marketeers present things
like IID, test-first, and even CRC cards in Sermon On The Mount mode as
if they invented them. (There is wikipedia entry that actually claims
that Beck and Cunningham invented CRC cards in 1989!) The author may not
have said that IID is a brand new idea, but it sure was presented as
new, cutting-edge technology. The author demonized big projects and BRUF
as intrinsically evil and then presented a detailed ritual to cast them
out without ever mentioning that it was a standard technique called IID.
The only thing the author could have done to present IID in a more
proprietary and religious would have been to write the article in latin.
It is that kind of marketing crap that is getting my knee up, not IID or
the processes institutionalizing it.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Phlip 2007-04-09, 10:04 pm |
| H. S. Lahman wrote:
> I did read the article; I just chose to ignore the mantras.
....
> [Just out of curiosity, does Scrum own BRUF while XP owns BDUF or has
> BDUF been replaced by BRUF as the straw man de jour in the whole
> OOP-based agile community?]
Next time read the "mantras".
No Agile process recommends BRUF; all decry it.
--
Phlip
| |
| kelly.waters 2007-04-14, 10:05 pm |
| On 8 Apr, 22:39, "Phlip" <phlip...@yahoo.com> wrote:
> Roy Smith wrote:
>
> Well, reliance on teamwork over planning might be "Agile"...
>
>
> That's Big Agile Up Front.
>
> --
> Phlip
> http://flea.sourceforge.net/PiglegToo_1.html
Hi all,
I don't think waterfall is bad btw, I wouldn't advoate agile in all
situations. I just personally prefer agile in my current situation.
I think there are times when agile is good, times when waterfall is
good, and times when you can mix the principles of both with enough
experience. In one of my earliest posts, I describe 10 key principles
of agile development and say...
"In reality there is no magic bullet for software development. The
real trick is to know lots of techniques from various Waterfall and
Agile Development methods, and to select a mixture of the best
approaches that are most appropriate for any given situation. To do
this reliably with any degree of success really requires a lot of
experience and skill."
Full post if you're interested is here:
http://kw-agiledevelopment.blogspot...bout-agile.html
Kelly Waters
http://www.allaboutagile.com
| |
|
|
"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:xQtSh.4441$Lm.1400@trndny05...
> Responding to Phlip...
>
> One thing that annoys the hell out of me is this ubiquitous Marketing by
> Mantras where straw men like Waterfall, BDUF, and BRUF are sloganized and
> demonized. The XP community reminds me of sitting around a bong in the '60s
> and someone brightens things up by saying, "Power to the People!". To which
> everyone else in the Club responds, "Right on, Man!".
>
I have been around this business about as long as Lahman. And I too have
seen a succession of mantras, gimmicks, definitive solutions, and clever ideas
that were intended to finally solve the problem of building good software. For
me, after watching these bright ideas come and go, the Agile religion is just
another in that succession.
There was a study in the field of clinical psychology to determine which
therapy was the most effective: Rogerian, Freudian, Jungian, Adlerian,
Sullivanian, Logotherapy, Gestalt, etc. The findings were inconclusive.
It seems that success is dependent on non-universal factors, patient by
patient. A large unknown is the placebo effect. If you believe in your
therapist, you might make progress, regardless of the therapeutic style.
We have a lot of excellent software built using Waterfall. There is a lot
of good software created with ad hoc processes. OOP has produced
many good systems. But structured methods have also resulted in a lot
of good software. The "grand design" approach has been successful
for a lot of systems. I am not aware of any large-scale projects that have
been completed using Agile methods, but I'm sure there are a lot of them.
Most of the ideas in Agile methods are not very new. Seasoned project
managers, those who have worked on and managed a lot of projects,
have understood those principles and used them to good effect on all
kinds of projects -- even within Waterfall and other methods so often
denigrated in this forum.
When I first began developing in Ada, back in the Eighties, there were those
who espoused Waterfall at the larger project level. For those in the trenches,
on our small part of the project, we frequently used the "code a little, test a
little, deploy a little" approach. Of course, we had the benefit of using Ada
so we could easily do this.
At the same time, one cannot deploy an incomplete system for some kinds
of applications. For example, the software for a cruise missile is not likely
to be deployed until all of it is completed, and that can mean upwards of
2 million SLOC.
A critical issue that confronts even the Agile developer is that of software
architecture. We need to have a sufficient understanding of the requirements
to choose an architecture prior to incremental development. It is not a sin
to develop the most complete set of requirements possible early, even knowing
that new requirements will manifest themselves along the way, so we can have
a clear understanding of the architecture within which each of the new
iterations
will reside.
Iterative processes, on a large project, must have a sound architecture and a
well-reasoned long-range strategy. Without that, the chances of painting
one's self into a corner increase over time. Sadly, it seems that a lot of
software developers are not engineers, and do not understand the concepts of
software architecture well enough to do this kind of high-level planning.
Programming is only a small part of the overall software engineering process,
yet it seems to have taken a "tail wagging the dog" role in recent times.
Richard Riehle
|
|
|
|
|