What’s your experience with distributed development?

  Compared to team work in an office, working together over the Internet
  tends to be more loose, as people work on different schedules--It gives
  individual developers more freedom (work-life balance) and responsibility
  but also demands more self motivation and for managers it's harder to
  monitor progress.

What is your advice for distributed development teams?

  1. Work only with people that you can trust.
  2. Put your all your development computers on a hoster so they are
  directly accessible from the Internet.  This makes maintaining build
  environments much easier.  (For security reasons you should use ssh with
  private keys when accessing those computers.)  Make your computers
  clonable, so it's easy to give them a build environment when new
  developers join a team.

  3. Design the architecture of your software so that people can be the
  most productive without needing to wait for other developers.  (eg on
  MySites we separated the data aggregation and the GUI so that they are
  completely separate, data aggregation happens in Ruby and GUI
  representation is done in JavaScript)

  4. Use an encrypted platform like Skype for chatting and instead of doing
  phone calls

  5. Use 'screen -x' when working together with individual developers on
  their build environment.

So he mostly speaks about finance, because that’s what he knows, but underneath he is mostly talking about statistics and risk. And that is what we all deal with.

His previous book "The Black Swan" in some senses wasn’t very useful… it can be abbreviated as "We are really Bad at prediction, much worse than you believe."

His latest essay is actually quite handy. It provides a map of where we are going to be startlingly Bad at predicting.

www.edge.org/3rd_culture/taleb08/taleb08_index.html

Many Agilisto’s will say, "Yip, he is right, thats why our practices work".

Others may look at Taleb’s essay and get an "Aha!" moment and finally realize why some of the Agile practices work.

He suggests you divide problems on the basis of moments of a random variable.

If your decision is a "yes/no" choice, it is simple. Will the project be finished by the 5th of December 2008?

If your question is based on the value of a random variable, it is more complex. What will be the completion date of the project?

If your question is based on a higher moment of a random variable, it is very complex. What will be the ROI of a project?

Then look at the nature of the randomness… Is it fat tailed, or well behaved?

For non-statistical types a probability distribution can be fat or thin tailed. The one you learned about in the stats course you have mostly forgotten was a thin tailed one. (Gauss / Normal distribution).

Odds on if you did any stats course they went on for hours about thin tailed distributions, because they can do the mathematics for them.

Unfortunately most real world distributions are fat tailed.

If you have a 1000 guys in the company, the average weight of employees is simply not going to shift by much if you employ the fattest guy in the world. (Fat guys come from a thin tail probability distribution.)

If you look at a 1000 random project case studies, the average project overrun is going to massively shift if you add the worlds largest project overrun.

ie. Things like food requirements for project workers are random variables from what Taleb calls "mediocristan".

Things like time to completion are from "extremistan".

So if divide your problems in to quadrants like this.…

 Simple Payoffs    |  Complex (Higher Moment) payoffs
 Thin tail distribution  Predictable      | Less predictable
 Fat  tail distribution  Less predictable | You're utterly stuffed.

Exercise for the Reader…

1) Catalogue the random variables in your work situation and categorise them as from mediocristan or extremistan.

eg. Time to complete an item of work - Extremistan

Programmer Productivity - Very high variance, but probably Mediocristan.

Security Risks - Extremistan. (No valid distribution on attack models, motivations etc.)

Exchange Rate fluctuations - Extremistan

Programmer Defect rates - Not sure. Maybe mediocristan for simple monothreaded programs. …

We have several projects in New York and Munich.

A small international team in an agile setting is waiting for you developing applications that scale to millions of users.

As usual, we care about experience, communication skills and simply the desire to excel and not page-long CVs.

If interested, please email me at armin at personifi dot com. Please no Word docs, only .txt or pdf or put it all in a simple email.

Next time we ask for some GNU Flex developers .. :-)

 Hi,

 we're currently implementing some the XP concepts when we can see the
 reason for using a concept. Mostly this is due to some problems we
 identify. I'm not a consultant, but integrated into a development
 team, perhaps that allows me to see things from a different
 perspective.

 I found that people dislike "guessing" effort in time, because they
 feel bad if estimated ideal time is small compared to actual time.
 This can lead to the following problems:
 - overcommitment (but this time I'll do it in 2 days! really!)
 - undercommitment (if I guess a lot too much, I feel better if I'm wrong)
 - artificial pressure (I guessed 2 days, so I need to do it in 2 days,
 let's not do refactoring now)
 - demotivation (being wrong makes me feel bad)
 - problems with communication to product management ("but you said
 you'll do it in 2 days, now it took already 5!" - "but I said it's
 ideal time!" - "than tell us the actual time it will take the next
 time!" - "but I can't do that" etc)

 Using points solved this. Perhaps explaining to the developers that
 they have to accept that ideal time has nothing to do with actual time
 and that they should not worry too much about correctness of single
 guesses and explaining to product management that there are different
 time estimations (some in ideal time and some in actual time) would
 have solved the issue, too, but simply using points is clearer, since
 you make the distinction explicit if you communicate about effort.

 If I tell to product management that this item has size 3 and they ask
 me how long it'll take, then I tell them that if they include it in
 the current iteration they'll have it at the time the current
 iteration finishes.

 All this is less communication effort for me and thus increases ROI
 because I can work on code instead of nitpicking on the concept of
 time  :-)

 Cheers,
 Manuel

Skiing in Garmisch :-).

 >> What happens when John leaves the company, and he's trained everyone
 >> to, whenever a certain class of error happens, go to him without
 >> learning anything about the problem first?

 That does concern me... It makes economic sense to me the rule "If a
 person is indispensable to your company, fire him now, since it
 will cost you more when you do eventually loose him."

 Thus I have several counters to the Truck Factor...
 1) Unit Test / TDD === executable documentation.
 2) Good rdocs that I periodically refresh.
 3) Get others to code review my changes.
 4) Go on holiday. The "It's Johns fault" message tells them immediately
     they had better start reading code if they want it fixed before I get back...

 > You don't have to be stupid to avoid work. I'm no dope, but I avoid any
 > > work I can avoid. If your co-worker sees the change a fully-automated
 > > build as extra work, and he doesn't want to do extra work, then you
 > > could try showing him why the fully-automated build will make for less
 > > work. If he can't see it, he can't see it. Don't smack your head against
 > > the wall; it just hurts.

It could be a "cultural" thing. The Unix philosophy was that if you were going to do something more than a couple of times, you should write a script to automate it. For PCs, it was that if you were going to do something a bunch of times, you should get some fancy GUI with a ton of buttons and then memorize all of the icon functions and key sequences. Pressing 5 or 10 buttons in a row is not seen as being too onerous.

Having been on both sides, automating it is always more consistent, faster in the long run, and helps to document the steps. Long sequences of button pressing are prone to human-memory glitches, making it a source of frequently errors. GUIs are good for rarely used and exploratory tasks, but not for frequently used or critical work. Unfortunately the PC development culture leans heavily on button bashing, IDEs and pretty GUIs (even for things like diff). It is something that I’ve always seen as a de-evolution in software development, but I realize with many developers it is a religious argument.

Paul.

In the end, it’s better to avoid creating stubborn dragons in the first place and to slay them early if they start to turn bad. Young dragons are easier to slay than old ones. You may even slay several dragons before you are happy that you have one you can live with.

Image source

Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. However, in business we often try other strategies with dead horses, including the following:

• Buying a stronger whip.
• Changing riders.
• Say things like, "This is the way we have always ridden this horse."
• Appointing a committee to study the horse.
• Arranging to visit other sites to see how they ride dead horses.
• Increasing the standards to ride dead horses.
• Appointing a tiger team to revive the dead horse.
• Creating a training session to increase our riding ability.
• Comparing the state of dead horses in todays environment.
• Change the requirements declaring that "This horse is not dead."
• Hire contractors to ride the dead horse.
• Harnessing several dead horses together for increased speed.
• Declaring that "No horse is too dead to beat."
• Providing additional funding to increase the horse’s performance.
• Do a Cost Analysis study to see if contractors can ride it cheaper.
• Purchase a product to make dead horses run faster.
• Declare the horse is "better, faster and cheaper" dead.
• Form a quality circle to find uses for dead horses.
• Revisit the performance requirements for horses.
• Say this horse was procured with cost as an independent variable.
• Promote the dead horse to a supervisory position.

Nice thread int he extremeprogramming-ML

 Let me relate a few war stories...

 Once I had a very very complex problem to solve.

 I had not the foggiest notion in which order to compute what.

 So I took the cowards way and hooked in the Observer all over the place
 so I didn't have to think in what order to do it.

 It was very slow and buggy and I was no closer to understanding in the
 problem than before. It did work occasionally though.

 I put in enough logging to see what order it did things in (when it
 worked). After glaring at that for an hour I saw the pattern, recoded
 it as a couple of tight while loops.

 Result...

 Very fast, very understandable, easily maintained, no bugs and no observers.

 Story two...

 Once I took over the maintenance of some code that had several
 observer pattern instances scattered around it.

 It was fragile, buggy, and erratic.

 After much loss of hair and many hours of poring over log traces I
 figured it out.

 There were complex loop paths through several observers. No mere
 mortal could really understand what would happen if object X updated,
 since the possible impacts and possible variants of paths were almost
 limitless and depended crucially on the order of registration of
 observers.

 After a brief killing spree amongst the instances of the observer
 pattern the code was still buggy, but at least no longer fragile and
 erratic...