Guest Post: How to Neglect a Product to Death
By: Dan Reese
My friend and former co-worker Matt Ryan recently commented on the impending death of Novell Forge. A message on the Novell Forge site confirms that Novell will be shutting things down soon. I can corroborate some of Matt's story as I was on the Forge team for about a year during its heyday.
But what really interests me about the situation are the implied instructions on how to neglect a successful product into a slow death that can be blamed on the product itself.
- Avoid rewarding or recognizing any of the people involved. Even better, reward someone else.
- Do not feed its success. Withhold funding, staffing and career growth opportunities.
- Provide poor support. Delay fixing problems.
- Set unrealistic goals and expectations. Blame the product or team for failure.
- Find excuses to kill the project. Focus on the negative in all meetings with executives.
This was a particular worry at Mozy when it was acquired by EMC. They promised that EMC did not want to be the lumbering elephant that accidentally squashed its shiny new purchase. And it was true. But we worried about accidental squashing anyway.
It has been two years, and I have seen projects and executives come and go. Though I do not believe it was intentional, at times it felt like Mozy was being neglected. But the core of Mozy has remained strong and continues to grow.
Based on my experience, here is what to do to keep a successful product moving forward:
- Execute anyway. Deliver a quality product in the face of neglect.
There is precious little a neglected production team can do other than produce. I heard something once I have always remembered: nothing succeeds like success. It is much harder to produce in the face of neglect, but it is also nearly impossible to ignore or argue with.
Mozy is clearly not perfect, but despite occasional neglect it continues to provides a valuable, profitable service. Working with smart people helps. Working for smart people helps. Working with people you like helps. Working on something you care about helps. Working with cool technology helps. But over time, delivering a useful, profitable product is what matters.
(This guest post is originally authored by Dan Reese and reprinted by permission. It is subject to the copyright terms at the original location.)
Fudging Complete
Are you guilty of this?
If you have kids, I bet they do it. You tell one of your kids to mow the lawn or do the dishes. After a while you see them playing XBox or watching TV. You ask, "Did you mow the lawn/finish the dishes?" "Yeah, I'm done," they claim. Then you go to check out the handiwork, only to find that there's a good 100 square feet of lawn that simply got skipped, or that all the dirty pots are still sitting on the countertop.
Don't get so high and mighty: You probably did it when you were a kid, too.
Apparently, as we grow up, we change. Some people don't, I guess. Some people continue to knowingly lie about this stuff even as adults (e.g., presidents of the USA). But most of us change a bit. Perhaps we don't like getting caught. Or we don't like the idea that we failed to do something we said we'd do.
The problem is, even though most of us change, it doesn't mean we are all delivering what we committed to.
If you've been given a task, completing the task means completing the work pertaining to that task. All of it. Not "the bulk" of it, or "the majority" of it, or "everything except a few odds and ends." It means the whole thing.
That's what Fudging Complete is. It's when, either because you are afraid of the consequences of not finishing, or because you don't like to admit failure, or because you don't want to lie, you try to convey a sense of "complete" when you aren't really complete. You redefine "done" to mean "mostly done". Or you change the definition of the task so that it matches the work that has been done, even though now the task doesn't match its intended purpose.
It's when you knowingly check in code that hasn't been fully tested in order to meet your feature complete date. You know the feature isn't actually done, because you haven't completely tested it. Or maybe you've done some preliminary testing on it, but you haven't written your unit tests. You know if you do what you should, you will miss the date, and that looks bad. So instead you can make your date by checking in today. You are knowingly incurring test debt, but at least you made your date. But you aren't really complete.
It's when you are at the end of a sprint and you take a look at the committed items, and notice that all but one of the committed items are done, and report your sprint status as having met your commitments anyway. In the footnotes you make note of the fact that the sprint is complete, except for one or two small tasks that didn't get finished, but other than that the sprint is complete. But you aren't really complete.
If you do this, you are Fudging Complete. You are like the movie rated PG-13 for "partial nudity." What does it mean to be partially nude? You are either nude or you aren't! A movie either has nudity in it or it doesn't.
Of course, "partial nudity" technically makes sense and is in fact quite common. I am partially nude as I type this post: My forearms are fully exposed. But the term doesn't really mean what it implies. Saying a movie contains "partial nudity" is simply one person's way of trying to deceive you about what is really in the movie. It doesn't have nudity! It only has partial nudity!
Fudging Complete has the same effect. Telling your manager that your project is complete, except for one or two loose ends, conveys the wrong sense to your manager. It is technically possible to be partially complete, but saying it doesn't convey the right message. It tries to convince your manager that you are complete, and you aren't.
When we do our work, we need to approach it the way a basketball player approaches shooting a basket. When you're playing basketball, whether you will take the shot depends on a number of things: Whether you actually have the ball, whether you are near enough to your basket that you think you can make the shot, whether anyone on your team is open closer to the basket, whether you are open to take the shot, etc. However, you know as you shoot the shot that there's a chance you will miss. Missing the shot is no big deal; every basketball player misses shots. If you miss, it is not that big of a deal. You quickly regroup and get ready for your next opportunity to shoot.
Working on software projects needs to be like this. It is okay to miss. Everyone misses. Sometimes software engineers are afraid to fail, so I don't call it "failing" — I call it "missing." If you miss, learn from your mistake and do better next time.
What you shouldn't do, however, is be dishonest about missing. Everyone misses. You are not perfect. Good teams and companies and managers know you will miss and will appreciate you being frank with them about what happened, instead of trying to redefine what completion means to make yourself look good. Don't do that. Don't fudge complete.
