Inexperience Generates Failure

I consult across the US. I'm often asked to consult on projects when they are already in trouble. When I visit these projects, I'm regularly amazed at how little experience the teams have. I mention this to management. They say "we just can't find good people!"

Studying the code, I find really ugly stuff. The programmers have no idea how to evolve a good design. They certainly don't know how to Refactor.

So if they embrace XP, but still don't have a full-time person who understands how to do EvolutionaryDesign, are they still doomed? -- JoshuaKerievsky

This is a valid concern. If no one on the project knows what good code looks like, you get (guess what) code that doesn't look good. Some years ago, Ward Cunningham declared the OakTree? code to be "mediocre". It really hurt my feelings at the time. Now, N years later, I know a lot of what he meant.

There are things that help. Programming from intention helps, for example. TestFirstProgramming helps. I'm not yet convinced that they're sufficient - I'm sure that I'd rather have experienced XPers over inexperienced. -- RonJeffries

Would it help if the team studied Patterns and learned how not to overuse them, but how to consider them as targets for Refactorings? (Ron, have I now given away my identity? :-)

One question is whether refactoring should have a target. Maybe the code doesn't want to be Command. I know a few million algorithms and it's hard not to think of one in the instant of arrival of a problem. However, I generally get better code when I program my IntentionNotAlgorithm. I hypothesize that less experienced programmers, who do not have algorithms but do have (we hope) intentions, would do better also. -- rj

I agree that there's a great opportunity for the untrained (aka unspoilt) to overtake many software sophisticates - if they learn the essence of XP early and never experience development where BusinessValueFirst doesn't apply(whatever the pressures). Within such a team there's still a place for the crafty input of those with genuinely useful experience, what NickSimons and I prefer to call know-how. See KnowHowToGrow. -- RichardDrake

Ron, Richard,

When I was 19, I worked at a bank and wrote a risk calculator. It contained a 12-foot-long case statement to control and capture UI input for a variety of loans. This calculator worked beautifully and was distributed and used at bank branches world-wide. At the time, I was completely focused on BusinessValueFirst.

