This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Visit the Product Blog for more information on our products.

“the hero grabs his hermit cape” – oh man, that is great

This is a hard lesson to implement in companies. It can lead to just quitting anytime adversity is faced instead of trying to power on through.

I can see the benefit as far as profit goes, but I don’t know if that philosophy would lead to consistent great work.

My company has no problem with this. I was once told to scrap a simple wiki application because our manager did not like the “look and feel” of it. No redesign or nothing. I was forced to not be a hero.

So what Highrise feature did we just miss out on? :)

I used to be one of these hero’s. Then it hit me years ago that no one actually appreciated the effort you put in anyway. Now I consider myself as a realist – it comes with experience – with a hint of pessimism for any of those hero’s still out there. :)

I have a question..When you say “The feature was deemed valuable at a cost of two hours, not sixteen” How do you deem the value of a feature? It is either something needed or it is not correct?

So which feature has just been ruled out? :)

This reminds me of “Do The Right Thing” by Spike Lee. It’s all about figuring out what the Right thing to do is in a difficult situation. Often times the Right thing to do is counter-intuitive.

One of the reasons I’m as good a developer as I am (forgive the hubris) is a natrual inclination to never let a problem remain unsolved. If I were to abandon every project that took longer than I thought it would a) I would never finish anything and b) my horrible estimation skills would never improve.

I can appreciate your post from a “business perspective,” but my fulfillment as a developer comes from solving hard problems.

JF

Thank you, I appreciate your response. I still get hung up on the word “value” Is this your intuitive sense of what a customer would want or what you would want? in other words, Value begs the question, of value to whom? (I hope I used whom correctly)

This should be common sense by now. Excellent reminder for everybody. At the project I am right now, my manager is trying hard to be a hero. But I already told him he is being just silly. He is acting as the user of the product and is requiring new features and adjustments even before releasing. He can’t grasp the concept of releasing earlier and adjusting later. The product is done, but he simply refuses to release unless all last minute details – that he imagined himself out of nowhere – are done. Problem is: everyday he imagines some new thing to touch. He thinks that users will celebrate him later. I know the users: they don’t give a dawn, they only want to have their job done.

“You’re playing to win the full season, not a single game.”

True, but I always forget when I really need to remember.

Now, THIS is a post I can agree with. Dev for dev’s own sake is never good for a project. This is business, fellas, not the sandbox.

I can appreciate your post from a “business perspective,” but my fulfillment as a developer comes from solving hard problems.

Nobody – no professional developer who’s on the clock, at least – develops in a vacuum. Sometimes your stated fulfillment carries a price. Often, this fulfillment is in direct opposition to the overall goals of the project/best interest of the client. What do you do then?

[shameless blog-pimping]

Remember, as much as you might love software development, you’re not REALLY in the software development business.

[/shameless blog-pimping]

Gah, borked link.

Fixed link

Sounds like you’ve been reading (or should read) Seth Godin’s The Dip, about the power of positive quitting. :-)

Sounds familiar. Viva Open Source ;-) _Marc

That’s a problem even the best of the best suffer from.

Usually when this happens it’s because I get stuck in a specific mindset from which I just can’t get out of while working on the functionality.

Ofcourse most of the time you´ve been assigned a task that is related to a functionality that is in the specs of your project so cancelling it just isn´t an option. Most of the time I just take a break for 15 minutes and ask someone else on his view on the implementation of my task without mentioning my own view.

You´d be surprised at how much easier it was to implement after you take a step back.

We call it “zero-based thinking” around here.

http://www.nightingale.com/pa product Power_Clarity audio 2641.asp

Teams that hold giant balloons for parades are taught that when the balloon starts getting away, let go. It’s instinct to want to hold on, and when it takes you a few feet in the air, you don’t realize it’s out of your control. When it’s fifty feet, you don’t want to fall and get hurt. When it’s a hundred feet, and you can’t hold on any longer, you fall to your death.

Ok, I get the concept of sunk cost but the reality is that a few of those “quit calls” will cause my boss to think I am an incompetent idiot. Eventually I’ll land on the street with no job.

