LARubyConf 2009 - Danny Blitz - "Herding Tigers: Software Development and the Art of War"

I had no idea what I was about to experience at Los Angeles Ruby Conference 2009 (LARubyConf) when Danny Blitz took the podium as the next presenter. I had seen him hanging out with his distinctive pompadour, tattoos, and leather jacket. He is a big guy, and hard to miss. But he had been pretty quiet till then, which was about to change radically.

Herding Cats is a term commonly used when describing the management of software teams. But when Danny Blitz says cats, he means big cats aka tigers. So who is this guy? He has done TONS of stuff, from DOD to Dell, to the DARPA autonomous vehicle challenge. Very cool stuff.

Get Agility?

"A good plan violently executed now is better than a perfect plan executed next week" - Patton

Q. Why is software so difficult?
A. We don't want to face the truth

Q. Why don't we want to face the truth?
A. We're afraid

Q. What are we afraid of?
A. We're afraid we do not know anything about end result

Q. How can we deal with this?
A. Admit the truth

A tiger team is a small self improving team.

What can you expect from a tiger team?
Their first project was scheduled to take 5 weeks - took 5 days

TIGERS ARE A TEAM!

QA is part of tiger team

Tigers show leadership

Tigers self-improve

Almost no meetings on a tiger team

QA and test automation are the tip of the spear

QA should be there from very beginning

Shared psychology and intelligence

Winning, boldness, excellence

Not afraid of the dark

Who is on team?
- all staff needed to deliver product
- leader, 4 devs, 1 automation engineer, 1 Q, product staff m,ember
- in addition, architecture, system admins, any other support staff

why warfare?
- business is battle

There are two kinds of warfare: attrition and maneuver

Attrition warefare
- traditional, tactical
- clashing head-on

Maneuver warfare
- internet space
- rapid modern violent
- unexpected movements

Speed
- it is a competitive weapon
- undeniable advantage in business

Speed mitigates risk
- not a guarantee
- damage is contained by quickly compensating

Speed improves the team

Speed adds to job satisfaction

Speed allows agile to function properly
- max iteration length (usually 30 days)

Speed builds credibility
- shows a lot of work in short order

Cows and tigers
- cow is bigger, but who wins?

Disease: using agile terms to describe non-agile project

Corporate animal kingdom
- Tiger
cautious, calculating, looks to win

- Cow
herding
not known to be original
afraid of risk

- Bear
big, usually mellow
awesome battle skills
live and let live attitude

- Leopard
truly wild
will attack at any time

- Elephant
huge and tough
invincible
best to avoid battle

- Hyena
scavenger
steals food
evil

"Tiger teams are like Hell's Programmers" - Danny Blitz

Leadership
this is what makes or breaks
faith
love
hope
success belongs to the team
failure belongs to the leader
buck stops here
fearlessness
listener and learner
protector
outside influences
internally too
team members themselves

US marine management techniques
- manage by end state and intent
- reward failure
- demand to be questoned
- glorify the lower levels of organization

Politeness and professionalism
- that or poison

Agile is not a methodology, it is a mindset, it is inevitable

Danny says he is working on the book called "Herding Tigers". He has also started a blog at herdingtigers.com. All I can say is, he is a very dynamic and exciting speaker. Everyone was captivated, myself included. I'm still not sure how I took these notes.

Rock on, Danny!

Stop The Bug-Based Development

I enjoyed reading Phil Haack's little "you're either with us or against us" diatribe from earlier today, where he rails against non-test-driven development. I only differ in that I prefer to call it Bug-Based Development (BBD).

So are you one of those fifth-column types who is providing aid and comfort to the enemy? Draw a line in the sand... never make your troops take casualties retaking the same ground twice... no bastard ever won a war by dying for his country. You won it by making the other poor dumb bastard die for his country.

Give 'em hell, Phil!

I Speak For The Code

Recently I was in a client meeting with a bunch of managers to discuss some very complex changes that were being proposed for an existing system. I was invited to the meeting so I could "speak for the code", which to them meant that I could validate the ideas of the group based on my knowledge of the code base.

After the meeting ended, I kept mulling over that phrase "speaking for the code". The more I did, the more I realized the parallels between "speaking for the code" as an architect or lead developer, and the Lorax "speaking for the trees" in the Dr. Seuss story of the same name.

So here goes my attempt to illustrate some lessons about best practices in software development, inspired by the story of the Lorax...