But I was also interested in making code that was easier to extend - mainly because I was the one extending the functionality of this software for many years. I continually strove to improve my design, and refactored constantly (with manual tests to ensure that I'd not introduced bugs). In any event, I never did sufficiently simplify that huge case statement, even though I eliminated tons of duplicate code (OnceAndOnlyOnce).

To have achieved some significant simplifications in the design, I would have needed to know what I'm now calling extra-strength Refactorings - that is, I would've needed to know Patterns. -- JoshuaKerievsky

Could the program have been written from the beginning without the giant case statement? For that matter, is there anything actually wrong with a giant case statement, if all each case does is call one function? -- rj

I think so, if only because it's difficult to locate which case you're looking for. When I've seen HugeCaseStatements in code, it's usually been an indication that I should do things some other way, (usually involving PolyMorphism,) and the first step to refactoring the case is moving the logic into a bunch of separate functions (usually all named "execute" in a bunch of different classes, all implementing the "Command" interface). -- BlakeWinton

This is a very important question - it certainly reflects the real world that I've experienced as a consultant. Realism is what we have lacked throughout the history of software method as I see it. The more realistic we are the less room there is for much of our cleverness and we don't like that. Although XP has corrected this to a great extent it isn't immune from the disease. Perhaps one day we'll realize AllMethodIsFantasy?

With this rather jaundiced view of our efforts so far I'm not at all sure that I would start with patterns as the answer. In fact I'm sure I wouldn't. I agree wholeheartedly with TestFirstProgramming. I'd simply add the VerySmallSteps of EvolutionaryDelivery and XP. The more inexperienced you are the more VerySmallSteps helps with risk. The more experienced you are the more VerySmallSteps helps with value.

Uncoded this means that more projects would be canned much sooner. This would then improve the ratio of experienced to inexperienced programmers. I'm not joking.

-- RichardDrake

Why don't they send someone to get some training?

Out of project training can only take you so far. If you commit to VerySmallSteps, TestFirst and PairProgramming you are more likely to learn something of real value than on most courses.

Sorry I should have said XP training, like XpImmersionTwo.

How come I believe that it would be the best kind there is. I guess it's the WikiBrainWashing? - in the very best sense of the three morphemes.

PairProgramming can be quite educational, provided your pair actually knows something. Inexperienced teams lack people who know something, and you know what, InexperiencedTeamsAreRampant in our industry. Sorry couldn't resist.

Training is largely ineffective because most trainers aren't practitioners. Totally agreed.

Imagine a popular, well-marketed, product called X. Real programmers use X, and learn what works and what doesn't in X. Say for instance, they learn that the Event Service in X, truly blows. No fool would use it. Now, consider the training classes on product X. The training schedule gives 2.5 hours of lecture to X's Event Service, along with 1 hours of lab. So, 3.5 hours spent on a part of X that no one should be using. So typical, so dumb, such a waste of time. It makes me ill.

RichardDrake insists that he said that he is sure that Patterns aren't the primary issue that he personally would emphasize to an inexperienced team. I don't believe for a second that we have the same idea about what Patterns are.

In my experience, inexperienced developers need to imbibe sound programming and design knowledge as early as possible. In addition, they absolutely need to learn to test first (or 2nd), take small steps, and everything else that XP says.

Inexperienced folks can not let the code go where it wants to go. They need help seeing what possible directions to take it in. Patterns provide them with targets for their Refactorings. But Patterns can be badly overused - and it takes time to learn to use them intelligently by taking small steps - applying them only when they do indeed solve a problem, and implementing them in the simplest way first. -- JoshuaKerievsky (also see ExtremeProgrammingAndPatterns)

I may not have the faintest clue of what Patterns means to you are but at least I knew enough about the subject to guess you originated the page Joshua!

awww, gave myself away again! I've got to start talking about something besides Patterns! :-)

I'm prepared to accept that Refactoring and Patterns are two sides of the same coin. I personally would always emphasize refactoring towards the SimplestThing giving rise to patterns mostly unconsciously within the context of VerySmallSteps of delivery to customers. I have seen this kind of emphasis do some pretty amazing things - like allow a new programmer to write some software that helped create and support a fund of $110M. If we'd added more emphasis on patterns I don't know how it would have affected the outcome. But I do respect your point of view in saying that more education on patterns is going to be needed for inexperienced teams. Time will tell. ScientificMethod and all that. -- RichardDrake

I have a little trouble with the let-patterns-emerge idea. I like it, but mistrust it. First, if a team doesn't know the Command pattern, for instance, I doubt it will ever emerge in their design. And yet it could be the key to making their system simple and easily extensible. Command has certainly done wonders for my code and actually has made my clients quite happy. I find it is the same with many more Patterns and PatternLanguages. They don't naturally emerge, but they do solve problems. Have you read the forWard to the PragmaticProgrammer? -- JoshuaKerievsky I didn't get the clever forWard reference immediately. Just looking at the great man's thoughts in http://c2.com/doc/pragmatic.html. Thanks. -- rd

No I'm too busy with Wiki and the rest of my life - in decreasing order of precedence it sometimes seems. But I happen to distrust the Command pattern in the hands of inexperienced people based on some real project experience in 1999 ... even though I happened to like it as implemented MacApp in Clascal when I first came across it in ... when did Noah land that ark again? -- RichardDrake

Interesting. I'm extremely curious to know what went wrong with Command on that project. Such stories are invaluable when helping folks learn the right ways to use Patterns. -- jk ok, this is JohannSebastianBach calling Buxtehude, are you receiving me? I'd like to give at least two points of view on this one in other words. Watch a space near here.

When I first used patterns I used the pattern book as a reference book. I tried to define the context of my problem and find a pattern which fit in. Since I found XP I find EmergingPatterns from the code as I refactor it. The hard part now is not second guessing what patterns will evolve. -- ErikMeade

That's well said but there's been another pretty hard part for me - when you do in fact know which pattern should emerge from refactoring but the code is sufficiently far from it, the budget (and customer trust) is limited and a lot of BusinessValueFirst needs to happen in a hurry to retrieve the situation. The pattern you know in an idealistic way should be there can become just another attempt to escape the nasty, messy reality and give you a nice set of GangOfFour approved excuses for failure.

I hope Wikiphiles and patternistas everywhere will forgive me if I say that some pages around here give me the impression that our answer to stuggling developers in these very common, very challenging situations matches the Irish villager who when asked by a lost motorist the way to Cork said: "If I was going to Cork I wouldn't start from here." Sometimes there is a way through to success and better factored code. Finding it and having the guts to see it through transforms a team in a way they can't teach either at Harvard Business School or your local UML course. -- RichardDrake

Well, I got a severe kicking on comp.lang.* a while ago with this idea, I'll be interested to see how it goes on Wiki...

And (good) programmers are naturally inclined to think abstractly, metaphorically, analogously, deterministically, logically; to solve problems, to be scientific, to be mystic, to focus, to learn and to play!

Totally wrong. The wrong way round, anyway. People who naturally are inclined to think abstractly, metaphorically, analogously, deterministically, logically; to solve problems, to be scientific, to be mystic, to focus, to learn and to play may make good programmers, if they are so inclined.

These traits aren't widely distributed in the general population.

Indeed they are not, so why limit the search for them amongst the small minority who have already shown an interest in programming?

In my experience in the UK commercial software industry, most of the best software developers have not had a background in "computer science", or "programming". They have been, variously: mathematicians, physicists, electrical engineers, philosophers. I've heard that musicians and zooologists also do very well. There are, of course, exceptions. You may know some

-- KeithBraithwaite

I second most of that. My first boss avoided comp scis at all cost. I have modified that to ... "if we can't find someone more open-minded". There are, of course, exceptions as you say. -- rd

Thats an interesting corroboration, and a wise caveat. The folks on comp.lang.* thought I was a lone maniac, I think.

From above ... Could the program have been written from the beginning without the giant case statement? For that matter, is there anything actually wrong with a giant case statement, if all each case does is call one function? -- rj

Well, I've got a pretty big one in Java right now, as a result of backing out of a Command pattern extra-strength Refactoring started the middle of last year (discussed with Joshua above). Anyone like to RemoteRefactor? me out of this one? Meanwhile I'm just plugging away at obvious OnceAndOnlyOnce problems and just don't see the need to touch it ... yet. -- rd

People who naturally are inclined to think abstractly, metaphorically, analogously, deterministically, logically; to solve problems, to be scientific, to be mystic, to focus, to learn and to play may make good programmers, if they are so inclined.

I agree. Mapper-thinkers make good programmers because programming is mapping. See MappersVsPackers.

Newbies call documents and versions "final X". However, they often end up being "final final X" and "really final final X". Experienced people give them version numbers.

See AvoidCompSci, SinkOrSwim