Perfection is the enemy

Right now I’m finishing an infoproduct. It’s a handbook, with audio and flowchart, for software-dependent startup entrepreneurs who don’t have a grip on the “buy vs. build” decision. In short, I’m creating this thing to help you figure out whether you should buy (or download!) some pre-existing software to support your business, or whether you’ll be better off doing a software development project even if you personally can’t get past “Hello World.”

It’s going to be a series, naturally, and the next segments will show you how to get started with that development project if you’ve decided it’s really necessary.

Continue reading Perfection is the enemy

The silver’s all around you

This is a response to Peter Kretzman’s coherent and insightful blog post, “No silver bullets. Really!” You should go read that first. I’ll wait.

Peter’s post, in turn, is a response to the classic paper, “No Silver Bullet: Essence and Accidents of Software Engineering” by Fred Brooks, in which Brooks says that complexity in software development is essential, not accidental. You should read that too.

Now here’s what I think.

Continue reading The silver’s all around you

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

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

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.

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

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

Project Planning: “Can we kill ’em tomorrow?”

What kind of organizations benefit from an agile approach to software development?

I was thinking of this around a year ago while working with a client who was thinking of reimplementing, for the first time, some important applications with .NET. One of the business-interface people started a planning meeting by stating:

Before we do anything else, we need to plan this whole project in detail. We need to know exactly how this is going to be done. Right now.

I don’t recall exactly how I responded out loud, but the monologue in my head went something like this:

Continue reading Project Planning: “Can we kill ’em tomorrow?”