Programmer conditioning

I do not have a Computer Science degree, so I cannot speak from direct experience about the "traditional" training most programmers get. That said, I've worked with many programmers and business people on multiple software development projects. As a result, I think I can speak intelligently about how those people tend to think and act when they're trying to create software. Let me talk about programmers first, since I am one.

Get with the program

My father is a physician. He has told me, more times than I can count, "You go to medical school and when you graduate, you do your residency to learn to be a doctor." It is similar for most Computer Science graduates, I think. They come out of college knowing lots of theory (some of it good and helpful) but not very much about how to write good code. Since I don't have a CS degree, I missed most of that theory. Sometimes that hurts me, but most of the time it doesn't.

When I started programming, I was 22 and right out of school. Andersen Consulting trained me, mentors showed me the ropes, and I muddled through. This is how it goes for most people: they learn to program on the job, most often in some flavor of corporate environment. Unfortunately, so did their mentors and teachers. Habits, idioms, and biases, most of which aren't very good, get passed from one generation to the next . In the end, most programmers learn to get the job done, probably as fast as possible.

Four programmer behavioural patterns seem pretty consistent:

• Programmers don't know how to talk to business decision-makers very well.
• Programmers expect textbook problems.
• Programmers like to work alone.
• Programmers think testing is a post-coding activity.

Back to top

Business conditioning

Business people have their own training, but it varies a great deal more than what is taught to programmers. The results are similar, though: business people are conditioned to behave in ways that jeopardize their software projects.

The cost of doing business

Business people in charge of budgets can calculate all day, but it seems they don't know how to think about why they need software. Often they have no real concept of business priority of features or of the monetary value (direct or indirect) of those features to their business. This is understandable, for both lower-level managers of projects and company leaders.

In lots of corporate environments, especially large ones, it's easy to see how people at the bottom can think people at the top rule by edict. Some order comes down from on high and people at the bottom are just expected to execute it. People in charge of managing projects are subject to constraints that keep them somewhat in the dark. They often aren't empowered to think. So, when an order is given, they simply obey and leave the details of why they should or should not do something to those higher up the food chain.

But the supposedly all-wise people at the top often aren't in any better shape. Many business decisions end up being based on what's "hot" or gets the most press. "If all these other companies are doing it, we should, too." It's called the "bandwagon effect." The problem is that business leaders are thinking about software incorrectly. They see it as a cost instead of an asset that costs something. They see it as a necessary evil, or as a means of production, rather than as a strategic advantage.

I don't want to get involved

Saying business people are "involved" with software projects tends to be an exaggeration. They usually aren't very involved at all. Software developers might ask them questions occasionally, but the process is really broken. A project usually begins with analysis design, even if the development team isn't using a waterfall variant. This is when business people get talked to the most. But the technical team usually expects the business people to be omniscient. "Tell me right now what the software needs to do in a year. We'll tell you that you can change your mind later, but we're just kidding. Whatever decision you make now is set in stone."

No wonder business people are nervous. They're forced to make definitive statements about things they don't know. This puts them almost inevitably in some kind of Darwinian struggle with IT, where business people throw stuff over the wall and expect the developers to figure it out. Not a recipe for coordinated creative activity, is it?

Corporate tug-of-war

Conflicting constraints are intense. As a project manager, your boss is getting dumped on by those above, and he passes it along. You have to make everyone happy, including the folks from other departments your system has to interface with, either upstream or downstream. You're bound to step on somebody's toes somewhere and make someone unhappy.

Back to top

Breaking the pattern

Most companies are "locked in" to this kind of behavior, which has built up over time. The result is software projects that run over people and often don't satisfy anyone when the projects are done.

Is it hopeless? Are you stuck forever? Well, yes, if you don't start behaving differently. I'm not an expert on the thought process; I can only speak from experience. Sometimes I believe you should first try to think differently, then that will influence your behavior. Most of the time, though, that doesn't work for me. I have to behave differently first. My thinking comes around later. The best approach for me is to behave differently with the intention of changing the way I think. This is where XP can help.

XP requires behavior that rails against typical conditioning. The only way to see the best possible results from it and judge whether it's right for you and for your organization is to use as many of the practices as you can (preferably all of them) for a period of time. Invest yourself and your team fully in exploring their effectiveness, and breed healthier habits within the people who create software in your company.