I’m currently in hero mode restoring a crashed hard drive. I can’t even say the number of hours out loud. Great post – but I’m not stopping on this one! I can see the light. I know I can win!

“5x work vs. estimate”

That’s your issue then. Estimate better. Or, if you’re the one not estimating, when you get assigned the work, point out the estimate sucks and why it sucks.

Yes, estimation and requirements engineering is a bit of a black art; however, if people focussed on it like they did design, implementation, or (nowadays) testing, I think we could all do a little better.

I totally agree with you, but sometimes I suffer about the i-must-to-solve-it complex.. It’s a challenge, I think only about that problem. Lately, I stop to code, I stand up, and think: Do really my webapp needs this? Often the answer is no.

MI: To answer your question, yes. Giving up on anything looks bad. If one of my programmers told me he gave up on an idea because it was more difficult then we estimated, and instead he moved on to do some easier things, I would be flabbergasted.

I think you get maybe one or two of these a year to look intelligent. I can appreciate when someone realizes that something is a lot harder then it seemed, and there may be more important things out there, but looking at work on features as “sunk cost”’s doesn’t feel like the right analogy to me. At least when you are answering to a corporation.

Let’s say 37Signals estimates that if Basecamp is integrated with Highrise and Campfire it would bring in an extra $50k of sales. Random 37sigs developer spends 6 months on this feature and his salary for 6 months is $50k. At that point, he should just drop the idea if he isn’t finished?

With sunk costs there is a logic as well. The idea behind sunk costs is you should not use the previous money spent to affect your decisions from here on out. The feature is still obviously needed… I’m just not sure the analogy holds up.

But then there is the other side of the equation.

Sometimes one feature can put your application in a whole new category. It makes sense that you will have the most trouble implementing a feature when you are going into uncharted territory. And these are the kinds of features that bring disruptive products to the market.

That’s how we got innovations like Google Maps using technology that already in everyones browsers for years. There was no one persistent enough to solve that problem before them.

In many cases, you will want to cancel a good feature or project because of how much you’ve spent on it. But in reality, you cannot reclaim what you’ve already spent. If you can get the feature done in one more hour, you might as well spend that one hour because that’s the new cost of the same feature.

I like the idea and I agree with it. There ares points during a features implementation where it should be re-estimated (probably at 20% and 80% of the original estimation). If you realize a new time cost that wasn’t apparent initially then it should be called out ASAP so the project decision maker (not always the manager) is aware. There is nothing wrong IMO with a developer saying: “This is going to take X hours/days longer than expected because of Y issue that has arisen”. Often I will add: “This additional work is risky and should be avoided entirely to ensure the current ship date”.

As for managers allowing projects to slip because of feature creep (both incorrect estimation and additional functionality) – I wash my hands of it. If I re-estimate a feature and they simply must have it then that is their business.

And I hate walking away from partially implemented features – even when I know it is the right thing to do.

Sounds soooo familiar! For me, playing the hero cards has led to working nights / weekends, full of unpaid, non-billable hours. But giving up is rarely an option, what to do?

good god people! don’t turn off campfire when you are four hours overdue on a project – turn that cr-p off /right now/...

Kill your darlings. Next.

I find myself several times trying to be a hero, while in all aspects, it is worth walking away for my business and for my productivity. But, it is not easy to walk away! Takes me time and effort to do that.

This reads like a summary of Seth Godin’s The Dip.

Gee, have you been spying on me at work lately, or what? hehe

Only yesterday I found myself working on a programming puzzles purely for heroics. I had recognized the danger it posed to my schedule and tried to avoid it but after mulling over it with a friend I found myself crunching numbers and cranking code. Finally after three hours I started to realize how much time this was going to cost me for little or no gain and was able to drop it.

...and I still feel the need to pick it up and finish it.

Learning how to solve hard problems is almost always worth the effort.

Very, very good. Will be passing that note around the office :-D

Next 37signals hire: a copy editor.

@JF

Okay, I think I can understand what you’re getting at. I don’t completely agree but I can see what your point is.

So basically you’re saying to go after the “low-hanging fruit” in the beginning because those will provide the best return?

Reminds me of a certain war…