At the far end of town where the Grickle-grass grows and the wind smells slow-and sour when it blows and no birds ever sing excepting old crows...is the Street of the Lifted Lorax.
And deep in the Grickle-grass, some people say, if you look deep enough you can still see, today, where the Lorax once stood just as long as it could before somebody lifted the Lorax away.

Our story begins looking at what remains of a once thriving software application, now gone to ruin. What went wrong?

What was the Lorax?
Any why was it there?
And why was it lifted and taken somewhere from the far end of town where the Grickle-grass grows?
The old Once-ler still lives here.
Ask him. He knows.

Perhaps the Lorax was the original system architect. But he is gone now, leaving behind Once-ler who is now in charge of the project.

You won´t see the Once-ler.
Don´t knock at his door.
He stays in his Lerkim on top of his store.
He stays in his Lerkim, cold under the roof,
where he makes his own clothes
out of miff-muffered moof.
And on special dank midnights in August,
he peeks out of the shutters
and sometimes he speaks
and tells how the Lorax was lifted away.
He´ll tell you, perhaps... if you´re willing to pay.
Then he hides what you paid him away in his Snuvv,
his secret strange hole in his gruvvulous glove.
Then he grunts, I will call you by Whisper-ma-Phone,
for the secrets I tell you are for your ears alone.

The Once-ler is the swamp guide project manager or developer who remains behind, holding on tightly to the secrets of the system.

Now I´ll tell you, he says, with his teeth sounding gray,
how the Lorax got lifted and taken away...
It all started way back... such a long, long time back...

Way back in the days when the grass was still green
and the pond was still wet
and the clouds were still clean,
and the song of the Swomee-Swans rang out in space...
one morning, I came to this glorious place.
And I first saw the trees! The Truffula Trees!
The bright-colored tufts of the Truffula Trees!
Mile after mile in the fresh morning breeze.

And under the trees, I saw Brown Bar-ba-loots
frisking about in their Bar-ba-loot suits
as they played in the shade and ate Truffula Fruits.

From the rippulous pond came the comfortable sound
of the Humming-Fish humming while splashing around.

The original system was a fine merger of art and science. It provided for all of the inhabitants of its software ecosystem (users, developers, testers, etc.) by using practices that conserved the ecology of the system. It was able to successfully grow from its origin to a useful level of functionality while preserving the environment of the code base.

In no time at all, I had built a small shop.
Then I chopped down a Truffula Tree with one chop.
And with great skillful skill and with great speedy speed,
I took the soft tuft. And I knitted a Thneed!

The instand I´d finished, I heard a ga-Zump!
I looked.
I saw something pop out of the stump
of the tree I´d chopped down. It was sort of a man.
Describe him?...That´s hard. I don´t know if I can.

He was shortish. And oldish.
And brownish. And mossy.
And he spoke with a voice
that was sharpish and bossy.

Mister! he said with a sawdusty sneeze,
I am the Lorax. I speak for the trees.
I speak for the trees, for the trees have no tongues.
And I´m asking you, sir, at the top of my lungs--
he was very upset as he shouted and puffed--
What´s that THING you´ve made out of my Truffula tuft?

The Once-ler took the original application in a direction that it was not architected to take, in a way that disturbed the equilibrium enough to attract the ire of the Lorax, who is the guardian for the system's logical integrity.

Look, Lorax, I said. There´s no cause for alarm.
I chopped just one tree. I am doing no harm.
I´m being quite useful. This thing is a Thneed.
A Thneed´s a Fine-Something-That-All-People-Need!
It´s a shirt. It´s a sock. It´s a glove. It´s a hat.
But it has other uses. Yes, far beyond that.
You can use it for carpets. For pillows! For sheets!
Or curtains! Or covers for bicycle seats!
The Lorax said,
Sir! You are crazy with greed.
There is no one on earth
who would buy that fool Thneed!

The Once-ler is utterly convinced of his own ideas regarding the directions for the system, and is not interested in listening to the warnings of the Lorax. He thinks he knows what the users need, and how to make the system fill that need. Or perhaps he is using the wrong design patterns, or too many different patterns, or some classic anti-patterns.

And, in no time at all,
in the factory I built,
the whole Once-ler Family
was working full tilt.
We were all knitting Thneeds
just as busy as bees,
to the sound of the chopping
of Truffula Trees.

Then...
Oh! Baby! Oh!
How my business did grow!
Now, chopping one tree
at a time
was too slow.

