4 ms·

Rands In Repose: Bits, Features, and Truth

39 points by filament 17y ago

bena 17y ago
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.
Alex63 17y ago
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 17y ago
  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 17y ago
    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.
deleted 17y ago
[deleted]
russell 17y ago
>> 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 17y ago
  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.

39 points by filament 17y ago

bena 17y ago

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.

Alex63 17y ago

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 17y ago
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 17y ago
  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.

deleted 17y ago

[deleted]

russell 17y ago

>> 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 17y ago
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.