Rules for nothing

Why do we have standards that assume people are trying to get away with doing less work, crappy work, and that they prefer to be selfish about it? These work rules are brute-force solutions to a problem that doesn’t really exist.

One blog entry from last year, “Look. This SOPA/PIPA Thing,” started out as an offhand blurb on my Facebook status. I think I spent two whole minutes writing it, which can be pretty effective when you know exactly what you want to say:

Rather than doing their own damn work chasing down copyright violators, they want to keep everyone off sites that *might* be used for unauthorized copying.

My favorite comment came from my old Grinnell College homie, Laura Allender Ferguson, who said simply: “Go Agile.” She was responding to my side-whine about the ever-changing requirements that we always get from software development clients.

Continue reading “Rules for nothing”

That's what my game is

My idol Naomi Dunford suggested that my fans and readers might not be clear on what I do and why it might matter to them. This makes me sad, because I want to be known for more than throwing rhetorical bombs on Twitter.

Don’t get me wrong, that guy deserved the slam on Twitter, seriously, but slamming isn’t my game. It’s not my whole game anyway.

So let me go answer some of Naomi’s questions here. Go ahead and fire back in the comments.

Q. What’s your game? What do you do?

A. Short answer: I take software projects that suck and make them not suck.

Real answer: Look, life is really hard. I’ve been working on one thing and the next, in about fifty organizations over the last fifteen years, and the same freakin’ things come up over and over again:

  • Everyone’s tired.
  • Everyone’s afraid for their job.
  • Everyone’s wasting time spinning wheels on stuff that doesn’t work.
  • Every software project is running late and pissing off the boss.
  • Every boss feels betrayed.
  • Every developer feels oppressed.
  • Software projects suck.

And I’m going huh. That shouldn’t be happening. I mean, this is ostensibly a “first world” country with tons of resources and lots of educated people who can do stuff. Software itself is complicated, but it shouldn’t be as hard as everyone is making it. Very often, we really do know how to make it better but for any of a thousand reasons doing the right thing seems to be beyond us.

And that’s my calling. It’s really quite simple. I take the things that are already actually known about making software projects go well and apply them to real life, so regular people can solve problems, live better, and maintain a certain level of sanity at work.

Q. Why do you do it? Do you love it, or do you just have one of those creepy knacks?

A. That’s a weird question, Naomi.

I happen to love having knacks for certain things. Is that creepy?

Also, I am in it for the love and the hugs. It’s so cool when I can help decrease the project suck factor so much they’re sad to see me go.

Q. Who are your customers? What kind of people would need or want what you offer?

A. If you manage, pay for, specify, benefit from, or try to oversee a software development project, and it sucks, we should totally talk.

Things that make you much more likely to benefit from working with me:

  • sense of adventure
  • willingness to be surprised
  • reasonable level of vulnerability

Things that make it very unlikely that you will benefit from working with me:

  • rather be comfortable than successful
  • like to be in control
  • quick to make up your mind about things
  • quite certain it’s not you

Not to go all New-Agey on you here, but Making Software Projects Not Suck is rarely just a matter of plugging away at code. I’ve had a few of those, but most of the time the problems are way deeper than that. Sometimes the things that Make Your Project Suck are the exact same things you love about the project: drama! action! involvement! Then you have to choose: would you rather have the drama or the success? Because having both is not an option.

I’ve even dealt with projects that, when you cut through the crap, are supposed to suck. Like one in which the lead developer was under the impression his job would end when the project did. Or one in which the project manager seriously couldn’t figure out how to live without the angst and panic. And there was the time–I’m not real sure about this one–but there was this kind of indentured-programmer setup and the boss kind of liked it that way. It was power.

So number one, the thing that totally stands out as the most important distinction, is that you have to want your project to not suck and you have to be willing to change. Okay, that’s actually two things.

Does that sound like therapy?

I guess it does. I’ve got people you can work with if what you want is real head-shrinking. That’s not my bag.

What is my bag is showing you the truth. Things like:

  • control isn’t progress
  • action isn’t accomplishment
  • progress isn’t a deliverable

If you’re up for that kind of challenge, let’s do it. If that scares you, then we should definitely do it. Buck up.

Q. What’s your marketing USP? Why should I buy from you instead of the other losers?

