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?

So…

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.

What to ask first

Sometimes you can’t make the project not suck right away. You need to do a pre-unsucking project to figure out the actual unsucking.

Oh my. Here’s a Project That Sucks. It sucks so much I seriously don’t (yet) know how to make it not suck. How crazy is that?

Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.

Continue reading “What to ask first”

Friday Night War Story

Nondisclosure agreements don’t usually come with an expiration date, but this story is so old nobody will care. Still, names have been changed to protect… oh… me.

I was doing this Clipper-on-Unix project (yes!) in 1996. It was a really big deal. The idea was to migrate a rather large vertical application from FoxPro on SCO Xenix (doesn’t that make you smile already?) to FlagShip on Linux. We would add a few major features, mainly interfaces to credit cards and some application-specific hardware. We had a few months to do it, and I was the only Clipper guy. (And by the way, can I just say that FlagShip itself was all kinds of awesome?)

Continue reading “Friday Night War Story”

Fantasy: the self-organizing team

Does it help to hand cards directly to developers and asking for status every day?

It sure does! It helps me feel super-duper important! It reassures the client that I’m in control! It reinforces my position!

It doesn’t get any more work done, but hey.

I wrote about this phenomenon in a different context about a week ago, but it’s come up again. Twice is a coincidence, three times is a pattern, right?

I was talking to a client the other day about a thousand things, in the space of half an hour. There were a few things that stung badly, but one of them was to the effect that I wasn’t managing the developers very well.

Continue reading “Fantasy: the self-organizing team”

Why I'm grumpy today

People who are effective at solving problems and making things better are doing valuable work. And nobody can long continue doing valuable work for free, or for stunted compensation, or in an atmosphere of toxicity and disrespect.

Wow. I haven’t been this grumpy about business in years.

It all started a few weeks ago when a mutual friend introduced me (virtually) to this fellow I’ll call Ben. Ben had a Project That Sucked. As you know, Projects can Suck in infinite different ways, and this one was considerably less sucky than most. Mainly, Ben’s client had been expecting a new commercial website that was a bit late already, and Ben’s PHP guy had just left for a cool new job out of town. And there wasn’t really that much to do to finish the site.

Ben got in touch with me about this just about a week ago.

It was one of those classic “90% done” issues. Seen it a thousand times. Shouldn’t be that hard. Continue reading “Why I'm grumpy today”

When the game is rigged

I’ve been thinking a lot about Victoria Brouhard’s recent blog post on “no-brainer” decisions. It’s a clever idea. When you’re trying to decide about accepting something like a job offer, ask yourself, “What would it take for me to say hell yeah?”

In other words, how would you change the offer–if you had the power–so it becomes something you couldn’t imagine rejecting?

Continue reading “When the game is rigged”

The biggest mistakes in small business

Two big mistakes in small business: 1) lack of clarity on who you serve and why; 2) undertaking big current projects for questionable future needs.

Melinda Emerson asked a good–albeit fairly obvious–question on Twitter just now.

I am working on an article about the 100 Biggest mistakes in smallbiz and how to avoid them. Does anyone have advice to share?

Continue reading “The biggest mistakes in small business”

Jazzed about products and projects

It’s Friday, which is usually my day for the big-picture, deep-thinking, philosophically confusing kind of blog post. This time, however, I’m going totally commercial.

I’m excited about this!

A couple of very different items that I’ve been working on for a long time have finally reached a state of substantial completion. I’m ready to get them into a market-friendly state that will enable me to help more people, in a very sustainable way that everyone can afford.

The first thing

The first thing is a Windows application that was custom-made for a local nonprofit organization. They’ve implemented a very successful environmental health program (one of many) that works with families to identify home health and safety hazards, remediate those hazards in a cost-effective manner, and educate the family on ways to maintain the healthy state of the home. There’s a lot of “workflow” involved, and the reporting issues are fairly intense because of federal grant requirements, and it’s further complicated by the need to support an offline distributed database because the inspector with his Tablet PC doesn’t have remote access in the field.

The new application has been in a solidly usable beta state for about six months. Now we’re calling 1.0 done!

[main dialog for Healthy Homes application]
The main screen looks kind of like this.

The next step

So consider this a pre-release announcement. If you’re working with HUD Healthy Homes or any similar program, and manual recordkeeping is making your quarterly reports a nightmare, or if you just want a better way to schedule all those inspections and followups… we should totally talk. Get in touch with me now and we can arrange a preview.

The other thing

The other thing, which I’ve been talking about on Twitter a lot recently, is my new Startup Booster series for entrepreneurs whose software projects do not yet suck, but might! If you’re starting a company, and particularly if it’s not a software company, the last thing you want is a software project that costs too much, takes forever, and doesn’t solve the problem you had in the first place.

Isn’t it hard enough to get your idea off the ground? The software part of your strategic plan has to help, not get in the way. That’s why I’m building the Startup Booster. It’s a series of super-accessible information products that show you a really clear path to making stuff work even if you aren’t a software person yourself.

Right now, I’m putting the finishing touches on the first module, Buy or Build? It addresses the first and most important question that a lot of entrepreneurs miss: “Do I need to do a software project at all?” In it, I show you a really simple and thorough eight-step process (with a flowchart!) to help you decide whether to buy an existing package, get set to develop something custom, or skip the whole thing.

That’s the perfect implementation of my favorite rule of thumb: the only bug-free program is the one you don’t have to create to begin with.

Here’s what you get

The first module, Buy or Build? delivers a PDF and an MP3. The PDF includes an overview of the whole process, the aforementioned flowchart, and a super-simple workbook that you can write in as you go along. The MP3 is half an hour of my soothing voice, giving you background on the buy/build decision and explaining all the steps with real examples and a few bigger insights.

