The Myth of the Aging Developer

I question that I've heard throughout my career is, "What happens to older software developers?" The danger with this question is when the discussion turns to the implied version which is "The lack of older developers means that it is a young persons game." Nothing could be further from the truth..

My wife and I are both developers. We have both been working as developers for 15+ years. One thing we noticed was that there were a lot of people working as developers who really shouldn't be, they didn't have the aptitude, interest or sometimes even the background. It would be easy to dismiss the problem as a lack of proper education but that doesn't explain the developers who lack a CS degree but who can code circles around veteran devs. Those folks usually decide that programming is not for them and move on to different job. Some go into management, some become analysts, while others change careers completely.

What's left? The ones who are passionate about development and are interested in doing it right. They love learning new stuff and don't gripe about how things used to be in "The good ole' days." They might be grumpy but they usually know their stuff.

The main problem would be in finding management who doesn't have a pre-conceived notion about what makes a good developer. If they feel that only the younger ones have the stamina to keep up with the pace, I'd wonder whether those same employers were the same ones who believe that the 'Deathmarch' style of project management is standard operating procedure. They'd rather grind through fresh-meat developers (Code-Monkeys anyone?) than listen to the experienced ones and change their development process much less change their management style.

Lastly, I've noticed that doing nothing but coding holds less business value than being able to communicate with customers, users, management, and vendors. One reason you start coding less is because finding answers to ambiguous requirements takes more experience and provides more payback to the business.

My advice, to those who worry about their coding future, would be to find a place where they need experienced developers to help with the overall task of creating or maintaining software, that also gives you the opportunity to code regularly. That way you can have the time to keep up with industry changes while taking advantage of your understanding of software development.

Programmers - Poets or Mathematicians?

Programming software is much like writing a story. Any given story can be told in a near-infinite number of ways and those who practice the craft will spend just as much time, if not more, arguing over the style of a work, as if their subjective opinion can suddenly become objective fact. Usually this leads to a contest of "If you don't agree with me, I'll just keep talking until you see reason" or otherwise known as talking the subject to death.

I thought I'd shine some light on an example of this issue in programming. There is a never-ending debate in programming circles about the 'proper' way to write code that creates some true/false decision. Stackoverflow has a good example of this.

My personal pet peeve (petty but my teeth grind everytime I see it) is verbosely setting booleans, e.g.

bool isValid;
if (percentage >= 0 && percentage <= 100)
  isValid = true;
else
  isValid = false;

whats wrong with

bool isValid = percentage >= 0 && percentage <= 100;

It's soooooo much more succinct and easier on the eye

Even though the single line version isn't the most complex, different people read through code in different ways. A single expression can be easily parsed by people who have a math background or are experienced coders. That's not the point. The expanded version reads more like a sentence than a formula. It's easy to forget that there are plenty of coders without a background in math. It really comes back to the preferred style of the reader. Do they prefer reading expressions and formulae or something more like human speech.

Homer's The Illiad and The Oddessy are ancient works dedicated to expressions of speech. They were originally poems that were passed down in an oral tradition and meant to be sung instead of read.

Euclid's Elements is a work dedicated to expressions of logic. It covers objective proofs and unambiguous facts and is the beginning of the mathematical tradition, if you will, of rigorous scientific thinking.

The problem we face in software is code is a form of human expression, with all the imprecision that entails, attempting to communicate with the utterly logical CPU; programmers will be forever trying to translate "An Ode to the Machine" into the Pythagorean Theorem.

Why Extreme Programming Fails

In the decades of the young life of software development, we've discovered many behaviors, processes, and techniques which have nothing to do with software yet continue to hold back progress. We ask time and time again why the mythical silver bullet is still searched for by those who have already agreed that it is a fools errand. Why are death-marches allowed to form when the futility is obvious to all but the oblivious? Why are proven techniques not mandated by management or agreed to by the workers who constantly complain about the current poor practices? This is true whether we're discussing XP or Agile or SCRUM.

