4 ms·
This is why economic thinking should be a part of every team's process. One of the major problems with technical projects is that many people can give an estima
by planet-and-halo 5y ago
This is why economic thinking should be a part of every team's process. One of the major problems with technical projects is that many people can give an estimate of their value but only the developers can give an estimate of the cost—and they can usually only do that effectively after some iterations and starting to sketch out the problem. Usually organizations just ignore this problem and try to fix the cost upfront, which is where the whole "mythical man month / hours" phenomenon comes from. In a well-functioning Lean/Agile/whatever-you-want-to-call-it organization, there should be a constant ongoing evaluation of the work and its cost/benefit, and that should be updated as the devs learn more about the problem. When you do this, ideas are no longer "good" or "bad," they just have a value estimate and can be evaluated against other ideas. (And you can factor in things like switching costs when people throw out something totally new.)
- Dracophoenix 5y agoWhile I think that kind of thinking the kind that encourages bean counting and half-assery in the name of profit? I would certainly agree that having an ongoing basis for calculation is a metric. But when that metric becomes a target (and it will), you get disasters like the 737 MAX.
- planet-and-halo 5y agoBean counting is happening in your organization whether you like it or not, it's just a question of whether it's visible to you. I would much rather have it be an explicit part of the development process where the developers get some kind of input than have it hidden away and have edicts emerge from the ether to mess up their whole month. For a thoughtful view of this topic, I recommend "Principles of Product Development Flow."