Leo Lipelis
Posts: 111
Nickname: aeoo
Registered: Apr, 2006
|
|
Re: Kung Fu styles
|
Posted: Jul 13, 2006 10:07 PM
|
|
Bruce,
I think the main issue is a human one: how do I make sure I'm getting my value?
Traditionally, you ask the person to commit to a date, then if it's done by that date, you got your money's worth. If not, then you're not getting good value, so to speak. The problem is, this doesn't work well with software of any non-trivial complexity.
So, how else can people know they get good value? Well, another way is to see that people spend most of their day productively, but how could you ever monitor that in a very creative field that often requires research and periods of contemplation? When you're contemplating and not writing any code, are you productive? Perhaps a lot more productive than someone who never stops banging out code. Perhaps not.
People want to be assured that they are not "screwed", so to speak. The problem is -- it's IMPOSSIBLE to know. The only person who can even have a hope of judging a programmer is another programmer of equivalent experience and domain of expertise. That's why programmers like open source -- because the judgement of peers is meaningful.
That's also why the judgement of traditional pointy-haired bosses is meaningless and completely without basis, even conventionally speaking (without getting into deep ultimate philosophy). And yet, at some point up the "command chain" a non-programmer will have to make a judgement of a programmer.
And then the very notion of value is extremely subjective and inconstant. For example, how do you know if an apple is worth 1 dollar? Well, you have to taste it for one. But what if it tastes great? To some, that means it's worth even 10 bucks. To others even a great tasting apple is not worth more than 5 cents. And then, a 10 dollar-per-apple person can have a mood swing the next day and conclude that they made a mistake and that the real worth is only 1 cent. In other words, values are not only inconstant from person to person, but they are even inconstant within a single person from time to time. And yet, people constantly try to evaluate everything, especially in business.
Regardless of whatever engineering techniques we come up with, we'll have an unpleasantly political job of basically massaging some manager's "feel good" antenna, which feels good on completely arbitrary basis. For example, you can spend 1 month on some brilliant server code and not get a word of acknowledgement. Then a Javascript person comes in and puts in some cute draggable columns in a table, and instantly they get a "WOW" response. The real hard work, the really impressive stuff -- it's all deep underground and totally invisible to management. In fact, the more important some job is, the more thankless and the less visible it is. The less important some job is, the more flashier it is, because the flashy and visible part is a tip of a pyramid that needs a wide and firm base of the pyramid in order to be stable. (A phrase "pyramid scheme" for some reason comes to mind)
This problem will never be solved. For this reason, programming will never be a happy job. Oh, programming can be pure bliss if you do it for yourself, or out of love, unconcerned about any judgements or money (but that's not what I call "a job"). But if you ever have to report to anyone or if you ever do it for someone else, it will always be a mediocre experience at best, because the other person will likely doubt the value they're getting, and there really will be no objective/reliable way of proving the value either. At the end of the day, it will be like a marriage. If it works, it's not because of any objective values, but it's something else, maybe faith, maybe chemistry, whatever, but it's not quantifiable and it's not qualifiable.
Agile techniques can scratch the itch by they can't cure it. With agile methods, you have your milestones, which will likely be treated similar to deadlines by management. Or you may have some other metrics, which, if taken seriously, can produce very weird incentives that are counter-productive (for example, using KLOC to judge output can result in over-verbose code, and so on). Having more shorter milestones is a little better than a single all-or-nothing deadline, but it's merely managing the problem and not solving it.
Think of it this way. Our real boss is not a concrete human being, but a value system that keeps changing by its very nature. With a boss like that, can anyone be content? Who can hit the bull's eye that keeps shifting and re-defining itself?
By tweaking our engineering methods we are, maybe, making some marginal improvements, but at that level, we are still just dabblers.
|
|