

Rands In Repose: Bits, Features, and Truth - filament
http://www.randsinrepose.com/archives/2010/03/29/bits_features_and_truth.html

======
bena
What? He winds up exactly where he started but with the roles of people
relabeled.

> Features: I want feature X and I want it on the same schedule.

> Truth: We need more time and since I know all the moving parts, I know that
> we’re ahead of schedule of one feature. I think we’ve got two weeks of
> wiggle room.

> Bits: Two weeks isn’t enough. Can we cut this one feature that we haven’t
> started and no one cares about in half?

> Features: I can live with that.

> Truth: Sold.

This exchange is "the triangle" working properly. They sacrificed some of the
quality in the form of features in exchange for time. All he's done is found
another way to say we need to properly prioritize application development.

I believe it's addressed in The Mythical Man-Month.

------
russell
>> We have six weeks to shipping...

That tells me that they are dealing with release cycles measured in months. No
wonder the pressure to add features at the last minute. Those of us in the web
world are used to releases every week or even every couple of days. Then the
releases are run like subways. The train pulls into the station and you board
the features. No one worries about a four week project because another train
will be there when it is done. If another project gets bumped, no big deal,
another train will pick it up.

This can even work with customer hosted servers. I worked on a project where a
couple thousand customers received a new server every week or two, including
database updates. The customer's server called home every night and asked if
its replacement was ready. If it was it downloaded it.

If you have agile, automatic delivery, you dont need a lot of heavyweight
process. Some process, yes, but not the kind that makes millionaires out of
consultants.

~~~
Alex63
I wish that process consulting was making me a millionaire. That aside, I
think in one of Jerry Weinberg's books he says something along the lines of
"things are they way they are because they got that way." In other words, in
most cases processes in big shops have evolved in response to past
circumstances. It's kind of like contracts - they're long and complicated, but
each clause reflects a lesson that someone learned in the past (the hard way).

I like the idea of regular, frequent delivery, but my experience has been that
for a lot of IT shops that is not a practical approach, either because of user
or management expectations. And in a few, rare cases it may be because of IT's
technical capability. More often the heavyweight process has evolved because
of issues that have occurred in the past (unplanned outages, etc.), or because
of management's desire for "predictability" in their delivery process.

------
Alex63
The first time I heard the "triangle argument", the points were labeled "Good"
(as in quality), "Fast" (in terms of time to deliver), and "Cheap" (cost of
the project). Maybe that version is more specific to MIS-type projects?

~~~
roc
I also found quality/features to be an odd distinction to make.

Then again, I've never been a real fan of 'cheap' either.

Experience has shown that there are very real upper-bounds on the
effectiveness of throwing resources at projects.

And, particularly when you're having these late-cycle meetings, it strikes me
as flat-out disingenuous to imply that throwing money at a project is a
reasonable or even plausible way to hit an expanded scope on an existing
schedule.

~~~
Alex63
True. The triangle doesn't really call out the issue of non-linear increase in
cost/risk of changes as the project progresses, or other aspects of Brooks's
Law.