The XP practices can help change people's minds, but only if those people start using the practices. This takes a leap of faith, or at least suspended judgment. XP isn't "normal," so it can feel awkward when you start. Maybe it'll never feel right for you. Maybe it'll never be right for your company, but you won't know for sure without giving it a try. An experiment is in order. Try XP for a couple weeks, during which you commit to two things:

1. Don't give up, even if you feel odd or hostile.
2. Make a conscious effort to think differently about what you're doing.

The first commitment is pretty self explanatory. The second one needs some clarification. XP practices for programmers (such as pair programming) and for business people (such as story telling) require a different way of thinking to work well. You can't just start thinking differently, but you can pretend.

The great pretender

When you encounter a practice that you're unfamiliar with, you need to pretend in two ways:

1. Pretend you like the task -- pretend you really like it.
2. Pretend you think differently in the way the practice expects you to.

Of course, if you do like the practice already, you won't have to pretend. But if you don't like it, you must hunker down and act like you do. Do the practice all the time. Act like you simply can't code without it. If you absolutely hate the practice (and most programmers either love or hate the "controversial" practices, like pair programming), vent if you must, but get over it. Suspend disbelief and do it anyway. This is an act of will. Just because your bias or your tendency or your experience tells you to sulk and stonewall, you don't have to react that way.

Now, what's this business about pretending to think differently? Exactly what it says. Ron Jeffries covered this in an article and he didn't even know it. He talked about the YAGNI ("You Aren't Gonna Need It") practice being a reminder that we need to think differently:

As technologists, most of us revel in our ability to handle complexity and love to learn the latest new thing. We need a reminder that our job is to produce simple, maintainable programs, Real Soon Now, not to build giant enterprise software to support a few Web pages.

He adds that YAGNI reminds us as programmers not to add features to software before we know we need them. Why? Because the business really ought to be driving that, because we frequently guess wrong about what we'll "need" later, and if we're doing the other practices reasonably well, we can just put something in later if we need to for no extra cost. YAGNI keeps us focused on simplicity. This is part of the new way of thinking that XP requires. Here are some other examples for programmers:

• Pair programming requires you to think two heads are better than one. No fair secretly thinking the other guy's an idiot. Does he have a knowledge gap? Fill it and stop privately cutting him down. You never know -- the "idiot" might see something you missed, or have a great idea.
  
  
• Test-first development requires you to think beyond the end of your nose. Sure you can whip out a class without a test. The code's simple. But what happens when you have 100 classes and a bug crops up? Having tests will isolate it extremely fast. Not having tests could sentence you to hours of debugging. Writing tests first also requires you to accept an uncomfortable fact about yourself: you're not perfect or omniscient.
  
  
• The story-telling practice requires you to believe your customer should drive the software, and I mean really drive it. You can't make something up, no matter how cool that hypothetical feature might be.

And here are a couple examples for business people:

• Story telling requires you to believe you can and should be driving the software. You have to think, "This is my software. I had better tell somebody what it's supposed to do."
  
  
• Frequent releases require you to think that good is better than perfect, and that feedback from real users is the best way to "steer" the project toward the software you want at the end. You have to think it's good to release something to real people before it's done, while some parts might still look ugly.
  
  
• Customer testing requires you to believe it's worth the obvious extra effort it takes for you to write these tests. Yes, it will take time. Do you want a successful project? Then tell your developers when they're "done" with a feature by giving them a test that proves they made you happy. Don't hide behind plausible deniability.

Here's an example of what all this pretending might look like. If you're a programmer, let the customer drive, even if it worries you. Don't write a stitch of code until you have a customer "story telling" you what to do and an acceptance test telling you when you're done. When you disagree with the wisdom of what a customer is asking for, simply ask a question to make the customer think about what he's doing. Don't spout off at the mouth about how the story is dumb. Hold every other developer on your team to that bargain. If you're a customer, resist the urge to give vague definitions and expect the programmers to figure them out. Try to write the best story you can, knowing that you can demand the right to change your mind later on. Then, intentionally change your mind on something -- it doesn't matter what. If you're a programmer, close the loop by reacting well when your customer changes his mind -- pretend you expected it.

