Rule #9: Research is not development, and development is not research.

Textbook mid-life crisis

Textbook mid-life crisis

Software development has two phases, and you are constantly flipping between the two. There is the research phase, in which you are thinking about what you want to build. And there is the development phase, in which you are actually building. These two phases are polar opposites of one another.

The goal of the research phase is discovery – you are looking for the “a-ha!” moment. You are not trying to create something, you are trying to decide what it is that you want to create. You are searching.

The goal of the development phase is quality – you know what you want to create, and your goal is to make it great. You are building.

You need both phases, but it is critical to remember that searching is not the same as building.

The Research Phase

Let’s say your name is Christopher Columbus. You’re about forty years old or so, kicking around Genoa, and you have something of a mid-life crisis. Because you have a bit of a big head about you, you suspect one day you might be written about in a blog, so you decide to speak and think in a terrible faux-Italian accent.

“My life-ah,” you say to yourself. “My life-ah, it is too much-ah about the pizza-pies and not about the finding new countries.” And so you decide that, despite your financial advisor’s stern advice to keep all of your gold in a diversified portfolio of stocks, bonds, and an index fund which tracks the price of Roman Catholic indulgences, you instead blow everything on a sailboat, rope in a bunch of your drinking buddies, and head out to the islands for a long party with the locals.

Now, if you were looking for, say, a world — a New World, perhaps? — how would you do it? Well, here are a few tips:

  • Get a lot of people involved. Involve a queen if possible.
  • Try a number of different approaches. Don’t get just one boat, get three.
  • Don’t get too hung up on exactly where you are going.
  • When you encounter something new and unexpected — say, for example, you accidentally stumble upon, I don’t know, North America while you’re heading for India — just go with it.

The goal of discovery is to find something new.

In other words, you are actively trying to create a set of conditions around you so that you find something new, non-linear, and unexpected. Research is a great way to find a brand-new solution to a problem.

The Development Phase

Seems like there may be easier ways to get her phone number

There may be easier ways to get her phone number

Now, say, for example, you’re a friend of Columbus. Let’s call you Leonardo. You’re a painter, a sculptor, an architect — in fact, you dabble in a lot of things. Truth be told, you probably spread yourself a bit thin at times, but that’s okay, as you’ve always considered yourself something of a Renaissance Man.

Your friend Chris approaches you one day. “Leonardo,” he says. “Leonardo, you’ve been-ah working too hard-ah. And don’t take this the wrong way, but painting that girl with the weird smile we met at Senor Frog’s the other night? I don’t know, seems like it could sort-of creep her out a bit, you know? I think you could use a vacation. How about a cruise?”

And, to be honest, you have been working pretty hard. And, hmmm. Maybe an all-inclusive might be just the thing.

And so there you are, on the Santa Maria for a few months. The breakfast buffet in the morning is well-stocked, and the bacon is pretty crispy. You’re perfecting your shuffleboard game in the afternoon, and there are worse things than ordering a Mai Tai on the deck and watching the sun go down each night.

Until, of course, the ship runs aground, and everyone looks around for someone who knows how to build someplace to live. And wouldn’t you know it, save for the waiter who had one stupid line in The Merchant of Venice and now thinks he’s somehow going to parlay that into a supporting role on a new sitcom, everyone else on the ship seems to be some type of sailor.

“Fine,” you say, shaking your head and setting your Nina Colada down on the table. “Fine, I’ll build a fort for us, but I am definitely asking the travel agent for a partial refund on this cruise. Fort-building was not part of the plan, the shrimp cocktail I had at my last supper was barely edible, and the Merlot is seriously beginning to taste like water.”

But such are the risks of booking travel through a friend, and so you set about building a fort.

Now, let’s say you decide to apply the key principals of research to your fort-building process. Specifically, you decide to get a lot of people involved and you try a number of different approaches. You don’t get too hung up on exactly where things are going, and when you encounter something unexpected, you kind-of “just go with it.”

