#101: “I want to be able to comment on a comment.”
#102: “I want to be able to post a question in response to a comment.”
#103: “I want to be able to post a comment or a question.”
#104: “I want to be able to post an answer to a question.”
#105: “I want to be able to comment on the conversation as a whole.”
This is oversimplified and (only very slightly) dramatized, but you see the overlap and the potential for confusion. These story cards are blocking a ton of other work that needs to be done in the next couple of weeks. And they’ve been claimed by different developers!
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?)
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.
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.
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
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?
Jason Cohen guest-posted in December 2009 on the great blog On Startups, disputing the startup cliche that it’s always good to release your product early. He makes a good case to the contrary, although like some commenters I don’t think the iPod is a fantastic counterexample. (I mean come on. It’s Apple. They can get away with wild new design ideas, it’s what they do.)
Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at).
Which, it should not surprise you to know, reminds me of a story.
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!
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!