Re: Kung Fu styles
Posted: Jul 15, 2006 5:45 PM
> 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.
I think/hope most projects would begin with an estimate. As you get more done you update the estimate. "The date" is virtually always a moving target that you refine as you go along.
> 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 taking it a bit too far. There's usually a contract that details (more or less) what the customer wants and this is where you are trying to get to, right? Customers are not interested in "the good vibes" you had while coding and hence appreciating your work on some "deeper" level. What they want is a functional product. Nothing wrong with that.
> 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
> s worth even 10 bucks. To others even a great tasting
> apple is not worth more than 5 cents.
Economists have been eating these apples and oranges for well over 200 years. There's of course a whole bunch of opinions but the dominant approach with neoclassical economics is that of marginal utility. The price you pay for things is basically the result of a dynamic equilibrium between sellers and buyers that captures average value of whatever it is you are willing to pay for. That's a simplification of course, but it's still useful.
> 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.
I don't really see why other people's "feeling of value" has anything to do with you enjoying the work you do. I try to have a good time programming (for money or not) and not worry about what other people "might" think.
Back to the point... given our current state of knowledge, software development processes are non-deterministic. If some very bright psychologist comes up with a model that can predict people's behaviour in a frequently changing environment I'll be the first to use it! We don't have much right now.
However, it's not all chaos either, is it? When we are incapable of formalizing all this stuff into a model what comes into play is experience... I was reading an interview with Marvin Minsky (AI guru) the other day - I think it's in MIT Technology Review - and what struck me as interesting is that after all this time we still can't get a computer to draw the simple logical connections a 3-4 year old can do. That should be enough to put ALL deterministic theories of software development in perspective.
In the end of the day it is VERY difficult to disagree with Bruce on this one. Shouldn't this be common sense? I find it quite strange that people are willing to pull in a whole bunch of physics examples and say "Things are deterministic... if we know XYZ". But that's the whole point. We don't know XYZ. And provided that we don't know XYZ the approach should account for that rather than ignore it.
Back in the real world I think most people implicitly use a non-deterministic model. The whole idea of short and focused iterations is to contain "the unknown" factors and make mistakes in small steps.