It might be you.
Process is a lie. All of it.
If you’re spitting and fuming because you believe in software development processes, bear with me. I have a point to make, and you’ll enjoy it.
If you’ve never believed in software development processes and you’re cheering me on, take a seat and a deep breath. I have a point to make, and you’re not gonna like it. But you need to hear it.
Process is a Lie?
Process is a lie, because process is a plan for how we’ll work. And plans are lies. All of them.
A plan says, “This is what will happen, and this is what we’ll do.” A more realistic plan says, “This is what will happen, and this is what we’ll do. These are things that could happen instead, and this is how we’ll handle them.” And a truly realistic plan says, “This is what will happen, and this is what we’ll do. These are things that could happen instead, and this is how we’ll handle them. And in case something happens that we haven’t foreseen, these are the resources we keep in reserve and the options we keep open.”
And even truly realistic plans fail. Nineteenth century German Field Marshall Helmuth Graf von Moltke told us: “No battle plan survives contact with the enemy.”
Some developers and teams are process averse. And one common reason is that they’ve experienced plenty of process failures.
And yet Field Marshall von Moltke made plenty of battle plans. He wasn’t saying “Plans are bad.” He was saying “Plans are never enough. But they’re still essential.”
Process is never enough. But it’s still essential. Process failure might indicate a flaw in that particular process; but often, it indicates that no process survives contact with the enemy.
Now the enemy in this case is not the customer (at least, not if your customer relations are healthy). The problem itself is the enemy, and your team is the invading army, trying to find its weak points, pick it apart, and conquer it. And the problem fights back! It hides minor details until they become critical. It changes due to unforeseen circumstances. It’s a lot bigger than it looks. And sometimes it draws a lot of its problem friends into the battle when you least expect them.
Your process is your battle plan; and it is wrong, in ways you can’t foresee until they happen. But that doesn’t make it wrong.
Wrong, but Not Wrong?
OK, now Martin’s getting confusing: it’s wrong, but it’s not wrong. What gives? Well, a plan can be (will be) wrong in details and yet still be right overall. Like all plans, your process is what you expect to do, not what you actually end up doing. A process or plan establishes a basic framework for how you’ll handle the simple, mundane matters that arise; but realism tells us that things are going to happen that aren’t covered by the plan. The process guides you in handling what you can foresee, so that you can spare more attention and thought for the eventualities you can’t foresee.
The plan or process lets you handle simple stuff without thinking, so you have more thought to devote to the hard stuff.
So a well-designed process is good, as far as it goes; but you have to be ready to step outside it or beyond it when the need arises. And a really good process includes a process for changing or sidestepping the process. The U.S. Constitution includes an amendment process for this reason.
One of the most common sources of process disillusionment is the ISO-9000 family of standards for quality management systems. Many an organization has implemented failed ISO-9000 initiatives; and while I won’t name names to protect the not-quite-innocent, more than one organization has implemented “pretend” ISO-9000 initiatives to attain certification, but never really follow their own standards.
And yet ISO-9000 is, at its core, a good process for designing processes. It really amounts to this:
- Document what your process is.
- Document how you gather data and measure it.
- Document how you correct it when it fails.
- Document how you change it when needed.
- Document how you handle exceptions when needed.
- Document how you’ll train people in the process.
- Document that you’re following the process, including data.
- Document that you’re correcting when needed.
- Document the exceptions when they happen.
- Document training results.
- Document changes to your process.
Forgive me if I’m being dense, but what could be wrong with any of those items?
No, when ISO-9000 fails, it’s almost never because of ISO-9000 itself. Rather, it’s because your process stinks; and when you’re process stinks, either your team abandons it, or they blindly follow it. In some cases, the stinky process comes from outside “experts” or consultants who don’t know how your team actually works. Often it’s a “canned” process that the team is “shoehorned” into, with disastrous results.
What’s missing, then, is an often-overlooked step 0: Decide what your process really is. Don’t let some outsider tell your team their process; ask your team what their process is. Ask them questions and get them thinking about it. And then document it, document your data, etc., etc., etc.
Yes, it’s possible that your team needs to learn and adopt better processes. Absolutely. But the wrong process can be worse than no process at all. If your team isn’t ready or able to be circus horses, then a circus horse process will fail. You can cajole and fume and order and threaten all you want, and it won’t change anything: some teams aren’t ready or suited for some levels of formality. Or informality: some people adapt well to more formal processes, and find informal processes to be chaotic time-wasters. They’re proud circus horses, not smelly, dirty cattle.
CAFÉ, or CAFÉ? Your Choice…
So yes, you need a development process, whether you think you do or not. In fact, if you don’t think you have a process, you’re probably following the most common development process, CAFÉ:
Figure 5: CAFÉ – Code And Fix, Endlessly
And if you’re really lucky, sometimes you hit the end of that process. Maybe. If you define “Bugs” in a very forgiving fashion.
The trick is finding the right process, one that fits well how you’re already working. Then try to describe that process so that you and your team can reach a common process. Then document that process. Then apply that process, and see where it falls short, and make it better over time.
Most popular software development processes today are incremental, building small chunks of functionality and then adding more over time. Why? Because that way you never get too far down a wrong path. You get quick feedback on what you’re doing right and wrong. And then you fix the code that’s wrong. (In fact, these incremental processes are all, at their core, more structured descendants of CAFÉ.)
Well, developing your development process should also be incremental. Don’t try to change everything overnight. Do try to change. Then look at what worked, and do more of it. Look at what didn’t work, and fix it. Repeat, repeat, repeat. When it comes to your process, you want the other CAFÉ: Change And Fix, Endlessly.
Short Cut (n): Something that will take longer and cost more, but might gain some immediate goal. (Odds of gaining that immediate goal average around 7.3%.)
Example: “Yeah, we know we needed to test that, but it would take all week. We need to ship today, so we’re going to take this short cut instead: we’ll test after we ship.”
Commentary: Really, if the short cut were a good idea, why didn’t you plan to do it that way in the first place? As Professor Tolkien wrote, “Short cuts make long delays.” Or as I keep telling people: Short cuts take longer and cost more, every single time.
Show Stopper (n): The largest bug that isn’t fixed yet.
Example: “Last week, the show stopper was that the brakes cut out. This week, the show stopper is that the buttons are cyan instead of teal.”
What would you get if you married Ambrose Bierce’s Devil’s Dictionary…
A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic’s eyes to improve his vision.
…with the engineering adage Murphy’s Law…
If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.
Murphy’s Dictionary: an ongoing series of definitions of what words really mean on a typical development project.
So you’re a coding ace. You know the latest languages. You use the latest tools. You even write your own tools, so your development environment practically reads your mind. You eat, sleep, and breathe code.
So why do you keep missing your deadlines? Code is not enough.
You love to code. You can hardly believe that people pay you to “work” at a hobby you often do for no pay at all. You’re never without a few personal projects under development.
So why do you feel so stressed at work? Code is not enough.
Code may be the fun part of programming, but it’s only a small part of the development process. It’s not enough to see you through a tough project. It’s not enough to help you develop business and meet requirements. It’s not enough to make your project a success.
Code is not enough. And in these essays, I’ll discuss the rest of the development process.
In our last episode, The Reader and The UML Guy refactored the simple Pizza Order Class into a more complex but more robust Class Diagram that supports a full range of pizza order options.
(Click picture for a larger image.)
No new references in this strip. Too much material to cover. But we see the return of some old friends.
Inheritance in UML is called “Generalization”: Menu Item is a general Class, and Pizza, Item, Drink, and Side are more specific Classes. But in most common languages, it’s just called “Inheritance”. When I say “Generalization” in my UML classes, people look at me funny. Don’t blame me, I didn’t make up the names.
For a discussion of why type codes are for losers, I recommend (again) Fowler’s Refactoring.
For an introduction to Patterns, I recommend Design Patterns: Elements of Reusable Object-Oriented Software…
…and also Head First Design Patterns.
Fowler’s Party Pattern and a host of other really powerful Patterns are found in one of the most indispensable books on my shelf.
With Design Patterns — as powerful as they are — there’s a trick: you kinda have to know you need a particular Pattern to know whether you need that particular Pattern. They’re low-level design concepts. Analysis Patterns are higher level, and you can usually recognize when you need them simply by looking at the customer’s business problems.
In our last episode, The Reader and The UML Guy drove through time and space in The Search for Class Diagrams. Along the way, they held a long discussion on the philosophy of modeling. But The Reader was surprised when they reached their destination: they were back at the Lounge!
(Click picture to see larger image.)
If you haven’t seen the film, parts of this strip will make no sense at all. I like some oddball films. Get used to it…
Oh, and because Editor Bill and Ernie Out in the Barn demanded it, Receptionist got contacts, and a makeover.
In our last episode, Pestbuster pursued Pest right through the strip, leaving a mess in his wake. The UML Guy told The Reader they would need Class Diagrams to help in the clean-up, and said they wouldn’t find any without a road trip.
(Click the image for a larger view.)
Yeah, I know… A lot of blah, blah, blah, yackity-smackity… But these were things that needed to be discussed. A road trip is always good for a long discussion.
Here’s the key to today’s references…
The car is a 1973 AMC Gremlin X, to be precise. Just in case you had trouble recognizing it.
Actually, this book has one comic. But it clearly needs more.
The premier for this film was the second-biggest event in my life that week. (Somehow that whole wedding/honeymoon business won first place…)
Do I really need to explain this reference?
Yes, I’m shameless.
Take your stinking paws off me, you damned dirty ape!
BDUF == Big Design Up Front; a.k.a. The Boogeyman, if you’re on an Agile team.
There was no room for pictures of this great book from Scott Ambler…
Both are inspirations for the Lounge.
Until you know every word in the English language, you cant speak English, right?
The Three Amigos — Grady Booch, James Rumbaugh, and Ivar Jacobson — wrote the first draft proposals for the UML, as well as some valuable UML books. Jacobson’s point — as captured in this video — is that the “OED” UML is too much notation for most people, and confuses more than it communicates. He recommends that we identify and promulgate an “Essential UML” for most developers to learn, and leave the detailed notations to teams and projects that need them. I agree, and recommend that a good start would be to go back to UML proposal 0.8 — i.e., the work of The Three Amigos.
Sometimes, when I look at my own code, I find myself humming: If I only had a brain…
And the question must be asked: will anyone catch the Dukes of Hazzard reference?
In our last episode, The Reader and The UML Guy explored how adding collaborating Actors to a Use Case Diagram gives the audience more context and thus better understanding of the requirements. In the process, unfortunately, Pest escaped. Pestbuster has abandoned his diagram to recapture Pest.
(Click for a larger image.)
And now I’d like to address four related questions. Editor Bill asked me why, in Episode 1, I chose to use an obscure in-joke from a mostly forgotten film — and worse, a film that was mostly hated by those who do remember it. (The masses just don’t appreciate its brilliance…) And Bill, a gamer and Foglio fan, also asked for an explanation of growlf, telling me that that reference was pretty obscure, too.
So after these questions, why did I drop another reference to Bruce Willis’s underappreciated masterpiece? Even more bizarre, why did I drop a reference to an obscure 1976 film that no one outside my family has ever admitted to seeing?
Simple answer: it amuses me.
This strip is hard work for me, but it’s also fun. If it ever stops being fun, then it’ll only be work. Hard, unpaid work. If it gets to be a chore, well, I have plenty of other claims on my time. So inserting obscure jokes and references helps me to keep producing it. Think of me as the Dennis Miller of UML (though not as funny, nor as erudite).
Editor Bill gently suggested that if I let the references get too obscure, I could lose my audience. (Bill must not be a Dennis Miller fan.) And while I appreciate The Reader, each and every one of you (and hope some of you some day will have comments and maybe even questions I can answer), my answer has to be: I don’t care. Many successful bloggers will tell you the advice I first heard from Dean Esmay: if you blog, blog what interests you. Don’t try to change who you are to please an audience, because you’ll lose authenticity, and lose your audience in the process. Blog for yourself; and if you’re passionate about it, you’re more likely to find and hold an audience.
Now these strips are a little different from the usual blog. I have a not-exactly-subtle goal of teaching UML here; and I can’t achieve that goal without The Reader. If I find no one’s reading over time, well, I already know UML. As fun as they can be, the strips don’t teach me much. So I can’t completely ignore the impact of my obscure jokes on the audience. But I gotta be me. As long as it’s me drawing and writing the strip, the obscure jokes will happen. It’s not like I have control over them.
Returning to jbkazoo’s second question: where’s Samuel L. Jackson? Well, I know it’s a shock, but I haven’t seen that film. I can only reference films that amuse me, which means films I know. Roughly speaking, that means 80s films (though two of three films referenced so far are from 1976 and 1991). Without me planning it, exactly, my favorite films have become an integral part of this strip, driving it almost as much as the UML. Since the 80s were a big movie-watching decade for me, that’s where most of the films will come from; and since some of my favorite films are a little off beat, some might say these aren’t just 80s films, they’re bad 80s films.
So I guess if you need a five-word description of this strip, it’s “UML and Bad 80s Films”. And that amuses me.
UPDATE: Unknown to me, it turns out Manny Quinn is an unintentional reference. Disney was there first, as Lynn the Build Queen pointed out. (And don’t worry, Manny’s not hurt. He’ll be back.)