A. Losers? There are no losers in this.

But here are a few things that make my services unique:

  1. I help you get started using Agile practices (and feeling the Agile principles) at the tactical level. You can try one thing at a time–such as starting with pair programming–without having to commit to some big revolutionary cultural shift. It’s fine to experiment first.
  2. I’m attracted to, and effective with, the high-stress projects that make people crazy. I tone down the hype and make it easy to keep working  instead of panicking. I’m anti-drama.
  3. Unlike a lot of shops that offer “Agile coaching,” you can see my terms and fees up front, like here and here. I just think it would be weird to hide things like that in the sales cycle when so much of what I do is make your practices transparent. I’m asking you to open your shop and your mind. The least I can do is be upfront about my side of the exchange.
  4. I still write software myself most days. It’s not theory.
  5. There is homemade Indian food on Fridays, even though some purists object to the hot reddish-orange cast of my special aloogobi recipe. (It’s traditionally a yellow curry, and mild.)

Q. What’s next for you? What’s the big plan?

A. So glad you asked! I’m doing two things to make Project Desuckification more accessible even when I’m not.

The first thing

The first thing is that I’m documenting my processes a lot more diligently than I used to.

For example: before, I’d ask a few dozen questions before doing anything else with a new client. Now I write down a few dozen questions before asking. In a very recent meeting, I planned the whole interview, then diverged from the plan to follow some tangents, then got back to the plan so I could finish (almost) all of the questions.

That accomplished two things:

  1. I remembered to ask about some less-immediately obvious things that would have flown out of my head in the give and take of the conversation.
  2. I have a handy list as a jumping-off point for the next such initial meeting.

I’ll refine and augment the list in using it a few more times on successive projects. Before long it will be easy to turn that set of questions into a checklist, an article, a NOTACON presentation, or maybe even a Prfessor course.

So it goes with the other artifacts of Desucking: the emails that explain pair programming, my notes from debriefings, a particularly amusing burndown chart, bits of open source code. They’re resources for the next gig, but they’re also inputs for the next consolidated offering. Their specificity is what makes them so valuable; their universality is what makes them so useful.

At this point you’re probably wondering how I get away with ripping off all this stuff from clients who pay me to keep things private. I don’t do that! In fact, depending on the assignment, I ask them to join in my famous “Disclosure Agreement.” It protects their proprietary and confidential information, but makes clear that I can talk, blog, and publish everything else about the project. It’s like compost for desucking: useless where it came from, but invaluable for the next cycle.

The other thing

The other thing is simple timeline planning. Sure, I’m thrilled to death to help when your project already sucks. That’s my Thing. But unfortunately, projects reach the ultimate sucking point at unpredictable times, and there’s only one of me. They tend to pile up, and I have to turn someone down, and then their project still sucks.

So now I’m developing ways to make your project not suck before it even starts to suck. They’re principles and techniques that work at any time, are easy to implement, don’t require a lot of overhead, and make everyone more productive with less hassle.

That way I can plan ahead a little, and the potential clients can relax if I’m not right on the spot when things start to sink.

Most importantly and immediately, I’m developing some resources to help your team learn pair programming relatively quickly and get the most benefit from it. So far I’ve found that pairing is a very low-cost and simple way to get started with the Agile concept.

My research question: The managers who resist pair programming the most are the ones who just can’t wrap their heads around Agility. True or false?


There it is. That’s my game. Wanna play? It’s easy (and free) to start. Just dive into the comments, and if my way intrigues you, take a nice swim in the “Contrarian Guide to Making Software Projects Not Suck,” even though it’s an opt-in link. Because the weekly emails are even more fun than what’s on the blog.

Win: Cleveland GiveCamp

It is amazing how much you can accomplish when it doesn’t matter who gets the credit. GiveCamp rocked!

I’m probably just about decompressed now from the joy and struggle that is Cleveland GiveCamp. If you weren’t there, you missed a fun and exhausting time. (You also missed out on seeing me walking around with yellow CAUTION tape around my head. I’m learning to accessorize.)

How it came together

Mark telling yet another story at Cleveland GiveCamp 2010 closing demo meeting
Mark tells one of THOSE stories

You know this saying?

It is amazing how much you can accomplish when it doesn’t matter who gets the credit.

Organizing GiveCamp was like that. I was the nominal Leader of our semi-formal organizing committe, but I always cringe when saying that. Jon Stahl was the de facto leader, at least in part, because a) he’s organized big events before; b) he’s hooked up with the larger GiveCamp movement; c) he took charge of a huge portion of the logistical details; and d) it’s his boat. I’m not remotely comfortable giving orders or even strong suggestions, so it was often hard for people to tell it was “my” event. To me, “leading” stuff looks more like finding out what people need and connecting them. It’s a middle child thing.

Based on the capacity of the LeanDog boat, the organizing committee figured that 75 volunteers would be an ideal number. Working back from that, given an average of five volunteers per team, we thought it would be good to do projects for fifteen local nonprofit organizations.

Those goals turned out to be challenging. We didn’t have a surplus of applications for help from nonprofits, and while it seemed that we’d probably reach our volunteer goal we didn’t expect to go very much beyond it.

Then Margaret Bernstein visited the boat, and this article hit the Plain Dealer. Within a week, the requests came in by the dozens and we eventually received sixty-eight. About 130 volunteers registered in advance. I openly asked my fellow organizers, “How many volunteers is too many?” After all, that was nearly doubling the capacity of the boat.

And it’s a boat. It can sink.

That’s when Jon asked about using the terminal at Burke Lakefront Airport, which is less than fifty yards from where the LeanDog boat is moored. Burke said okay, and we became a two-site gathering.

Who did what

Among many, many other things that got done by other organizers:

  • Andy Craze went to a zillion user group meetings to recruit volunteers, and assigned them to teams a day or two before the event;
  • Larry Mingle made the Cleveland GiveCamp website;
  • Matt Beyer collated all the volunteer registrations;
  • Trish Rouru networked with many of our nonprofit partners, solicited food donations, and (together with Deb Stahl and Jane Winik) prepared all the meals;
  • Sam Nasr served as our Sponsorship Coordinator; and
  • Nick Barendt set up our fiscal sponsorship with IEEE Cleveland, talked to media people, and took care of many, many site details.

In summarizing like this I am leaving people out, and minimizing the accomplishments of those I did include. It really is amazing how much work goes into an event like this, and in the heat of getting things done it’s hard to remember who did what.

While they were not part of the organizing team, I especially want to pick out two other volunteers:

  • On Friday night, Amy Wong told me she was available to help write website copy for any and all nonprofits. Amy was busy all weekend with this. I think her words are on at least half the websites we did.
  • Also on Friday night, Heidi Cool (who was there as part of our social media team) foolishly reminded me that she can help with WordPress and design issues. We ended up doing about fifteen WordPress sites! Heidi was incredibly in demand. She also taught an hour-long seminar on WordPress content management for our nonprofit partners on Sunday.

What got done

Bottom line:

  • We took on twenty-two projects in software and website development.
  • Twenty of them were successfully completed during GiveCamp weekend.
  • All the nonprofit clients got training on using and maintaining their new software and websites.

That makes Cleveland’s the largest and most successful first-time GiveCamp. Anywhere. Ever.


Jim Gorjup solicited “retrospective” notes from all the volunteers and nonprofits. We wanted to know what worked really well, what could have been better, and what really sucked about this year’s event. Mostly, I took these handwritten scraps and passed them right along to Jim so he could collate them and talk about the themes, but one line got my attention. It went something like this, approximate quote:

I liked the way everyone cooperated and shifted from team to team as needed.

This was particularly evident when a scheduling application for the Richmond Heights Fire Department looked like it wasn’t going to get done. Jon–being pretty much the King of Agile around here–collected what we called the “rockstar team” of Ruby developers who were done with (or could be borrowed from) their other projects and prompted them to self-organize. The upshot, unfortunately, was that the project simply couldn’t be completed in a weekend. It was just too ambitious, and since the project was a last-minute addition to our lineup it was hard to know that ahead of time.

I count that as a win for the Agile concept. At least we were able to conclude that project wasn’t going to go, which gave us permission to drop it (for now) and reallocate our developers to something that had a better chance.

What’s next

