Today I’m talking about two different kinds of Process. On the surface they’re very different, but both kinds exist to support you and protect you. They’re also similar because some people regard them as threats or compromises.
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.More
As almost everyone knows by now, I work with Software Projects That Suck and make them not suck.
But then there are the projects that can’t be made to Not Suck.
Last night I had the pleasure of hearing Jon Stahl‘s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.
It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.
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?
I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.
Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)
On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.
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.
Over the past few years, I’ve studied what it means to market and sell professional services like mine. Honestly, I’m in a weird place with that, because I’m a huge geek (and still speak FORTRAN fluently) but a lot of what I do is what is sometimes, probably condescendingly, called the “soft skills” realm.
That makes it hard to answer that inevitable question, “So, what do you do?”
I used to reply with variations that started, “I’m a software developer” or “I’m a Unix guy.” But that doesn’t quite tickle the people who really need me.
In my experience, most software-dependent startups fail because they never actually finish the software. It’s really that simple.
I’m trying to figure out how I feel about Jeff Atwood’s recent proclamation: “Version 1 Sucks, But Ship It Anyway.” As a connoisseur of Software Projects That Suck, I get Atwood’s point: you don’t really know what’s wrong with Version 1.0 until some real customers get to play with it and let you know what they think. I’ve often spent days or weeks perfecting a feature that nobody cared about! Why not save that time by getting feedback first?
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.