I think it’s based on the situation if you quit or not, but regrouping if you’re too far down a path makes great sense every time.

It really gets back to the relationship you have with a client.

If your relationship is strong you can pick up the phone and say “we were wrong in estimating this functionality.” The you can make a decision with the entire team (including the client) about what happens next.

My advice to you is: don’t start a startup.

Reminds me of a something Willie Randolph (manager of the NY Mets) once said:

“Of course you want to win, but you can’t manage every game like it’s the seventh game of the World Series.”

A dynamic not limited to software development. What fascinates me are the increasingly intangible benefits that are assumed to accrue to an organization by continuing down an otherwise dead end path.

Usually these wind up referring to some ill-defined “goodwill” or to a claim that finishing the project will somehow enhance your profile and make you more successful.

It’s when people start arguing that attempts to monetize the claimed benefits are “beside the point” that I usually conclude that the project is dead in the water.

David, I really enjoyed that post, thank you for writing it. It resonated with me regarding a lot of different things I am doing at the moment.

— Des

“But was it worth it?”

You left out the part where after 16 hours, you get it done and then decide to can the whole thing.

I know this sounds horribly inefficient but I’d do it anyway.

Nice article, Davis. Yes, you can get 4 other things done if you give it up. And in some cases it’s a good or even probably the only choice. But will you be satisfied with 4 cherries instead 1 apple that you need? It’s like you set up 4 base camps around the mountain, but you never rich the top of that mountain.

Yes, some complex feature will cost you a lot, but it will give you few valuable bonuses.

If your work is you passion, getting another complex problem done will bring you more enthusiasm and get your motivation high. In future, even if you will try to avoid some difficulty you will know: “I faced a problem a lot of others were afraid of. I solved it. I can do it! I will survive next time if trouble will come!”

Other thing solving complex problems gives you extra knowledge you hardly can find in a book. It gives you professional skills.

And yes, you feel yourself a hero – it’s the other great thing the challenge with trouble brings you. :)

Sometimes heros come back in a body bag.

Giving up is not good. Sorry. As an account exec at an agency that develops a fair number of sites, I have to tell you that few client relationships can stand up to the truth. When I get an estimate from our IT folks, I usually multiply by 5 and pray it doesn’t go over 10. I know what you’re thinking, but like others have said, there are so many occasions where you’re heading off into uncharted territory, estimating a process that takes months is incredibly difficult.

Because our name is on the product, we will do whatever it takes to deliver within our estimates and time frame. Sometimes it’s very painfull, but from the client’s point of view, it’s not their problem if we make promises we can’t deliver on. It’s up to us to refine our internal systems and not say “yeah…we can do that for you” everytime they ask for another design tweak, or feature. We call it simply doing the right thing. It’s not being a hero.

Looks more like a communications issue rather than a programming, policy or procedural malfunction.

This post really applies to my day to day work.

I figured out that my big problem was exactly what you’ve came up to : Here’s the problem: You agree that feature X can be done in two hours. But four hours into it, you’re still only a quarter of the way done.

Heroic estimates are easy to give when discussing with your boss or client about a project. Everybody wants to impress eh! But when you’re not done with a task that you said would be done a while ago, you definitely realize that you should have been more realistic.

I try to avoid such hassles by developing iteratively, with the first stage (and all subsequent stages) to aim for the minimal set of features necessary to do what I want the system to do.

When you do run into these problems that end up taking more time than you thought; I usually find one of two causes for it: either you don’t know enough or aren’t experienced enough to fully understand the problem at hand; or the estimate was far too low.

In either case; determining the value of what you’re working on is important and also requires experience. It takes a while for developers to become aware of determining value; this is where (hopefully) business/project managers come in handy.

Sometimes feature x is the core of the whole project; in which case, perhaps revisiting the problem domain may be an order.

I’ve done this “giving up” a few times. Most recently when fixing dozens of bugs in a project that was live and being used by a couple hundred students to register for workshops. I gave up on a lot of functionality for a few days that I thought would take just a few hours but ended up requiring two days of work and a total rewrite of much of my code. If I hadn’t moved on there would have been tons of bugs still imminent and I would have had even bigger problems in the end.