In my closing remarks to the assembled GiveCamp community, I referred to “next year” even though there weren’t any specific plans to do this again. I caught myself and asked, “Wait, who wants to do this again next year?” I’d say the response was strongly in the affirmative. So we’re on for next year.

Which reminds me. There is still time to contribute cash for next year’s event!

Why I preach it

The other day, I gave a presentation on “Three Ways to Get Your Web Development Project Back on Track.” It’s the same overall concept as what you typically read on this blog, in a little different packaging. For one thing, they asked me to avoid using the word “sucks” too much. 🙂

I got carried away a little, maybe, with the motivation part. Why does it matter, really, if a project “sucks” or not? Why do we bother making projects successful and work life better?

It’s not profit

…because money is actually fake, just a proxy for value. The important things are whatever solves problems, alleviates pain, promotes health, and makes people happy. We push money around ostensibly to keep track of everyone’s contributions, but sometimes that connection is tenuous. The key thing is to Make Stuff Go Better. I really believe this.

What suckage costs

Software and Web projects can suck for any number of reasons (although I speak of eight main ones), but the suckage takes this kind of human toll:

  • Illness and exhaustion
  • Broken relationships
  • Diminished skills and enthusiasm

I talked about this part with some intensity. One evaluation read in part: “Good speaker… but sounds like the pastor at a really liberal church.” All right, so I got enthusiastic about the motivation part. I still think it’s a big deal.

So my point…

…and I do have one, is to consider the bigger picture. Optimize your numbers, sure, but try to work sustainably, work on the right things, and do it in a way that respects people’s needs.

Because that’s all you really have anyway.

Pair programming sucks. That's okay.

The only thing worse than pair programming is NOT pair programming.

Pair programming is fundamentaly as simple as it sounds, but in practice it has many layers.

You know, one way to look at Agile is to observe that it’s simply an attitude that recognizes that software is done by real people who have complicated personalities. Tasks don’t get done just because they’re next up on the Gantt chart, they get done because a human person has his or her head together enough to think clearly and figure them out.

That’s the nature of creative work. Thus, you’ll often find that production doesn’t equal resources multiplied by time on task. If you care about your project, cultivate the conditions that help yourself and others do their best work. And pairing, done well, helps bring about such conditions.

Continue reading “Pair programming sucks. That's okay.”

Faith-Based Software Development

How do you know that? Are you sure? Why?

Yesterday, while discussing a particularly difficult team-energy kind of problem, something led me to identify their methodology as “faith-based.” Everyone laughed, and they immediately got my point. Faith in a process is really no way to run a development shop.

Continue reading “Faith-Based Software Development”

The Saga of Lou

Don’t dismiss the weirdest person in the department. The weird guy may know something you don’t.

Sometimes projects are made to suck because people are cussed and they just won’t listen.

There was this time in late 1988. It was my first job out of college, with my freshly minted B.A. in Mathematics (!) and a lot of enthusiasm. It was a little financial services company just off East 9th and Euclid.

One of the first things they asked me to do was… kind of a drudge job. See, there was this database on our IBM System/38 mini. It had a file that included (among a lot of other fields) customer identifying information, balance due, and last activity date.

Continue reading “The Saga of Lou”

The other essential Agile ingredient

I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.

–the “litany against fear” from the science fiction novel Dune

Yesterday I got a call from a prospective client whose Project Does Not Yet Suck, but it’s starting to make little slurping noises.

The situation calls for someone who is “aggressive without being arrogant” and “can handle pressure” while “getting stuff done.” And I thought hey, maybe this project isn’t necessarily right for me for some other reasons… but she did catch the spirit of what I talked about a couple weeks ago.

See here. Humility is not contradicted by effectiveness. It just isn’t. They’re different things. Continue reading “The other essential Agile ingredient”

The one essential Agile ingredient

Agile isn’t about the work. It’s about you. You can’t change your company’s work life without changing YOUR life.

You know more than you think you know, just as you know less than you want to know.
Oscar Wilde

As I wrote last Friday, you just can’t know everything at the beginning of a project. A lot of times, you can’t even know things at the end either! That’s one way of looking at the whole “Agile” concept–simply realizing that your knowledge is limited and therefore letting go of a lot of things that you can’t control correctly anyway.

So what kind of manager works best with an Agile team?

Continue reading “The one essential Agile ingredient”