So I quickly invented my Super-Axe-Hacker
which whacked off four Truffula Trees at one smacker.
We were making Thneeds
four times as fast as before!
And that Lorax?... He didn´t show up any more.

Now the Once-ler is scaling up the project, using all of his old buddies. Now four times more staffing than before. Not only that, but with such confidence in his vision that he doesn't miss the fact that the crucial architectural knowledge of the Lorax is no longer guiding the project.

But the next week he knocked on my new office door.
He snapped, I´m the Lorax who speaks for the trees
which you seem to be chopping as fast as you please.
But I´m also in charge of the Brown Bar-ba-loots
who played in the shade in their Bar-ba-loot suits
and happily lived, eating Truffula Fruits.
NOW...thanks to your hacking my trees to the ground,
there´s not enough Truffula Fruit to go ´round.
And my poor Bar-ba-loots are all getting the crummies
because they have gas, and no food, in their tummies!

They loved living here. But I can´t let them stay.
They´ll have to find food. And I hope that they may.
Good luck, boys, he cried. And he sent them away.

I, the Once-ler, felt sad as I watched them all go.
BUT... business is business! And business must grow
regardless of crummies in tummies, you know.

The Once-ler is willing to do anything at all to the code base, including losing the architectural consistency of the system, in order to implement his new vision for the project. Or lose anyone at all on the project team, for that matter, to maintain control over the project. Too bad Once-ler doesn't realize that once the tipping point of architectural instability is reached, a system can become unreliable and unmaintainable very quickly.

And then I got mad. I got terribly mad.
I yelled at the Lorax, Now listen here, Dad!
All you do is yap-yap and say, Bad! Bad! Bad! Bad!
Well, I have my rights, sir, and I´m telling you
I intend to go on doing just what I do!
And, for your information, you Lorax, I´m figgering on biggering
and BIGGERING and BIGGERING and BIGGERING,
turning MORE Truffula Trees into Thneeds
which everyone, EVERYONE, EVERYONE needs!

And at that very moment, we heard a loud whack!
From outside in the fields came a sickening smack
of an axe on a tree. Then we heard the tree fall.
The very last Truffula Tree of them all!

Did you see THAT coming? Of course you did! Once the technical debt of the system exceeded the available resources, the application went bankrupt.

No more trees. No more Thneeds. No more work to be done.
So, in no time, my uncles and aunts, every one,
all waved me good-bye. They jumped into my cars
and drove away under the smoke-smuggered stars.

Now all that was left ´neath the bad-smelling sky
was my big empty factory... the Lorax... and I.

Once the project's future prospects are bleak, project funding or company revenues dry up. As a result, key resources leave. When this vicious cycle begins, there may be no stopping it.

The Lorax said nothing. Just gave me a glance...
just gave me a very sad, sad backward glance...
as he lifted himself by the seat of his pants.
And I´ll never forget the grim look on his face
when he heisted himself and took leave of this place,
through a hole in the smog, without leaving a trace.

And all that the Lorax left here in this mess
was a small pile of rocks, with one word...
UNLESS.

If you are an architect or dev lead, you are probably sympathizing with the Lorax as you sometimes feel like you are "defending" your system. If you are a hiring manager or recruiter reading this blog, perhaps at this point in the story you are getting a idea about why it is hard to recruit and retain the best system architects and developers to work on toxic projects.

But now, says the Once-ler,
Now that you´re here, the word of the Lorax seems perfectly clear.
UNLESS someone like you cares a whole awful lot,
nothing is going to get better. It´s not. SO...
Catch! calls the Once-ler. He lets something fall.
It´s a Truffula Seed. It´s the last one of all!
You´re in charge of the last of the Truffula Seeds.
And Truffula Trees are what everyone needs.
Plant a new Truffula. Treat it with care.
Give it clean water. And feed it fresh air.
Grow a forest. Protect it from axes that hack.
Then the Lorax and all of his friends may come back.

System architects, let a thousand flowers bloom. Fight for your systems.

RIP, Dr. Seuss. We miss your wisdom.

Iteration At Jet Speed

Jeff Atwood's blog has some excellent points about agile software development, based on a cool article by Roger Sessions from MSDN.

Sessions notes the concept of the iconoclastic Col. John Boyd that speed of iteration beats quality of iteration.

Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.

Jeff Atwood riffs further on this idea:

You'll find this same theme echoed throughout every discipline of modern software engineering:

• Unit tests should be small and fast, so you can run them with every build.


• Usability tests work best if you make small changes every two weeks and quickly discard what isn't working.