Most folks would probably intuitively feel that this is not the greatest way to build a fort. In fact, most folks who, say, might find themselves in the market for a nice two-bedroom-two-and-a-half-bath fort, and discovered the “Fort Discovery Condos” in an online search might decide — despite the granite counter tops and all-new appliances, which they have to admit, really would be the perfect place to throw a house-warming — that this might not be the most stable place to live. And nothing ruins a good bruschetta more quickly than ceiling tiles raining down upon it.

Research is a great way to find something, but it is not a great way to build something. When you actually need to build something, your goals are the  exact opposite of those you had when you were in the research phase. That is, you don’t want that many people on the project. You don’t want a number of different approaches: you want one. You want to know exactly where you are going, and, should you encounter something unexpected, you want to stop and solve that problem right away.

Research is about maximizing the unexpected. Development is about minimizing the unexpected.

How the Two Phases Feel

Discover a new world on your next cruise

Discover a whole new world on your next cruise

If you are in the research phase, each new idea will feel fresh and exciting — and you’ll want to create hundreds. If you are in the development phase, however, those same new ideas will feel confusing, troubling, and will slow things down as your team “chases” or, even worse, simply stops to wait until those ideas are solidified so they can continue properly.

If you are in the development phase, strong designs, specifications, and processes will feel calm and peaceful. Every day a small new part of the project will get completed, and every day you’ll feel a little bit of progress. However, if you are in the research phase, that same approach will feel old, confining, and boring. You’ll look around and feel that your competitors are “getting away from you” and that your team “isn’t moving quickly enough.”

If you want to build software, it’s important to recognize that there are two phases to the process, and you will need to decide how you want to separate these phases. There are a great number of ways to do so — and the approach that works for you may be completely different than the approach that works for another.

But if you don’t know which phase you’re in, then: hit the brakes and figure it out. Because you most definitely need both phases — you just can’t blend those two phases into one.

Rule #8: Follow the five-minute rule.

When I was five years old, it was a well-known Law of Physics that if you dropped a cookie on the floor, it was “still good” if you picked it up within five seconds. This, appropriately enough, was know as The Five Second Rule and I’m fairly certain a lot of children are aware of this rule even today.

Go ahead. Pick it up.

Go ahead. Pick it up.

I think this is a great example of a rule which, though seemingly very simple, actually aggregates a large number of goals that a nearby adult likely wishes to achieve. For example:

  • You would likely prefer this child not start crying, screaming, or kicking things because he no longer has a Choco-Licious-Cookie-Surprise in his hand.
  • You would rather this child not start punching his sister and trying to grab her Choco-Licious-Cookie-Surprise.
  • You would prefer not to have to shell out $2.75 for another Choco-Licious-Cookie-Surprise.
  • You would like to make it on time to your friend’s house for your 12:30 lunch, rather than drive back to the Choco-Licious-Cookie-Surprise-Warehouse to buy another Choco-Licious-Cookie-Surprise and miss your lunch date.
  • You are fairly certain that even if you did go back to the Choco-Licious-Cookie-Surprise-Warehouse, there is a greater-than-70% chance that said child will again drop this item on the floor.

So, though I am quite certain that The International Council of Pediatricians Who Fight Adults Who Think It’s  Okay For Kids To Once-In-A-While Eat Things That Have Dropped on the Ground will send me some angry letters, I’m going to go  out on a limb and say that I think, used properly, the Five Second Rule is a pretty valuable rule, and I  intend to use it to its fullest the next time I see my nephew.

It’s in that spirit that I’d like to introduce “The Five Minute Rule,” something several employees at Leverage  Software have heard me speak about many times. The Five Minute Rule goes like this:

“If you are evaluating a piece of software, and you can’t make it do one thing — no matter what that is — within five minutes, don’t buy it.”

So, what’s behind this rule, really? Well, just like the Five-Second Rule, the Five Minute Rule is actually an aggregation of goals that I’m trying to accomplish. Specifically:

  • I want the Total Cost of Ownership (TCO) of any software we buy to be as low as possible. If we can get something working within five minutes, it means that there’s a good chance that we won’t be spending a lot of time on things like installations, configurations, and other potentially expensive tasks.
  • I don’t want to have to invest heavily in training our employees to use a new system. If someone can figure something out in five minutes, there’s a good chance that the software is either (a) pretty easy to learn, (b) very elegantly designed, or (c) just not that complicated overall. All are fine by me.
  • I want every piece of software we purchase to be created by people who really care about the people who are actually going to use the software, and who spend the time thinking about how to make it better.
  • I don’t want to buy software that is buggy, has problems, or was rushed out the door. If someone had the time to spend on making sure that the “out of the box experience” for their software was positive, they probably also had the time to fix any bugs.
  • I want to buy software that I like.

Now, I do want to be careful here and state that the Five Minute Rule doesn’t mean that I should be able to do everything the software does within five minutes. Some things will take time. For example, if I’m evaluating, say, some sort of sales tool and I want to add a new customer record to a database? Five minutes, tops. If I want to build some sort of complex report which provides me with sales forecasts for the next six quarters? That can take longer. The point isn’t that it has to do everything in five minutes, just that it can do something.

To some, this might sounds like a trivial (or even obvious) request. Consumer applications in particular, of course, can only succeed if they adhere to this rule.

However, in the business software world, I have to say that I am continually amazed by systems that most certainly do not adhere to this rule. Backup systems that take six hours to set up. Collaboration tools which assume you have a set of internal IT staff who have a lot of extra time on their hands to install, configure, and maintain a new system. Marketing tools which require you attend a set of training seminars before you can get the system doing even one thing.

Just as the Five-Second Rule doesn’t ensure you’ll have a happy five-year-old, so too the Five-Minute Rule doesn’t mean that you’ll buy a perfect piece of software. And it does tend to be biased towards software-as-a-service (SaaS) systems, which I do strongly prefer but which may not be appropriate for every scenario.

But it tends to be a good rule-of-thumb. And, if you are running a software company or creating software of some type, I think it’s worth asking: does your software adhere to the Five-Minute Rule?

Rule #7: Use as little technology as you can for as long as you can.

Change is part of every project, and one of the most effective ways to create something great is not to hide from this idea but to embrace it. If you know that things are going to change, then meet those changes head-on. One of the best ways to do this is through rapid iteration using lo-fi tools.

Hi-fi may be groovy, but lo-fi is useful too.

Hi-fi may be groovy, but lo-fi is useful too.

Most industries understand this simply due to the obvious expense of the technology they work with. For example, if you wanted to build a bridge across, say, the Bering Strait, it is unlikely you would immediately “just start building it.” Instead, you would likely talk about the idea — over and over and over again — perhaps for years. And, once you settled on the fact that this was a good idea, then you’d likely start sketching out designs and concepts using simple tools so that you could try as many different ideas out as possible.

You would likely not use a cold-weather construction crew and a few million tons of steel to “try things out.”

The actual process of creating software — almost anything creative, actually — is similar. However, software tricks us because a software developer writing code seems to be much less expensive than a construction worker creating a steel truss. However, no matter how easily a design can be “refactored” over time, changing code is simply always more expensive then changing your mind.

Some years ago I attended a workshop led by Jared Spool, CEO of a Boston-based firm called User Interface Engineering. Jared is a big proponent (among many others) of an approach called paper prototyping, which is just want it sounds like: you use lo-fi tools like paper, pens, and crayons to design software — instead of using software to design software.

This turns out to be a very good idea, because:

  • It allows you to embrace iterations instead of hide from them. Have thirty-six different ideas for a new interface? Excellent! You can whip them up as quickly as you can draw.
  • It provides you with flexibility. Change your mind five days later about what you really wanted in the first place? No problem — iterations are designed to help generate new and diferent ideas. Throw a few sheets of paper away and start over.
  • It’s a great communication tool. Want to get input from others on an idea? Not a problem — as long as everyone is “working in lo-fi,” it’s easy to flush out new ideas and gather new input without having to worry about how it will impact “what you have so far.”

In other words, if you know that a solid project will require a large number of iterations, then you should try to set yourself up with tools which allow you to go through as many iterations as possible as quickly as you can.

Rule #6: Keep your programmers in the zone.

Earlier this week I attended a great presentation by Ron Lichty, an incredibly talented and experienced VP of Engineering who has managed a number of amazing projects at places like Apple, Razorfish, and Charles Schwab. One of the items that Ron discussed that really hit home with me is that it’s important to try to keep programmers ‘in the zone.’

Oscar clearly in the zone.

Oscar clearly in the zone.

Every programmer instinctively knows what Ron means by this. When you are writing code, and everything is just clicking — you can be incredibly efficient. You start writing, and writing, and writing, and suddenly the sun has gone down but things are just working and a feature that you initially thought might take a week to write takes a day, and it just feels good.

Now, if you are managing a software project or a software company and your programmers are all “in the zone,” it is entirely possible that the product that you were hoping to ship “sometime in Q3 of 2015″ may now ship in about seventeen minutes.

This is a good thing. This is a very, very, very good thing.

So, at this point, you might say to yourself, “sure, Joe, that’s great. I would love it if my programmers were all in the zone and if my software project shipped in about seventeen minutes. But, how do I get there?”

Easy. Three steps to the process.

First, define, upfront, exactly what you want to build. This  is the single most important thing you can do. If, for example, you are making a robotic duck, it’s important that you know if your duck is going to say “quack” with an American accent or “kvack” with an Austrian accent. If you don’t know this, that’s okay, but just remember: if you want to have your programmers in the zone, until you know what you want, don’t start building the duck.

Next, once you know what kind of duck you want, and you’ve written up some beautiful description of that duck, and your developer says “yes, I completely understand, this is going to be the best robotic duck ever created,” then the second-most important thing you can do is this: once you know what you want, let your team build the duck. In other words, don’t tell them they need to go to a meeting that afternoon to “brainstorm” about pelicans. Leave them be.

Finally, while they are building your lifelong dream, “Hans Kvacky McKvack, the World’s First Austrian Robotic Duck,” the third-most important thing you should do is this: don’t change your mind about the duck.

Now, in reading this most everyone involved on any software project will say: “Ha! That’s fine, but that’s not how things work in the real world! And, anyway, aren’t we supposed to iterate? This doesn’t seem right — things change, Joe, don’t you get that?”

And I will say: why, yes. Yes, I do. Change is part of every project — it’s inescapable. So the question is: how do you take something that is inherently filled with change on the one side, but somehow optimize a development process which is most efficient when you avoid change?

Rule #5: Count iterations, not days.

Suprised by tenuous link made in this blog post

Showing suprise at tenuous connection made between mushrooms and software

Writing software is like writing a screenplay — you have to do things a few times to get it right. The creative process is like that.

Every writer understands, intuitively, the concept of the “first draft.” For example, say you  have an idea for a movie.

“Hey,” you say. “I’ve got an idea for a movie. It wil be about giant mushrooms. They’ll live on another planet. And they’ll fly to earth looking for things to eat. Like, hmmm. Like people. Yeah. This will be a movie about giant mushrooms that eat people.” And you sit down and start writing.

And after a little bit of time you realize, hmmm. This movie, well, it will have heart. And soul. And, you promise, it won’t just be some hollywood fluff. It’s going to really challenge the intellect like no other people-eating-mushroom movie ever has.

But.

But, you realize. This movie? It may be a bit tough to cast. Julia Roberts really has range, you’ll say, but it’s going to be tough to convince her to really “get” the mushroom persona, you know? And, hmmm. Well, maybe, just maybe, those mushrooms should be…something else. And you write a second draft. And a third.

And twenty-nine drafts later you realize you’ve just written Erin Brockovich, and congratulations, you’re up for an Oscar. “Julia,” you’ll say as you hand her a glass of champagne at the Oscar party. “Julia, you really nailed it.” And Julia may never know that the first version of this script had, well, a bit of a different focus. And that is just fine.

People understand that with movies, you need to iterate. With books, you need to iterate. With painting, you need to iterate.

Writing software is like this too: often, you just need to iterate. I’m not sure why, but sometimes — a lot of the time, actually – you just have to do things a few times to get it exactly right.

So if you are managing a software project, and you want to figure out how close you are to being “done” — don’t count the number of days your team has worked on an idea, count the number of iterations they’ve gone through. This number will likely give you a much better idea of how close you are to completing your project.

Rule #4: You are leading an army of poets.

malta

If they only knew.

For a long while people have joked that “managing a software project is like herding cats.” I’m not a big fan of this saying for a couple of reasons. First off, I don’t really like cats all that much, which I know is heresy to the 4.2 million readers of Cat Fancy and all those people who think it’s somehow a good idea to train an animal to go to the bathroom inside your house. But secondly, and perhaps more importantly, I’ve always thought that the statement suggested that nobody on the team actually wanted to work together and get something done, which is definitely how cats tend to think but not really how most good software developers I know do.

Which led me to think of another phrase that I think is more accurate: “managing a software project is like leading an army of poets.” This works for me much better because, for one, I like poets, and two, I think an army of them would actually want to work together to, say, invade Malta, but they just wouldn’t necessarily be very interested in all the marching around and doing drills and whatnot. And this visual somehow does jive with my view of real software developers, most of whom are willing to work together so long as there isn’t a lot of nonsense involved.

So, if you are managing an army of poets, what would you do? For one, cut the junk: neither poets nor software developers are going to love a lot of meetings where not much gets done. Secondly, remember that most good developers have a lot to offer in the way of creativity and insight — and you want to create a culture which recognizes that core fact. (In my experience, a very large number of the best ideas we’ve had “bubble up” from one of our developers saying “hey, I thought of a better way.”)

But, finally — and this is an important note — I think it is key to remember that this isn’t an academic department of poets, or a book club of poets — it’s an army. That is, if you work in a business setting of some sort, it’s probably important that something gets done. And there are going to be a few times in which you will need to remember that it’s important to keep on the move, and that yes, poets or no, people will need to work together.

Rule #3: Think new, and think big.

hillary swank astronaut

Later rescued by whales. Really.


If you buy into the first rules — that is, you love software and you agree that mostly, stuff doesn’t work — then rule #3 is sort-of the natural combination of those two rules. Basically, if you — or your team — is going to spend a lot of time working on something, and that something probably isn’t going to work, then doesn’t it make sense that if, in the off chance that it does work, that it should actually be worth doing? Consider the following two movie scenes:

“Well, there may be aliens who shoot at us, and there may be an asteroid belt we have to fly through, and we may have to put ourselves to sleep for a year, and we may have to build a crazy spaceship that’s never been built before, and there may be some seriously bad acting in this movie — I mean, we’re talking Hillary-Swank-and-Bruce-Willis-in-astronaut-suits-bad — but if we pull this off, we’ll be living on mars! Can you imagine? Mars!”

That’s the first movie playing at your local Cineplex 22. And then there’s this other movie:

“Well, we may already have a working order-tracking system in-place, and we may have a reporting system that’s been chugging along for 10 years, and it may be annoying that one of our systems runs on Solaris, for god’s sake, and another system works on some weird mainframe thing, but if we pull this off, we’ll have another, different system that will be 10% better than the existing system!”

Which movie would you rather see? The correct answer is, actually, none of the above, since we should really all come together and agree that (a) Hillary Swank should never, ever go into space and (b) that building systems that are only 10% better are not actually worth any of our time.

I am pretty sure there are a lot of people out there who will disagree with my comments here — which is just fine. Is there room for making something 10% better? Of course! (More on incremental improvements later.) What I am trying to say here is, simply, if you are starting out a new project, try your best to find a way to allow yourself to dream a little.

Note: Hillary Swank went to the center of the earth after a brief time in space. Why this seemed like a good idea to anyone, ever, I’m really not sure.

Rule #2: Mostly, stuff doesn’t work.

working machine

Some things work a little.

Great software developers know a very basic fact about software development: mostly, stuff doesn’t work.

I don’t know why this is as true as it is, but it just is. I suspect it might have something to do with entropy, or maybe some weird chemical reaction that gets triggered inside the human brain when a group of people smell a whiteboard marker. Perhaps little gnomes break into office parks throughout the world late at night and randomly mess things up. But whatever the reason, it is a universal truth: if you try to build some software, chances are it isn’t going to work.

Sometimes, it doesn’t work because the problem is really hard. Sometimes, it doesn’t work because people keep changing their minds, and computers are not very good at letting you change your mind. Sometimes, it doesn’t work because the people who make it start to lose interest in it, or hire some bad people, or fire some good people, or maybe both. Sometimes, the code itself sort-of does something, but nobody really likes the thing it does. Sometimes, the code doesn’t really do anything, except maybe crash.

The point is, there are many, many ways that software doesn’t work. Every time you start a software project, the odds are always against you.

What lessons should you take away from this rule? Well, for one, you could think of software like smoking. If you haven’t started, don’t. And if you’ve already started, try to quit. It’s generally a bad idea to keep doing anything in which the odds are that it will end badly.

But if the idea of software-as-smoking doesn’t really sit well with you, and you’re more of a glass-half-full kind of person, then perhaps we need a new metaphor. Sending people to Mars for example. The odds are still against you, but hey, if you make it, you’ll be on Mars. You’ll be a Martian.

This is actually not too far off how a lot of good programmers I know think. That is, they know that, mostly, stuff doesn’t work. But if it does: hey, they’ll be on Mars. Which leads me to the next rule.

Rule #1: You have to love software to build software.

Building software is a ridiculous art. You sit in a dark room somewhere for hours on end, sitting way to close to a TV screen, giving yourself carpel tunnel syndrome. Typing, over-and-over again, the same 100 words or so, in different combinations, and if you don’t do it more-or-less perfectly, everything breaks. Sometimes you do this by yourself, and sometimes you do this with a team of people who all think this is actually a good way to spend some time.

If your goal is to be a nice, sociable, interesting human being, this is not really the smartest way to spend your days. You don’t get a good tan, your arms get skinny from all that sitting, and when people talk to you your mind sort-of tends to trail off trying to “fix” things you see around you, like, say, the train schedule on your way to work.

And yet. If you spent some time — probably as a kid, maybe as a teenager — playing around with a little device, trying to get it to work, and, one time, after about eighteen tries, it actually did something — something you wanted it to do — well, there is a pretty good feeling there. It’s fun. And you sort of start to love that type of fun, that fun that you get when a stupid little collection of wires and plastic bits and screens sort-of do what you want it to do.

Over the years I’ve had the great fortune to see some very smart people make computers do some very cool things — and they loved doing it. I’ve also been lucky enough to do that myself a few times. That’s a good feeling.

I’ve also seen some people who don’t really care for software — but who think software is a good place to make some money. Guess what? If you don’t love it, it isn’t. To those people, I’d like to say: take up dog-walking. Or acting. Or neurobiology. Whatever floats your boat. Because if the actual “doing” part of making software isn’t fun to you, then there is a lot of extra junk that you will just hate.

Follow

Get every new post delivered to your Inbox.