We can use rational thought to decipher the mystery, attempting to achieve clarity. However much success is possible in finding rational explanations, there comes a time when we must recognize the difference between clarity and understanding. We can state things extremely clearly and succinctly and still fail to understand why people continue their unproductive habits or why change is viewed by those in charge with such disdain.

Submitted here for your edification, The 48 Laws of Power.

Why does that developer refuse to pair with someone? There are lots of reasons, i.e. Law #1 - Never Outshine the Master or law #30 - Make your Accomplishments Seem Effortless, are good places to start. Why is Continuous Integration scoffed at? See law #11 - Learn to Keep People Dependent on You

The words 'politics' or 'management' may seem like pejoratives but they serve as simple placeholders for the understanding of human behavior. At their worst, they can be weapons in a Machiavellian conflict while at their best they can be the protective shield against those who see your efforts as a challenge to their plans. Is every use of these laws an instance of plotting and scheming? No, never forget that human nature operates below the level of conscious thought; these behaviors are ancient artifacts used for thousands of years to survive in a violent and irrational world. Disagree with them all you'd like but ignoring them can easily cost you your job.

Chapter 3 - How Can We Study Programming?

This is a continuation of the review of Gerald M. Weinberg's book, The Psychology of Computer Programming. The review begins here for Chapter 1 - Reading Programs. The post on Chapter 2 can be found here.

What chance have we to understand the human factor? How do you study programming when the important majority of it takes place between one's ears?

Perhaps programming is too complex a behavior to be studied and must remain largely a mysterious process.

INTROSPECTION

Although some modern students of human behavior tend to discredit it as nonscientific, introspection has always been the first foundation stone of their science.

The author tells a story about a student having difficulty with a particular PL/I programming problem:

ANGLES(I)=2*ATAND(SQRT((S-A(IND(I,1)))*(S-A(IND(I,2))))/(S*(S-A(IND(I,3))))));

When it was finished the author asked the student to recall the thought processes -- the difficulties -- he had experienced with this statement, here is that list.

1. He had trouble getting the parentheses matched, because there were so many of them.
2. The original ANGLES(i) was a structure, not an arry, so the compiler complained of an illegal subscript list, but he had not been able to find the problem because there were so many subscript lists.
3. When the program finally got into execution, there were these further difficulties:
1. IND was a matrix on another page of the listing, and he had trouble finding it.
2. Even though the parentheses were now matched, one pair was in the wrong place and was most difficult to find.
3. The last difficulty turned out to be a problem of precision caused by capricious declaration of different data types, by the large expression, and by the division--which would not have been necessary if the two-argument form of ATAND had been used.

The student provided a number of insights, from the proper size of statements, the choice of data structures, to the design of compiler and execution-time diagnostics.

None of these insights could be obtained without introspection of this sort, yet thousands of programmers [millions now days - ed.] each day have theses same problems and simply grumble that they are having "bugs." Without the introspection, they will simply continue to have "bugs" until, in the end, the bugs will have them.

From this single instance of introspection, we could come up with "Laws of Programming"

1. The mind cannot cope with more than five levels of parentheses.
2. Compiler diagnostics should be more explicit.
3. PL/I precision rules are too complicated to use.

Although each of these statements might turn out to be a "law" in the psychology of programming, writing it on the basis of a single introspective example hardly qualifies it as a law. To be a "law," a principle must be explored so as to set limits to its application, because all laws have limits. Indeed, the limits are Usually more important to know than the laws themselves, and it is only by investigating a multitude of cases that limits can be set. Thus, without introspections, investigation would be sterile, but without investigation, introspection will be of questionable value in application.

OBSERVATION

One way to follow up introspection is by observation of what people actually do, as opposed to what they think they do.

Like the study of parentheses and how many levels of nesting programmers use.

One of the problems with observation, however, is that it tells us what people do do, but not necessarily what they can do.