• Most agile approaches recommend iterations no longer than 4 weeks.


• Software testing is about failing early and often.


• Functional specifications are best when they're concise and evolving.

When in doubt, iterate faster.

Time For A Little Story

Brian Marick has a great example of how to break a software feature up into user stories.

Note how looking at smaller units of granularity make it so much easier to understand, then just trying to identify an entire feature all at once.

Also note how much value even the simplest pictures add to the stories. However, a picture is not enough. I personally love to see video of the whiteboard conversations for documenting the user stories.

People are communicating beings

I ran into this older article from Alistair Cockburn the other day called Characterizing people as non-linear, first-order components in software development.

What Dr. Cockburn is talking about, is that very agile of ideas that people are the central focus for any software development effort. Developing software is not just a sausage factory of requirement documents, source code documents, and unit test plan documents. The people are what is important, not the documents.

Deep within it is a fantastic section called "People are communicating beings". In it, Dr. Cockburn says that "The most significant single factor is 'communication'", and presents an informal chart of the efficiency of communication that he uses to "inform my methodological considerations":

This chart shows that real-time, face to face communications is the most efficient. Conversely, written documents are the least efficient format.

The article goes on to say:

If this model is useful, it should inform us as to how better to work. Indeed it does, and we find the busiest projects making use of those suggestions.

'Put all the people into one room.' 'Don't give me more than 4 people, that's all I can get into one room and talking together.' These are standard recommendations of successful project leaders. They plan on using the highest communication mode, people face-to-face...'Make sure there are whiteboards and coffee corners all over the building.' Hewlett-Packard and IBM were early to observe the effectiveness of informal meeting places, and by now it has become a standard idiom in our industry that an effective design environment actively encourage and permit ad hoc meetings of small groups. Weinberg documented specific instances where casual conversations had significant effect on the overall group output [Wei]. Much progress comes when people 'just talk together.'.

A colleague of mine argued on behalf of written documents, and in his case, he took a very conventional view and insisted that the documents were the most important thing to "provide a record of what happened". Dr. Cockburn does not dismiss the need, and addresses this in an excellent manner:

The above model also allows us to make a recommendation for archival documentation:

Have the designer give a short (5-20 minute) description of the design to one or two colleagues who are not familiar with the work. They will act as ombudsmen for the viewers of the videotape. Let the people simply have a discussion of the design, with the colleagues asking questions as they need. Video the discussion. At the end, produce drawings of the examples used in the discussion, or the design drawings used, to act as mnemonic anchors of the discussion.

I was pleased to hear from Lizette Velasquez of Lucent Technologies that not only had she profitably already used that technique, but that I had forgotten to mention something important. She said it is also important to mark and index places where 'something interesting happened'. While much of the discussion proceeds at a relatively slow pace, occasionally a question triggers a flurry of significant discussion, and the viewers will want to refer back to those sections.

These days, it is possible to put the talk online with hyperlinked media.

For those who still think a book is best, consider the excellent but difficult book Design Patterns. Imagine that instead of trying to extract the meaning of the 'Decorator' pattern from the paper, you could click on the page and see one of the authors explaining the pattern in a video clip. They would, of course, rely on tonal inflections, gestures, and timing to get the idea across.

The lesson of this human characteristic is that we should try to move team communications up the curve as far as possible, given the situation at hand.

As I said, Dr. Cockburn does not dismiss the need for archival documentation, he just puts it in its place. Thank you, Doctor! I'm just glad I have some of your wisdom on video.

The Folly of Accountabalism

The Harvard Business Review has published their list of 20 breakthrough ideas for 2007. There are several ideas on this list with particular appeal to me. One that stands out is David Weinberger's "Folly of Accountabalism" which insists that "Accountability has gone horribly wrong. It has become 'accountabalism,' the practice of eating sacrificial victims in an attempt to magically ward off evil."

Dr. Weinberger is referring to the emphasis on corporate management and compliance that has come to dominate modern American business. Software development within corporate IT departments are just as bound by this kind of thinking as marketing or sales is. Weinberger argues that this manifests itself as several common practices.

"Deciding that the problem can be solved at the next level of detail - looking at complex systems that have gone wrong for complex reasons and writing another set of work procedures, and printing up more forms." A common approach with software development organizations is to try to become too abstract, creating a solution to every possible problem in advance.

"Assuming perfection - if anything goes wrong, it’s a sign that the system is broken." This does not allow for the "good enough" solutions that allows for the mismatches between what we can do, and what we can do now.

"Being blind to human nature - by overly formalizing processes, accountabalism refuses to acknowledge that people work and think differently. It eliminates the human variations that move institutions forward and provide a check on the monoculture that accounts for most disastrous decisions. It also makes work no fun." Need I say more!

"Bureaucratizing and atomizing responsibility - While claiming to increase individual responsibility, it drives out human judgment. When a sign-off is required for every step in the work flow, those closest to a process lack the leeway to optimize or rectify it." I was just following orders...we know where that road leads.

No wonder so many organizations try to force all of their software development processes into a waterfall! It just fits perfectly within the practices that have already fallen into due to this overemphasis on idealized management, however wrong minded it may be.

Speaking The Same Language

The art of successful software development is matching the delivered software to the needs of the users. Achieving this requires that the developers and the users speak the same language regarding the problem to be solved. James Shore has a new chapter called Ubiquitous Language in his upcoming agile development book that summarizes this idea nicely.
Martin Fowler's seminal article on Language Workbenches also has really influenced my thinking. I guess the difference to me is that where Ubiquitous Language is about getting the developers to understand what the users are talking about, Language Workbenches are about building software systems using tools to translate the domain specific language into runnable code.
The foundations of these ideas have to do with human communication as much or more than they have to do with technology. For decades, good consultants have been taught "learn to speak the customer's language". The movement behind domain specific languages is just a formalization of something that has been going on for a long time. I'm pretty sure that Peter Drucker was doing something like this back in 1954 or so...just not using computers.

The Dark Side Of Metrics

I have usually been in favor of measurement of any possible aspect of the software development process. Proper techniques of gathering and analyzing metrics have been espoused since Capers Jones created the study of software measurement. I was first introduced to many of these concepts in the writings of Steve McConnell, particularly when his book Rapid Development first came out. If a thing cannot be measured, it cannot be easily studied or improved.
But any tool, no matter how well intentioned its purpose, can be used for ill. Any system that relies entirely on user entered information can by lied to. Such systems can be gamed, for various purposes. In a very political environment, a rogue group can manipulate their own metrics to gain power over other groups, gain budget, or simply steer the company in the direction of their own egos. Sometimes metrics can be used to hide something important. "But look at our metrics," protests the manager in charge of a spectacular failure.

Even worse, once this starts to happen, the "everybody's doing it" syndrome strikes, and it can spread like a disease. Pity the poor foolish team that actually tries to tell the truth within such a system once this dynamic sets in. They will be punished, sometimes severely, for "not measuring up to the standards of the company".

The best sorts of metrics are collected automatically. All sorts of interesting information can be learned from analysis of the source code repository. Other information can be assessed from other dynamic sources such as number of unit tests passed, or Fitnesse tests, or measuring Running Tested Features. The important thing is that it is a lot more reliable to use metrics that are not so easily fooled by people with various agendas.

The Planning Game Vs. The Crying Game

James Shore just posted a very cool chapterette from his upcoming book on agile development called "The Planning Game". The concept simply enough is that customers and developers work together to plan what features are going to be implemented, and in what order. Customers know what features have the most value to the business, so they get to choose the order in which features are developed. Developers know about the costs, so they get to say how long something is going to take.
In the Planning Game, the play is not quite so simple as the description above might suggest. As each team discusses a feature from their perspective (cost vs. value), the requirements for that feature can come into clearer focus, or be negotiated to reduce their cost.
More often, what I have experienced is the "Crying Game": whoever cries the loudest gets their way. The outcome of the Crying Game is not a good one. Either arbitrary and unrealistic deadlines are set by customers, or the wrong solution is provided by the developers. The crying doesn't end there; everyone is crying later as the recriminations fly back and forth. The moral of the story is that internal cooperation yields a lot more business value than internal competition.

Toward A Test-Driven Culture

We all have to move to a test-driven culture. We cannot think about testing as an afterthought, or as a necessary evil. Testing has to be baked into the culture of software development the same way that testing is baked into Ruby on Rails. It is there right from the beginning, and makes you feel guilty when you DON'T do it. The DNA of software development has to evolve to grow systems with neurons that make it so that a lack of testing feels like sticking your hand into a wall socket; you notice right away when it happens, and you take immediate action to make it stop.