This pretending will start to build habits. These habits will change your thinking. They will start to feel natural.

Back to top

Focusing on value

The last thing to do will seem the most insane of all. You business people on the team need to try your best to quantify -- in dollars -- the business value of each feature (or more likely each set of features) you ask for. This is the business case for the software, and it's probably worth another article in this column (I'll let reader opinion drive that, so give me your input). For now, let me talk briefly about what I mean. You should try to answer two questions for each feature of the software your team is making:

1. What need for value will this feature address (that is, which of your customer's costs will it reduce or which revenues will it increase)?
   
   
2. By how much will it do that?

I'll be the first to admit that answering these questions isn't always possible. When it's not, don't sweat it, but don't assume it's not until you try. It is important for you as a requester of features to understand why you're asking for them. Somebody's paying for this software. They should know what they're getting for their money.

Back to top

Mindbenders

Developing software with XP requires you to change your mind generally, but there are a few points where the new mindset is particularly weird. Watch out for these:

• The customer needs to drive all the time, not just when the developers let him. Developers need to see customers as part of the team. Customers need to see themselves as part of the team.
  
  
• The customer should be driven by business need, not arbitrary pressure from above.
  
  
• Customers have to translate business need into feature stories that are very specific. Otherwise, programmers won't know what to code.
  
  
• Customers, perhaps with help from others, have to specify acceptance tests that tell developers when they're done with each story.
  
  
• Developers can't add features without a customer story-telling them to do so.
  
  
• Developers must write programmer tests all the time.

These things are radically different. They require discipline. That discipline will, in most cases, be rewarded with increased project success. Stick to your guns. In future articles, I'll include concrete suggestions on how to change your thought patterns.

Back to top

Change must affect the top

The second bullet in the previous section probably chokes you up a bit. "The customer should be driven by business need, not arbitrary pressure from above." I can hear what you're saying, "Come now, Roy. Surely you aren't that naive. There will always be pressure from above. It rolls downhill." You're right, but the response to this has to change.

Remember the programmer practices? When a customer asks for twice as much as will fit in an iteration, and he wants it yesterday, what do the programmers say? They say no, or perhaps yes with modifications. They don't just agree to start working 100 hours a week. Business people need to start doing the same. This has to ripple up all the way to the top of the organization. Everyone needs to start behaving this way. Anything else is unrealistic.

I'd like to say that change starts at the top, but often it doesn't. Sometimes change has to come from below. The way it starts is for people to stop lying to people above them in order to relieve short-term pressure. Otherwise, you're storing up wrath for yourself when you don't deliver. Tell the truth: "No, we can't get that done. We can get this done, we think, so that's what we'll do." It's possible that the bigger fish will then show you the door. I hope that doesn't happen. But as Martin Fowler said, "If you can't change your organization, change your organization." Find a realistic place somewhere else. The only reason things don't change is that we refuse to make it so.

Back to top

Next month

The customer role is where XP is most effective and it's something foreign to most IT organizations. It's way too informal, and way too empowered, for most people to feel comfortable. But it's vital to making an XP project successful. An XP project without a customer is doomed to stray far from what users end up wanting at the end of the project. Next month, I'll talk about what needs to be different psychologically and organizationally for XP teams to have customers.

Resources

• Participate in the discussion forum.
  
  
• Read all of the articles in the Demystifying Extreme Programming series.
  
  
• Read the original "XP distilled" (developerWorks, March 2001).
  
  
• Check out "Misconceptions about XP" by Ron Jeffries for some of his thoughts on XP thinking.
  
  
• Another good article by Ron about the benefit of pretending: "Pretend You're Not Afraid."
  
  
• Find hundreds of other Java technology-related resources at the developerWorks Java technology zone.
  
  

• Extreme Programming Explored by William Wake (Addison-Wesley, 2001)
  
  
• Extreme Programming Applied: Playing to Win by Ken Auer and Roy Miller (Addison-Wesley, 2001)
  
  
• Planning Extreme Programming by Kent Beck and Martin Fowler (Addison-Wesley, 2000)
  
  
• Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 1999)
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Programmer conditioning
• Business conditioning
• Breaking the pattern
• Focusing on value
• Mindbenders
• Change must affect the top
• Next month
• Resources
• About the author
• Comments