If your census showed that programmers never nested parentheses more than 5 levels deep, does that mean they are unable to?

A second problem with observation is deciding just what it is we are observing.

All you know about the programmers who limit themselves to 5 levels of parentheses is a simple fact, to know why they don't use 6 or more would of course require introspection on the programmers part. If you were designing a language, would you limit the size of arrays to three dimensions simply because you've never seen anyone use more?

A third problem with observation is the problem of interference of the observer with the subject being observed.

This is called the "Hawthorne Effect". The act of observing workers actually affected their performance, a kind of uncertainty principle.

EXPERIMENT

Here is a very interesting section where the author describes the costs of conducting experiments on programmers using typical experimental psychology methods. How do you collect data without influencing the results. To a degree it is somewhat like the problem of testing the performance of a program. The modifications necessary to observe the programs use of memory or CPU time actually uses memory and CPU time so how can you know your results haven't been skewed?

You could do experiments using programming majors in school but would the results apply to professionals? You could study professionals but that could be prohibitively expensive. The author describes doing an experiment using one-quarter time of nine experienced programmers for three months. The average salary was $14,000 [I'm assuming annually - ed.], add in overhead (workspace, machine time, etc.) came to $20,000 apiece, or $1250 apiece over the course of the study. Add to that the experimenters salaries and so forth and the bill comes to $30,000 for nine subjects. [In 1970 dollars! - ed.] Using the Inflation Calculator ($30,000 in 1970 compared to 2009) this comes out to a cost of $163,254.90. Serious money, just to study programming.

... we must deal with one other problem, which is important because of a seldom-questioned view of programming. That view is that programming is an individual activity, not a social activity.

Not that the individual level is unimportant, but we might start by asking why, if the average programmer spends two-thirds of his time working with other people rather than working alone (yes, it's true!), that 99 percent of the studies have been on individual programmers.

The answer is that it is expensive to study programmers in groups. Plus, you can't put a number of trainees together and call them a 'team'.

Putting a bunch of people to work on the same problem doesn't make them a team--as the sloppy performance in all-star games should teach us.

The neglect of social effects also casts doubt upon all individual studies, since these studies force the individual to separate himself from his normal working environment. In one of our studies, one of the programmers came to me when he had finished coding and asked who could check his work. In his home group, this was standard practice at this point in development, but it was not allowed during the study -- lest it should "invalidate" the results.

Looking back, it seems that forcing programmers to work in isolation is like trying to study the swimming behavior of frogs by cutting off their legs and putting those legs in the water to watch them swim. After all, everyone knows that the frog swims with its legs, so why complicate the experiments with all the rest of the frog?

PSYCHOLOGICAL MEASUREMENT

For the present, most of the work in the psychology of programming is going to have to be "looking for questions."

I conjecture that we will move beyond looking for questions only when we start believing and acting on the questions that we've found over the almost 40 years since this book was published. This is definitely not a programming problem. When the software managers are able to dictate practices based on a whim or the local political winds, "We don't have time to do code reviews! Why can't you just make it work? I don't understand why it's constantly breaking!", you might start looking for answers in the abnormal psychology section of the library.

USING BEHAVIORAL SCIENCE DATA

Because of the nature of programming, there is not much hope that actual results can be transferred directly from other fields to ours. Our use of results has to be for insights, not for answers.

So maybe all those comparisons with engineering and construction are invalid on the face of it. We might look at Paul Graham's book Hackers and Painters for insight.

Finally, as we pass successfully through all this, we may find ourselves in a sufficiently objective frame of mind to examine some of the myths of programming -- the articles of programming faith. Faith, as Bertrand Russell pointed out, is the belief in something for which there is no evidence; and myths, as Ambrose Bierce once defined them, are the sacred beliefs of other people. Perhaps we shall simply carry away our old beliefs unchanged, but if just one unfounded programming myth should die as a result, this book will have been worth the effort.

SUMMARY

Common pitfalls:

1. Using introspection without validation.
2. Use of observation on an overly narrow base.
3. Observing the wrong variables, or failing to observe the right ones.
4. Interfering with the observed phenomenon.
5. Generating too much data and not enough information.
6. Overly constraining experiments.
7. Depending excessively on trainees as subjects.
8. Failing to study group effects and group behaviour.
9. Measuring what is simple to measure.
10. Using unjustified precision.

1. 
   

Several of these items have had some attention paid to them over the last decade. Extreme Programming was one of the first movements focused on groups of developers to get enough traction to garner a following. There are several similar movements, SCRUM, Agile, etc. Instead of assuming the problem was in the process that humans were following, they finally addressed the human factor as a first-order success factor (thanks to Alistair Cockburn)

The question is, when will we learn that we are the problem?


This ends Part 1 - Programming as Human Performance. Next up is Part 2 Chapter 4 - Programming as a Social Activity

Review - The Psychology of Computer Programming

I got a "new" book in the mail a few weeks ago and finally had time to crack it open, "The Psychology of Computer Programming" by Gerald M. Weinberg published in 1971. There is a Silver Anniversary edition that recently came out but I wanted a cheap copy in hardback so mine came from an online used book site. Why read a computer programming book that is almost as old as myself? Because it addresses the core issue of producing computer programs, the people who read, write, edit, maintain, or otherwise cuss at (other people's of course), code. People are the primary factor in all programs; before hardware, language, specifications, anything. If you don't understand how humans go about creating these abstract entities called programs, you will constantly be mystified by missed deadlines, frustrated by missing functionality, and stymied by endless scope creep. Enough of my pontificating, let's talk about the book.

Table of Contents

1. Programming as Human Performance




1. Reading Programs


2. What Makes a Good Program?


3. How Can We Study Programming?




2. Programming as a Social Activity




4. The Programming Group


5. The Programming Team


6. The Programming Project




3. Programming as an Individual Activity




7. Variations in the Programming Task


8. Personality Factors


9. Intelligence, or Problem-Solving Ability


10. 1Motivation, Training, and Experience




4. Programming Tools




11. Programming Languages


12. Some Principles for Programming Language Design


13. Other Programming Tools




5. Epilogue

"Computer programming is a human activity." A pretty bold thesis from the intro to Part I. Is there a mystique to programming? "Either you can program or you cannot. Some have it; some don't." Both quotes give you a good idea as to what is in this book, tackled expertly by Mr. Weinberg.

Chapter 1 - Reading Programs

Some years ago, when COBOL was the great white programming hope, one heard much talk of the possibility of executives being able to read programs. Weith the perspective of time, we can see that this claim was merely inteded to attract the funds of exectutives who hoped to free themselves from bondage to their programmers. Nobody can seriously have believed that executives could read programs. Why should they? Even programmers do not read programs.

I hear a similar story from when assemblers were introduced - as in, "With the development of assemblers, we won't need programmers anymore!" I believe similar statements have been propagated by hordes of 4th generation language and CASE salesmen.

"Programming is, among other things, a kind of writing."

This is not a very mainstream view in the programming world even though we work with constructs which are literally "languages".

"We shall need a method of approach for reading programs, for, unlike novels, the best way to read them is not always from beginning to end. They are not even like mysteries, where we can turn to the penultimate page for the best part -- or like sexy books, which we can let fall open to the most creased pages in order to find the warmest passages. No, the good parts of a program are not found in any necessary places -- although we will later see how we can discover crucial sections for such tasks as debugging and optimization. Instead, we might base our reading on a conceptual framework consisting of the origin of each part. In other words, as we look at each peice of code, we ask ourselves the questions, 'Why is this piece here?'"

The author begins examining a section of PL/I code showing how certain machine, language, and human limitations influence a program. Machine limitations like lack of memory to hold the entire problem set in memory at the same time causing the use of two loops instead of one. Language limitations like the lack of an end-of-file indicator which forces the operators to include a special character (or card in the 1970's punch-card centric world) and causes the programmer to account for the special character in code. Programmer limitations like not really understanding array notation of the language, in this instance PL/I. As a program is modified over time, machines change, languages are updated, and programmers come and go.

"And so, some years later, a novice programmer who is given the job of modifying this program will congratulate himself for knowing more about PL/I than the person who originally wrote this program. Since that person is probably his supervisor, an unhealthy attitude may develop -- which, incidentally, is another psychological reality of programming life which we shall have to face eventually."

Some programs have inscrutable logic like the use of special characters which are ordinarily invalid; "magic numbers" used for interim states for some long-forgotten problem.

"Once the patch was made, it worked so well that everyone forgot about it -- more psychology -- and there it sat until unearthed many years later by two archeologist programmers."

To different versions of the same PL/I program are compared, the first includes many limitations of which we've already spoken, the second much improved by removal of the previous limitations. Of the comparison,

"When we look at the difference between Figures 1-1 and 1-4, we might begin to believe that very little of the coding that is done in the world has much to do with the problems we are trying to solve"

Would we be any better off if we could use the latest code (Figure 1-4) as our spec?

"Specifications evolve together with programs and programmers. Writing a program is a process of learning -- both for the programmer and the person who commissions the program. Moreover, this learning takes place in the context of a particular machine, a particular programming language, a particular programmer or programming team in a particular working environment, and a particular set of historical events that determine not just the form of the code but also what the code does!

In a way, the most important reason for stufying the process by which programs are written by people is not to make the programs more efficient, more compact, cheaper, or more easily understood. Instead, the most important gain is the prospect of getting from our programs what we really want -- rather than just whatever we can manage to produce in our fumbling, bumbling way"

Hopefully the reason to study a 30+ year-old book is apparent; those who fail to learn from history are bound to repeat it.

Let's study historical mistakes so we can make our own new mistakes instead of repeating mistakes of programmers long-retired.

The rest of the book is just as rich in lessons we can still take to heart. By approaching the book chapter by chapter, I'm hoping to increase my chances of getting all the way through without writing a 50-page article all at once which would never get finished.

Here is the link for the next chapter: Chapter 2 - What Makes a Good Program

The Tale of Two Managers

Is the company you work for serious about software development? How can you tell whether your manager is susceptible to the "Death March" management style you ask? Let's discuss a negative case and go from there.

I have a new definition of 'Chaos Theory'. Those who don't understand how to develop software will never free themselves from the chaos caused by operating in constant crisis mode.

Have you ever worked for a boss who liked to give direction and expected their group to start running around doing anything because action == progress regardless of direction? Did we do stuff we didn't need to? So what, at least we're doing _something_. is their mantra. Imagine what would happen if we let modern skyscrapers be built this way. The financial backers would revolt because they'd have to write the check for all the re-work; the engineering team would go AWOL because their carefully evaluated design wasn't being followed; the workers would go on strike because of the unsafe work environment caused by the activity-for-activities-sake. If your manager never wants to discuss process (current or future) they might be trying to manage the chaos by dictating constant activity. My theory is those managers feel like they are having to flail like the dickens just to keep their heads above water because they don't want their team to know just how out of control they feel.
Let's call this manager "Suzy Spur" for her penchant for 'spurring' her team to action; her idea of effective management is making sure her cattle-prod has freshly charged batteries.

Now, let's switch gears to a large development project that has it's head on straight. While Eclipse is also a tool that Java developers use to create applications, it also has sprouted a mature project management template for coordinating large-scale (in number of apps involved) software releases.

The Eclipse organization has created a process that is rational, consistent, and repeatable. By thinking through the process beforehand, they do not have to make things up as they go. They release on-time and with high-quality even if that means leaving features behind. Here is a quote from the site

Ganymede is about improving the productivity of the developers working on top of Eclipse frameworks by providing a more transparent and predictable development cycle; Ganymede is about developers helping developers serve the whole Eclipse community

When the executives are clamoring for results, what they really are asking for is predictability. They want to know when they can plan on the next version of their application will be ready for release so they can plan their trip to Jackson Hole (for those without spouses) or Orlando (for those with families). What they don't want is a make-it-up-as-you-go process, of which Suzy Spur is so fond, that will send them to Las Vegas in August with no AC.

In comes "Craig Calm". He acts deliberately, instead of by reflex. He surveys the road ahead and lays out a route which will get him to his destination with a minimum of fuss instead of bouncing over each hill unable to see over the next rise. He prepares the project foundation so the flurry of change means asking different interior designers for their ideas on the finishing touches instead of tearing out walls because they were put up before the wiring and pumbing were installed. He is respected because his team can plan time off because his projects are always on-time or any delays are expiditiously relayed to the proper governance group; instead of reviled due to the ever-cracking whip and constantly worrying about being fired right before a family vacation because the project is always behind the eight ball -- the deadline never moving regardless of the increased workload.

When a deadline doesn't move even though the work increases, that is a classic sign of inadequate risk management. If you (project) manager is not insane, a sliding schedules would be a simple result of project math: Workload divided by resources = timeline. Of course I'm over simplifying but let me use an analogy here. You are in charge of building a dam and one of the project assumptions is the area will get no more rain than the largest amount in the last 100 years. If halfway through the site gets deluged with twice the 100-year-record amount, you do not go to your team, at the waterlogged site, and say "Guys, just work harder" or my favorite "Work Smarter". What the sane project manager does is go to the sponser and say, "We didn't plan on this, we're going to have to start over." It is not the fault of the team or of the project plan when the sponser approved the assumptions and then came up short. The book "Waltzing With Bears" is a fantastic resource on the subject of proper risk management and how it can restore sanity to your project.

So, for whom would you rather work? The insane activity-for-its-own-sake pile-driver or the methodical, consisent, and goes-home-by-five software development veteran?

Stalking a Serial Thinker

Some people think using groups of lists (1 dimensional) , others can think in grids (2 dimensional). I ran across this phenomenon when I was in a requirements gathering session for a complex revenue accounting system. Many of the components of the system had several attributes in common. The example I'll use is a family of four (Mom, Dad, little Gary, little Jan) and their bicycles. One way to describe the bikes is list each of the separately by the owner and then their attributes. For a serial thinker (let's call them Serial Sue), it looks like this:

Bike1
Owner: Mom
Type: Touring
Gears: 15
Size: 26-inch
Color: blue
Make: Trek
Model: Super-Safe Sidewalk
Wheels: street
Accessories: water bottle

Bike2
Owner: Dad
Type: Hybrid
Gears: 18
Size: 28-inch
Color: black
Make: Specialized
Model: Trail-aways
Wheels: knobby
Accessories: speedometer

Bike3
Owner: Gary
Type: Mountain
Gears: 24
Size: 26-inch
Color: red
Make: Specialized
Model: Porche
Wheels: knobby
Accessories: rear view mirror

Bike4
Owner: Jan
Type: learning
Gears: 0
Size: 16-inch
Color: yellow
Make: Murray
Model: Princess
Wheels: street
Accessories: handlebar tassels


Notice how each bike repeated all the attribute names? No big deal right? What if you now need to add 2 more attributes to each bike, or 4, or 10? You would have a lot of editing in your future.

Don't get ahead of me here but another way to organize this data is with a grid (aka a spreadsheet) which could look like this:

	Bike4	Bike3	Bike2	Bike1
Owner	Jan	Gary	Dad	Mom
Type	learning	Mountain	Hybrid	Touring
Gears	0	24	18	15
Size	16-inch	26-inch	28-inch	26-inch
Color	yellow	black	red	blue
Make	Murray	Specialized	Specialized	Trek
Model	Princess	Peaks-r-us	Trail-aways	Super-Safe Sidewalk
Wheels	street	knobby	knobby	street
Accessories	handlebar tassels	none	speedometer	water bottle

In this form it becomes easy to add categories and/or bikes; thus maintaining the list in an efficient manner. The problem? Describing this method to a Serial-Sue will confuse them. They'll ask, "Why go to the trouble of creating a grid, all I want is a list?" You might think that it is a simple matter of just do it they way your boss wants. That is fair but there is more to the story. When dealing with a large list of semi-related things, using categories to subdivide the items can be an enormous help in simplifying the organization and can help bring order out of the chaos.

Another clue you are dealing with a serial thinker is if you show her a grid and then have to explain it. It takes a different sort of brain. Much like how some people can't read maps well, go figure. Watch for symptoms of frustration when showing or explaining a grid of data to someone, it could be that you've botched your data, but it could also be a sign of serial thinking.

So, do you work for/with a Serial-Sue?

Intolerance of Vision

I've always been the type who likes to look far ahead on whatever trail I find myself. When I can see some obstacle, it only seems logical to report back to whomever is in command so they can make appropriate plans. What I've discovered is that some commanders are allergic to news portraying events beyond their mental horizon. "It's not going to happen for a week/month/year, why do you want me to worry about it?" That's a fair argument when you're in the heat of battle but rings empty when you're safe at home, eating dinner in front of the fireplace or when the battle-stations alarm is constantly clanging in your ear because everything is a crisis.

To ignore what lies ahead takes one of two types of people. The first is constantly in battle-mode and never feels like the have the luxury of looking down the road. There are managers who take this to the extreme by operating in this mode all the time and make management-by-crisis their modus operandi. If it doesn't get immediate results, they're not interested. It doesn't matter if doing things the easy way now will create 10 times more work later, the mantra is "why is it taking so long and when can we be done?" Quality, safety, sanity, all take a back seat to expediancy. The second type of person has a devil-may-care attitude and lives with their head in the sand. Worring about what might happen is for those wet-blanket types who keep telling me what to do like "wear your seatbelt" or "quit smoking". Nag nag nag, that's all they do. Can't they stop whining and live a little? While the latter is a case of simple denial, the former is clearly one of short-sightedness.

This brings me to tolerance. Imagine if General Custer had had a scout who kept him informed on the location of the belligerent Indian tribes but Custer got so annoyed by the constant reminders of upcoming trouble that he fired the scout. Having such a low tolerance for long-range vision (of both good and bad news) becomes a grim mistake. Having kept said scout and charging ahead anyway is completely within a commanders decision-making authority. It would not prevent the upcoming catastrophe but puts the mantle of blame solely on the commander. The scout's responsibility is to report what he sees and would be derelict in his duty to stay silent. The commander will be responsible for whatever happens regardless but ignoring information snatches from his grip the haven of excuses and tightens the noose of history around the neck of his legacy.

The deluded commanders ignore harbingers of bad news while deranged commander shoots them. The pragmatic one listens but takes his own counsel. At the very least, having another warm body around means one more person you can hand a weapon when you've circled the wagons and are faced with a relentless oncoming horde.

Do you know someone with a low tolerance of Vision? It'll take more than a visit to the eye-doctor to take off the blinders and open their eyes. Let me know if you discover an effective vaccine for this particularly nasty disease.

Fred Brooks meets Mozart

For some reason, as I started to read this blog entry I thought that a better analogy would be that writing software is like writing music for hire.

Music has well established connections with mathematics. That doesn't mean I'm going to hold my breath waiting for my computer to compose 'The Magic Flute'.

I started to describe the idea to my friend Craig and the more I talked the more apt the comparison became. It's partly ephemeral yet can be reproduced in the real world and its acceptance is controlled by someone other than the writer.

It also depends on those who perform the instructions. Maybe coding is like writing a symphony. You can write as grandly as Bach or Mozart but if the players are terrible, so will the performance. The same goes for good players using poor instruments, or good players using good instruments but having a poor conductor, or having all the players and conductor as first rate but the audience is completely tone-deaf.

Maybe we have Code-Cowboys instead of Virtuosos or Divas.

Ok, instead of a symphony, it would be an opera. In addition to the symphony (for the music) you have a company of actors with which to contend.

My friend Craig chimes in with: and a director

Now you're getting it.

Think about estimating how long it would take to put on a production of an opera that had never been done?

The estimate would be pretty worthless because it depends on how long it takes to do the casting, figure the lighting, blocking the scenes, creating the scenery and all that is dependent upon the budget.

Craig:Yes - building the stage is like erecting the infrastructure for a platform not currently used. You have to set up sound, seating, temperature, etc

Talented individuals can create great performances, they can make it seem effortless. We even have terms for these people in the arts. An singer can be a 'diva' and a musician can be a 'virtuoso'. When we limit the scope to the talent of a single individual we can get good material but what marks transcendent art is when the creator inspires the performer using the sheer force of ideas alone.


Music expresses that which cannot be said and on which it is impossible to be silent. ~Victor Hugo

Can this be the equivalent driving force behind the open source movement? There is an idea that needs expressed, the code, compiler, and CPU serving as the artist's paints, brushes and canvas. The Software Craftsmanship movement has much in common with the artistic temperament.

The Codewright Mentality revisited

In my last post about the Codewright Mentality I had some fun at the expense of consultants. When my friend Paul, whom I met while he was a consultant, pointed out my over-generalized stereotyping of consultants, I felt that I needed to clarify my point. Being a consultant does not imply lacking drive to improve. I was going for humor but instead stepped on some toes. Don't get me wrong, if there are toes that need stepped-on I'm all for it, but this time he had me dead-to-rights.

Maybe I should have said contractors instead of consultants but that would have traded one set of toes for another. The truth is nobody has a monopoly on the lack of drive; this means contractors; as well as consultants; as well as full-time employees. I'm not sure there is a consistently used differentiation between consulting and contracting. The behavior in question is, for contractors they either did what we asked but no more or for consultants they gave us the answer to our question but no more. You would hope that if there was a better way to do something or a better question to ask, the contractor / consultant would mention it. Both assume the client being open-minded enough to listen. What we're describing is being optimistic about the intentions of those involved.

Paul's observation:

I also have noticed a tendency to blur the distinction between a consultant and a contractor in the IT world. I tend to perceive "contractors" as being hired for very specific skills (C++, Oracle, whatever) and as being mostly just complements to a team, rather than a facilitator/leader. The "contractee" often doesn't make the distinction because "consultants" are, like "contractors", just "not full time employees but being paid by us, directly or indirectly". Doesn't much matter, I suppose, so long as both parties agree on expectations.

I give Paul a lot of credit for helping me start thinking about programming as a craft and worthy of study in it's own right.

Here is what Paul had to say about what it means to be a Codewright:

For me, codewright-ship is...

• About not settling for intention-obscuring code
• About not settling for inarticulate requirements
• About seeking out other codewrights to learn from
• About seeking out codewright apprentices to teach
• About not settling for code without tests
• About believing there is something noble about programming
• About tuning out the voices of developers past who want you to think that coding is monkey business, or that quality is the testers' job, or that you have to figure it all out ahead of time before you write even one line of code.
  
• About realizing that simplicity is beautiful; and that the simplest things that could possibly work probably isn't the first thing you think of.
• About building systems people are passionate about using.
• About realizing that developing such software is difficult-- that maybe it shouldn't be easy -- that maybe gains in software productivity needn't or can't keep pace with such gains in hardware performance
• About creating sustainable solutions -- software that future maintenance programmers don't mind maintaining (as opposed to the mind-bogglingly putrid legacy code much software is).