You'll hear a lot of developers talk about the old saw: "You can have software good, fast, or cheap: pick two". Now, given an unchangeable set of people, processes, and technology, that might hold true. However, the reality is, you can have things better, faster, and cheaper, simply by improving the efficiency of your approach. That usually boils down to just improving the way you conduct the activities of software project management, and the specific activities that contribute to creating the software. Even just improving communication skills can have a dramatic effect on software project efficiency.
The other issue with this good/fast/cheap BS is that it implies once you've picked the two you care about, you can stop worrying about how to achieve the other one, and that is simply not true. You can't ignore quality, time, or expense - these are all constant considerations.
Similarly, it suggests that by throwing money, or time, or bugs(!) at a system, you can get the other two factors to go up, and again that is absolutely not true.
So the response this always gets from me is: That's an interesting observation... so what?
There are always real-world business constraints on time, quality, and expense. The real blood and guts of the matter is this: What is your capability to produce a given project within those constraints? The only way to improve your capability is to improve your efficiency.
A side effect when you improve your efficiency is that you improve on all three indices - better quality, shorter turnaround, and lower costs.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment