On Fri, Dec 16, 2011 at 3:51 PM, Andrew Coppin
<andrewcoppin@btinternet.com> wrote:
On 16/12/2011 07:05 PM, Bardur Arantsson wrote:
Michael Litchard wrote:
[--snip--]
If getting hit by a bus is a significant factor in the overall outcome of
the project then I think those are pretty good odds, aren't they?
(I do realize that traffic accidents are a lot more frequent than we like to
think, but still...)
The /actual/ probability of being hit by a bus is irrelevant. The only thing of concequence is the /percieved/ probability. This latter quantity is not related to the former in any meaningful way. In fact, due to an effect known as availability bias, the probability of any potential threat varies depending on how long you spend thinking about it.
(In other words, if you've never even considered what would happen if your sole developer got hit by a bus, your estimate of the probability of this will be very low. If you sit down and think about how much trouble you'd be in if this actually happened, suddenly your estimate of the probability starts increasing. This is completely illogical - which is why it's called a cognitive bias.
There are a lot of ways that, from the perspective of the business, a person could get "hit by a bus"- they could get into an accident, including getting hit by a bus, die for some other reason, get sick, retire, get another job, or even quit to join the Peace Corp and get shipped off to Uganda (actually had that happen to me once). Sooner or later, everyone will be metaphorically "hit by a bus", in that they will not be here anymore. Next time this discussion comes up, as the room how many people have been at their company for 20 years or more. Then ask them to guess how many people in the room will still be at the company in 20 years time. The high probability is that very few, if any, people will still be at the company in 20 years time.
It doesn't matter why Bob is no longer here with his specialized knowledge of Bob's code, but the end result is the same. And the problem is the same- someone else has to be brought in to deal with Bob's code. And that someone, even if they know the language the code is written in as well, or even better, than Bob, doesn't know the *code*. And it's just a question of when, not if, Bob will no longer be there to maintain the code.
If anything, using Haskell *reduces* the truck-factor compared to other languages. Someone new coming in needs to be able to make small changes fairly quickly (major reorganizations and refactorings can generally be delayed while the new person comes up to speed, but small bug fix and small feature additions are a constant need). What Nancy the new hire can do, if the code is in Haskell, is simply change the function, and let the compiler figure out where it's being used. Also, types are a wonderful bit of documentation- see the paper "Theorems for Free" by Phillip Wadler. This makes it easier fo the new person to come up to speed on what the code does, if not necessarily how or why.
Ever heard the phrase "fear, uncertainty and doubt"? It's a killer in a business context.
It seems clear [to me] that there are actually quite a few Haskell programmers around, and it's not especially hard to find them. The question is how many "good" ones there are. "Good" is all vague and subjective and hard to measure, unfortunately.
On the other hand, if you just start the project with more than one developer on board in the first place, then the possibility of just one of them being killed prematurely becomes drastically less serious. (For the business. I'm sure it's still fairly serious for the person who just DIED...)
Again, it depends. If there was this large body of code that only one developer ever worked on, then you have truck-factor problems.
PS. Kudos to Ketil Malde for the best link I've seen today.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe