smart stuff

Adobe Flex developer wanted - remote or onsite

Either as free lancer or permanently employed we need a Flex guru or an advanced Flex developer that likes challenges.

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 .. :-)

XP: Real-world experiment with Hours instead of points

Manuel Klimek posted his insights to the XP-list.

 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 :-).

On indispensable persons in a team

John Carter posted this to the pragprog-ML.

 >> 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...

Scripting vs GUIs

Nice post from Paul W. homer in the pragprog-ML.

 > 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.

Dragons of Design

David Buck compares software subsystems with dragons.

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

Beating a dead horse

Victor posted this to the XP-list

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

Cycles of Observers

Good post by John Carter to the pragprog@yahoogroups.com

 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...

Small Teams Make Better Software

I saw that a small team of good people seemed to outperform the most disciplined process, toolset, or philosophy. A bad team usually failed to produce a good result, regardless of what magic process was applied. Article

Twelve Benefits of Writing Unit Tests First

www.jtse.com/blog/2006/07/11/twelve-benefits-of-writing-unit-tests-first?

Refactoring Demo Screencast

Four different ways of performing the refactoring "Extract Method".

xp123.com/xplor/xp0605/index.shtml

A thousand cleaners in one tiny room

Ron Jeffries answered in the XP list to Jim Hughes.

 > Ed has tried what you suggest.  When the bosses want 10 things and our
 > > measured velocity indicates we're going to get 6 done by the date, the
 > > bosses reply with "how many contractors do you need to get it all done?"  Ed
 > > says "We could use a couple more good coders; maybe we could get 7 done if
 > > we get them in soon.  Any more than that will slow us down, because helping
 > > the get up to speed will take up too much of our time."

 > > "Okay, so how many contractors do you need to get to 10?"

 > > This exchange really takes place over weeks, not seconds, and involves many
 > > more people.

 > > I realize that what Ed's bosses don't "get" isn't just Agile, but basic
 > > proto-agile wisdom about how software development works, like in The
 > > Mythical Man-Month.  Ed is looking for a way to help them get it.

 I'd really need to hear the real conversations to know what's up.
 But the answer to the first contractor question probably ought to
 be:

    Adding one contractor will slow us down for 45 to 60 days, then it
    will add X percent to our speed.

 The answer to the second is probably something like:

    There is no such number. We can't vacuum your office in ten
    seconds by using a thousand cleaners. They won't fit in the room.

Engines of Democracy

The General Electric plant in Durham, North Carolina builds some of the world’s most powerful jet engines. But the plant’s real power lies in the lessons that it teaches about the future of work and about workplace democracy.

A nice article about discovering the value of the human being.

Project (Cartoon)

Enjoy the super comic.

It’s truer than one thinks :-).

Ron Jeffries article: Complex Scope

In which we discover that our implementation is "totally wrong" and we have to rewrite everything. Or do we?

www.xprogramming.com/xpmag/xstComplexScope.htm

Agile Dilbert

Even Dilbert has to face agile methods. Great story.

Making the Date

Ron Jeffries posted a new article.

It seems like every development project begins with the date, and we’re held responsible for "making the date". Making the date is not a development responsibility. Here’s why.

Outsourcing research and development work

I came across this great post by Luiz Esmiralha in the pragprog list.

 >>  On Sun, Oct 16, 2005 at 11:48:34PM -0200, Luiz Esmiralha wrote:
 >>  >
 >>  > Maybe another question can help clarify the issue.
 >>  >
 >>  > Why pay 100 grand a year for a programmer just to make a guy in the US
 >>  > or Europe happy if I can get the same job paying 20 grand a year for a
 >>  > guy in India?
 >>
 >>  Well those aren't anything near the figures.  I know someone who is
 >>  the IT director for a UK company that uses outsourcing.  The financial
 >>  savings are around 15%.  If he sets up a UK shop in one of the more
 >>  deprived areas of the UK he will be able to get to somewhere near that
 >>  figure - lower salaries, govt grants etc.  As a result he is seriously
 >>  looking at doing just that.
 >>

 In a recent survey, average savings from offshoring are around a bit
 less than 10%. 5% of the companies polled acheved savings around 50%
 (cases where they replaced 400 bucks/hour resources for 50 bucks/hour
 resources).

 The realistic target saving when offshoring operations is estimated
 around 30% as companies become more mature in the way they conduct
 offshoring.

 20 grand a year for a programmer in Brazil is a very good figure. I
 don't know the current average salary of a programmer in the US or UK.
 The 100K figure was based on supposition rather than fact.

 >>  > Your analogy implies that Indian software lacks quality. Quality seems
 >>  > to be measured (or guessed?) in CMM levels by every company in the US
 >>  > and the rest of the world is following this trend. Given that fact, I
 >>  > would like to remind you of the many companies in India appraised at a
 >>  > CMM 5 maturity level.
 >>  > I don't believe in CMM, but the guys in India didn't make it up, they
 >>  > just happily jumped on the SEI bandwagon.
 >>
 >>  I don't believe in CMM either and I dont believe it necessarily produces
 >>  a high quality product.  It has been my experience (of three different
 >>  Indian outsourcing companies) that product quality is variable, and
 >>  a lot of the developers are what I would class as juniors even though they
 >>  are not sold as such.  Undoubtedly some of this can be tracked to
 >>  the fact that development of apps that distant from the users is not the
 >>  best way of doing things. Also there is a disinclination for the Indian
 >>  guys to question the spec if they think it is inconsistent or lacking in
 >>  detail and to raise questions with whoever is leading the project.
 >>
 >>  Some (maybe most) of these issues are often also present for the big US/UK
 >>  consulting firms.
 >>

 I worked with the 'Big Five"  in some projects and they present a
 uniform pattern in their staffing that I call "War Movie Team".

 These teams are usually composed by a seasoned sargent (consultant)
 which marvels the spectator (customer) with his ability and 10 rookies
 (juniors or trainees). The sargent is usually assigned to another post
 in the middle of the movie and must leave the rookies to their own
 luck.

 In unrealistic war movies, the rookies will use their talent combined
 with the experience they acquired with Sarge to overcome the enemy and
 come home as heroes. In real wars and real projects, they are
 slaughtered by snipe fire, hidden mines and disease and return to
 South Dakota in bodybags.

SD People & Projects: Mo' Developers, Mo' Problems?

Thanks to Stefan for the forwarded eamil.

 Von: "SD Magazine"<sd@newsletters.sdmediagroup.com>
 Betreff: SD People & Projects: Mo' Developers, Mo' Problems?
 Datum: Mon, 03 Oct 2005 19:09:26 -0400 (EDT)

 SD PEOPLE & PROJECTS

 October 2005: Bigger Teams Not Always Better
 By Amit Asaravala

 >>>> MO' DEVELOPERS, MO' PROBLEMS?

 Thinking about assigning more developers to a project
 to accelerate your schedule? Be careful. Putting a large
 team on the job could cause you more trouble than it's
 worth, according to a new study by software estimation
 and analytics vendor QSM.

 The study, based on data that QSM collected from 564
 information systems projects completed since 2002,
 revealed that large teams don't complete projects much
 faster than small teams, though they cost much more. In
 particular, teams with 34 people on average completed a
 100,000-line project in 5.6 months at a cost of $2.1
 million, while teams of four people on average took
 about two weeks longer but cost just $294,000. Thus,
 shaving two weeks off the schedule cost some companies
 as much as $1.84 million.

 Why such disproportionate production rates? Blame it
 on the bugs. The larger teams produced more than five
 times as many bugs as the smaller teams, which required
 the teams to reexamine their code more often, according
 to QSM. In the end, this ate into a large portion of
 the time saved by having more developers turn out more
 code per day.

 But before you decide to cut your team back to just
 four people, consider this: The size of the small team
 in the study was just an average, and QSM readily admits
 that it's saving the question of "optimum" team size for
 a future study.

 Rather, the real lessons here are that you'd better be
 sure that accelerating your schedule by adding more
 developers is worth the extra cost, and that you should
 have realistic expectations about how many days you'll
 actually save by doing so.

 --Amit Asaravala

Linus on Specifications

William posted this to the XP-List.

Here’s a very interesting set of comments from Linus Torvalds and Theodore Tso on the problem with writing specs:

kerneltrap.org/node/5725

Here’s a great quote from Linus:

 The classic example of this is the OSI network model protocols.
 Classic spec-design, which had absolutely _zero_ relevance for the
 real world.We still talk about the seven layers model, because it's
 a convenient model for _discussion_, but that has absolutely zero to
 do with any real-life software engineering. In other words, it's a
 way to _talk_ about things, not to implement them.

 And that's important. Specs are a basis for _talking_about_ things.
 But they are _not_ a basis for implementing software.

And a good one from Ted Tso:

 In those cases, if you implement something which is religiously
 adherent to the specification, and it doesn't interoperate with the
 real world (i.e., everybody else, or some large part of the
 industry) --- do you claim that you are right because you are
 following the specification, and everyone else in the world is
 wrong? Or do you adapt to reality?

And another one from Linus:

 So don't talk about specs. Talk about working code that is
 _readable_ and _works_. There's an absolutely mindbogglingly huge
 difference between the two.

All heresy to the BDUF school of thought, of course. But relatively uncontroversial in the XP world. Interesting to see the parallel evolution.

Why I hate factories

Great post on the Joel on Software forums by Benji Smith.

"Let’s pretend I’ve decided to build a spice rack.

I’ve done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.

If I were going to build a whole house, rather than just a spice rack, I’d still need a tape measure, a saw, a level, and a hammer (among other things).

So I go to the hardware store to buy the tools, and I ask the sales clerk where I can find a hammer.

"A hammer?" he asks. "Nobody really buys hammers anymore. They’re kind of old fashioned."

Surprised at this development, I ask him why."

discuss.joelonsoftware.com/default.asp?joel.3.219431.22