What happens if you get hit by a bus?

older
Dutch national FP day, January 6,...

Michael Litchard

16 Dec 2011 16 Dec '11

10:37 a.m.

I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, "What happens then?", what is a good answer?

Show replies by date

Colin Adams

16 Dec 16 Dec

10:40 a.m.

I would think there were plenty of Haskell programmers ready to jump in as replacements. On 16 December 2011 15:37, Michael Litchard wrote:

...

I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, "What happens then?", what is a good answer?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Michael Litchard

10:47 a.m.

Yes! I could cite the large and growing set of libraries on hackage as evidence. On Fri, Dec 16, 2011 at 7:40 AM, Colin Adams wrote:

...

I would think there were plenty of Haskell programmers ready to jump in as replacements.

On 16 December 2011 15:37, Michael Litchard wrote:

...
I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, "What happens then?", what is a good answer?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Brian Hurt

11:17 a.m.

I think the "truck-factor" implications of the programming language as dwarfed by the implications of everything else in the project. Any project of any significant size is going to have a huge amount of project-specific information tucked up inside the programmers head. It doesn't matter if there are a million other programmers who know the language you used, or only a dozen- if you're the only one who knows how things were done, and more importantly, why they were done that way, and you get hit by a truck, then your boss has a big problem. Whether there are millions of candidate replacement programmers, or only dozens, none of them had the project-specific knowledge you had. Finding a replacement who knows the language is the least of his problems. On Fri, Dec 16, 2011 at 10:40 AM, Colin Adams wrote:

...

I would think there were plenty of Haskell programmers ready to jump in as replacements.

On 16 December 2011 15:37, Michael Litchard wrote:

...
I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, "What happens then?", what is a good answer?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Steve Schafer

11:35 a.m.

On Fri, 16 Dec 2011 11:17:20 -0500, Brian Hurt wrote:

...

I think the "truck-factor" implications of the programming language as dwarfed by the implications of everything else in the project. Any project of any significant size is going to have a huge amount of project-specific information tucked up inside the programmers head. It doesn't matter if there are a million other programmers who know the language you used, or only a dozen- if you're the only one who knows how things were done, and more importantly, why they were done that way, and you get hit by a truck, then your boss has a big problem. Whether there are millions of candidate replacement programmers, or only dozens, none of them had the project-specific knowledge you had. Finding a replacement who knows the language is the least of his problems.

I believe that you're absolutely right. I also believe that corporate decision makers rarely, if ever, think that way. And that's the problem: You have to deal with the perception, not the reality. So, that's the real question that needs to be answered: How do you deal with the _perception_ that hiring a Haskell developer instead of a Rails, etc. developer will result in more chaos when said developer is hit by a bus? -Steve Schafer

Marc Weber

10:48 a.m.

What about just replying with this one link: http://www.haskellers.com/ As thumb of rule it takes half the time to review code compared to writing it (Don't remember where I read it ..). Thus even RoR can be a lock in and delay updates if stuff changes. The only chance is creating a team and provide services as "team". But in the end its a matter of costs: If you have to share ideas - if you have to keep each other up to date it'll take more time and somebody has to pay for it in the end.. Its not only a Haskell vs RoR qusetion IMHO. Marc Weber

Ketil Malde

11:08 a.m.

Michael Litchard writes:

...

One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question?

In this particular case, you could argue that more people know PHP and Python than Ruby, so surely one should avoid Ruby as well. Managers like to think of their company as a factory, and from this perspective, it makes sense to build your factory from easily obtainable parts. But the factory mindset only works when you want to manufacture stuff, nobody who takes a minute to actually think will say that you can replace any programmer with any other, as long as they know the same programming language or framework. Anyway, here's something I found interesting in that respect: http://www.dachisgroup.com/2011/12/cant-get-no-satisfaction-why-service-comp... (This probably turned out less helpful than I intended, sorry :-) -k -- If I haven't seen further, it is by standing in the footprints of giants

Ivan Perez

11:37 a.m.