Software testers are considered "lower on the food chain" then software developers or analysts. That means testers are compensated less than their developer or analyst counterparts. Even on many important projects, across both companies and industries, this is still the case. This amazes me, given how much of the world runs on software. If the software that runs your airplane's landing gear, or your electronic voting system, or whatever other ultra-critical system has not been sufficiently tested, lives can be at stake. Despite the fantastic work being done in the area of software quality, and the proliferation of practices that can dramatically reduce the cost of creating and maintaining a system, we still all too often see quality getting shortchanged on required resources.

So testing is good, and we need more of it, surely. But we need to go further, much further. Giving proper attention to test-driven development is great. But even all this is not enough. What we need to do is to apply a test-driven mentality to all aspects of business. Marketers have found that testing and measuring their marketing yields a far greater ROI then marketing based on opinion or theory. Salespeople have been measured by quotas, and the most successful sales organization performing testing for some time.

In particular, we need to move toward management philosophies that apply testing to business decisions, in particular those about processes. All too often, decisions have consequences often than those intended, perhaps failing in one of more objectives. A new process designed to streamline a company, can actually result in adding more burden with less efficiency.

Without the ability to test, management will eventually lose control over itself. With no feedback, failures may be looked at as successes, and vice versa. Management cannot be arbitrary; by carefully adopting a test-driven culture across all disciplines within an organization we can improve both the quality of our work, as well as the quality of the experience we have while doing that work.

Architect Is Not An Honorary Title

The job title "architect" seems to mean something different inside every organization. At far too many companies, it is almost an honorary title, being reserved as a promotion for long-term company loyalists who "know the business", instead of actually meaning anything related to the overarching technical design required for the successful release of quality software.

Knowing the business is great. In fact, knowing the business is essential. I hope that business experts abound within your organization. But "architecting" is not what these people are doing.

Here is a list of some of the knowledge, skills, or qualities that I think are required for anyone who wants to be called "architect". In no particular order:

- Speaks in terms of design patterns
- Uses open source/commercial off the shelf(COTS) software
- Can determine the least cost solution for a particular business need
- Desire for a career path in technology which is NOT management
- Knowledge of both current and next-generation technologies, so that development efforts can be synched up with other developers in the industry
- Knows how to avoid or get out of anti-patterns
- Embraces simplicity as a fundamental design principle
- Can embrace the good ideas of others
- Unafraid of change

Do you know who the architects are in your organization? Are these the qualities that they are known for?

Programming Zombies Will Crush You

This post on the "Creating Passionate Users" blog really sums up what makes a Dead Programmer, well....dead!

http://headrush.typepad.com/creating_passionate_users/2006/10/knocking_the_ex.html

A colleague of mine once quipped, "Why is it that at some point in most people's career, they suddenly decide that they now know everything and don't have anything else to learn?". That is around the point that they are past the point of no return converging on the "micro-manage every detail" side of the "Zombie Function" graph.

So what happens to these poor middle managers? Is it the tribal "showing the size of one's beak"? Or is it a kind of post traumatic stress disorder, brought on by being way into the "anxiety zone" (I will post about the state of flow soon).

Odd that the very factors like creativity and free-thinking that can most stimulate success, are the ones most likely to be blocked by management at many companies.

So what can a poor, Dead Programmer do about it? Speaking truth to power is both difficult and dangerous. If you really think you are ready to take on a monoculture within your organization, you had better prepare. Once you finally get your chance to pitch them, you will only get one chance. Writing down your ideas well in advance of this can refine them down to the size of information packet that management will be able to digest.

Focusing on new solutions instead of dwelling on the mistakes of the past is also a good idea. This is particularly true when speaking to the individuals who got the company into whatever mess it is in, in the first place. Be very diplomatic, but still take a firm stand ("tough love"?), and keep it far, far away from anything that can be taken personally.

Lastly, keep in mind that only benefits that will really impact the business are important enough to risk the firestorm that sometimes arises when confronting a zombie organization. When I say impact the business, I mean either bring in major new sources of revenue, or dramatically reduce the cost per running tested feature.

Small incremental improvements to the organization are best implemented from the bottom up in a "stealth mode" project. More about that next time...

Too Skilled For Programming?

This classic bit of wisdom from David Dossot explains many things about management philosophy that frequently make little sense to developers. If you ever wondered how some people ended up in management, the answer is here:

http://perso.wanadoo.fr/lothar/datastore/TooSkilledForProgramming.pdf

In a world where taller people tend to more successful, I guess it makes sense. But logic has nothing to do with it! And things that lack logic offend the sensibilities of any self-respecting Dead Programmer...