Here’s when you get it

At this moment, Buy or Build? is in preview. You can buy it at a special discount price of $17 if you’re on my free keep-in-touch eZine list. Otherwise, you have to wait until next Wednesday to join in the fun.

Of course if you now buy the preview, which is honestly kind of rough around the edges, you’ll get the tidied-up finished version for free next Wednesday. Like duh.

The rest of the series

But wait! There’s more! Future Startup Booster installments will help with topics like these. (Not all will be separate modules though.)

  • Can you do the software project yourself? Is that so crazy?
  • Figuring out what kind of help you need… how to get it… how to manage it… and when to fire people.
  • Is Open Source or Free Software right for you?
  • Deciding on a platform (e.g. Mac OS X, Windows, Web) and tool set.
  • How to know when your contractor is snowing you.
  • Protocols for problem-solving.
  • Measuring return on investment.
  • Can you turn your project investment into a profitable product of its own?
  • When to upgrade.

I haven’t worked out all the pricing, but each module will be pretty similar to the first in terms of content and bulk: a half hour of audio, a workbook, an overview, and a visual aid. There will be a really good no-regrets bundle price if you decide to get the whole series. (By “no regrets” I mean the bundle price is discounted by what you’ve already paid for individual modules, so you won’t have to go “Dang! I should have waited for the bundle!”)

Next up:

I’ve already started on the installment that addresses getting help with your custom software project. I’m hoping to get that preview out to friends as early as next Monday and releasing it to the public in mid-February. This is an ongoing process, with new content at least every month or so.

So there you go.

You can get on the keep-in-touch list right now and order the preview of Buy or Build? at a pretty cheap price with the free update, or you can hang around until Wednesday and pay a bit more for the flowered-up product.

Up to you though. I really hope you decide to check this stuff out, because if you’re trying to get a startup going this stuff can really cut out a lot of the cost, hassle, and stress of software projects gone bad–and so much more affordably than figuring it out with a consultant!

Small isn't the new Big; that's okay.

Everyone talks about “authenticity” as a marketing technique, but if you can’t manage that you should at least not be directly misleading. It rarely gets your foot in the door, and even then you just end up with a sore foot.

A while back, I was led to Jason Cohen’s blog post on not trying to look like a big company when you’re not. Jason makes a good point, that when Lockheed Martin is ready to order 1000 copies of new software they probably won’t buy it from a small company anyway. That’s often true. But I think there’s a more important reason to knock off the high-falutin’ corporate image thing.

Continue reading “Small isn't the new Big; that's okay.”

The Power of Dumb Ideas II

Want to hit the next big thing? Don’t bother. Just build stuff that works and creates value!

Recently I wrote about some of the Really Big Cool Commercial Things people tried to do on the Internet when it was still kind of a fad. These Big Things tended not to work out either because they didn’t make sense to begin with, or because their perpetrators could never settle for something that actually worked and delivered value.

I think (and said then) that this is probably because people often enter into business for reasons other than doing stuff that works and delivers value. If, on the other hand, you *cough* do stuff that works and delivers value it’s a lot more likely your business will do well. Notably, it doesn’t have to have an amazing idea behind it.

My favorite example of this is those nifty little PC-based cash registers. I’m a bit out of date on who has what these days, but back in the early and middle 1990s it seemed like one out of four mall stores had something from Systems for Today’s Retailer, which went by STR most of the time when I worked there.

STR started a little like this. Scott and Chuck what I call a dumb idea: to mimic those $10,000 intelligent cash registers that know how much everything costs, calculate discounts, print time cards, keep inventory up to date, and send sales data back to the corporate offices. Except they would do it for around $3,000 on an industry-standard PC.

That’s all. That was the big idea.

I’m sorry, there just isn’t very much to it.

It hit big. Everyone wanted this. They made their first sale to a small chain of jewelry stores headquartered in California. Then there were a couple of local Ohio customers. A place that sold swimming pool supplies, stuff like that. There was a chain of pet supply stores. And a nascent chain of computer superstores. None of these were gigantic wins, but they were mostly solid customers who paid a fair price for a good product.

Hey, there were a lot of problems with the software. By the time I showed up as the fifth employee, Scott’s office contained a clear box of 5.25″ floppy diskettes, generally three for the uniquely copied source code for each client’s custom applications. “Source control” was pulling things out of the box and putting them back.

What we considered the “base” application was about 160,000 lines of Clipper code, largely cut and paste from previous versions. In fact, one of my first really big refactorings involved merging eleven slightly different versions of the main item entry function into one, with just a little branching to distinguish the eleven kinds of transactions. It wasn’t the best code base to work with.

But it didn’t matter, not then, not really.

The key thing Scott and Chuck did, and this was seriously brilliant, was to figure out what people wanted to pay money for and making it work well enough to use. (Well, that and hiring me.) In a few years, STR had become fairly stable and rather profitable. We had matching 401(k) plans and good health insurance. It was a good place to work, and the software itself got quite a bit better as we improved our code and project management practices.

I started working with those guys almost twenty years ago now, and I still keep thinking… wow, it’s just a cash register with a regular computer in it. That’s all.

What’s the difference between a Great Idea and a Great Business?

One is fun to think about. The other is a lot of hard work.

And what do you know, tonight begins Startup Weekend Cleveland. In about five hours, I’m going to join about seventy other business and technical people to talk about ideas, pick a subset that the group will develop into products, and personally contribute to one of those. Which ones will be most successful? I’m betting on the ideas that make people say “I need that!” not “Oh cool!” In other words, the stuff that works and creates value.