Just like Michael, I've been learning what it means to be a professional Haskell programmer for a few months. I think the case of Ruby on Rails and Haskell are very, very, very different. Ruby on Rails has been around for many years. There are books, tutorials, examples, websites, etc. Still, there are not as many developers that use Rails than those that use PHP, or Java, or .NET, or Python (for web development). But there are many. This is definitely not the case with Haskell. If you go around the internet, it's not just that you can't find Haskell programmers with the necessary skills. You also cannot find people demanding these jobs, servers that support Haskell for web, or success stories to convince others and yourself that this is the right platform for this job. After several months, I just found the first client for which I'll create a website using Yesod. Being a professional Haskell developer requires many skills that have nothing to do with Haskell. Unless you are born with the talent of having the tax rules embedded in your head, you'll have to learn them. Maybe the hard way. That is true for lots of tasks related to social skills, design, management, negotiation. such as "how do I know what the client really wants without wasting hundreds of hours", "how the heck do I show my client what I have in mind" or "should this button go on the right or on the left and why should I care". Learning them takes time, and most of us don't learn them unless we actually need to. It's not that there aren't any people capable of creating websites using Haskell, or Haskell programmers who could learn to do it. It's just that not many people know enough, as of this day, to deliver a professional product with the results that clients expect. In my experience, the following help: - Have a good portfolio, a list of websites you've created in Haskell that shows they have nothing to fear. If you can't find clients, create websites for free. Sparked.com may help. You'll know the list is good when there are great jobs that you choose not to include in it. - Ask your previous clients and those you created websites for to leave feedback, acknowledge your work publicly or recommend you on linkedin. - Make a list of your competitors names and addresses (and put my name on top of the list ;) Haskellers.org may help. So can linkedin, guru.com, peopleperhour, etc. If they ask, tell them that there are tens of programmers with the necessary experience to go on if they are not satisfied with your work. If you want, we can created a group in a social network just for this, with the requirement that you must have created an actual product to be in the group. The amount of packages in hackage means Nothing to me. It means nothing to my clients. Good luck. Cheers, Ivan On 16 December 2011 17:08, Ketil Malde wrote:

...

Michael Litchard writes:

...
One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question?

In this particular case, you could argue that more people know PHP and Python than Ruby, so surely one should avoid Ruby as well.

Managers like to think of their company as a factory, and from this perspective, it makes sense to build your factory from easily obtainable parts. But the factory mindset only works when you want to manufacture stuff, nobody who takes a minute to actually think will say that you can replace any programmer with any other, as long as they know the same programming language or framework.

Anyway, here's something I found interesting in that respect:

http://www.dachisgroup.com/2011/12/cant-get-no-satisfaction-why-service-comp...

(This probably turned out less helpful than I intended, sorry :-)

-k -- If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Yves Parès

1:02 p.m.

Tell them that if you were instead on Rails, you'd have a huge chance of being hit by a train, which is likely to deal far more damage than a bus. 2011/12/16 Michael Litchard

...

I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, "What happens then?", what is a good answer?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Alberto G. Corona

17 Dec 17 Dec

8:24 a.m.

Hehee Great. Haskell is a flexible high level language perfect for domain specific languages it isn't?. A well designed solution is, at the top level, simple and understandable even by non experts. The software transforms the complexities of the hardware into something that the user can understand by means of interfaces, EDSLs etc. The complexity must be hidden in deeper layers. So if you are hit by a bus, the new programmer would be confronted with a simple application layer (ideally simple enough to be understood by a non haskell programmer) , that would permit the evolution of the software, so the new programmer is productive from day one, from the client point of view. More radical adaptations may require deeper knowledge, but at least the shock would be greatly mitigated. 2011/12/16 Yves Parès :

...

Tell them that if you were instead on Rails, you'd have a huge chance of being hit by a train, which is likely to deal far more damage than a bus.

2011/12/16 Michael Litchard

...
I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, "What happens then?", what is a good answer?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Bardur Arantsson

16 Dec 16 Dec

2:05 p.m.

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...) -- Bárður Árantsson

Andrew Coppin

3:51 p.m.

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.) 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...) PS. Kudos to Ketil Malde for the best link I've seen today.

Brian Hurt

4:42 p.m.

On Fri, Dec 16, 2011 at 3:51 PM, Andrew Coppin 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 http://www.haskell.org/mailman/listinfo/haskell-cafe

Brian

Bardur Arantsson

5:09 p.m.

Andrew Coppin 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 dependi ng on how long you spend thinking about it.

[snip blah blah blah] - Not to be rude, but... (*) That was the point of my post. If you're actually confronted with this perception that traffic accidents are relevant to project success, you're already in deep manure because there's so much more than code in a project. That's what you need to explain. Code is the "means" of getting us to an "end". It seems these people are worring about the "means" when the big problem is actually conveying the "ends". (Again, just my take on the situation, I'm not claiming canonicity or anything.) -- Bárður Árantsson (*) I realize that this is rude. I can only apologize.

4905

Age (days ago)

4906

Last active (days ago)

List overview

Download

13 comments

11 participants

participants (11)

Alberto G. Corona
Andrew Coppin
Bardur Arantsson
Brian Hurt
Colin Adams
Ivan Perez
Ketil Malde
Marc Weber
Michael Litchard
Steve Schafer
Yves Parès