Everyone wants to be a hero. Techies especially so. And there are special occasions where true glory awaits the hero. When there’s a crisis, it can pay to just carry on no matter what. Get the problem solved and celebrate victory. Winning through shear effort.
But most days are not like that. Most features need not heroes. They need realists. People who are willing to give up and walk away. Being a hero is all about sitting aside all costs and winning anyway. That’s not a prudent way to drive everyday development.
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. The natural instinct is to think “but I can’t give up now, I’ve already spent four hours on this!”.
So you go into hero mode. Determined to make this work, but also embarrassed that it isn’t already so. So the hero grabs his hermit cape and isolates himself from feedback. “I really need to get this done, so I’ll turn off IM, Campfire, email, and more for now”. And some times that works. Throwing sheer effort at the problem to get it done.
But was it worth it? Probably not. The feature was deemed valuable at a cost of two hours, not sixteen. Sixteen hours of work could have gotten four other things done that individually were at least as important. And you had to cut the feedback loop to avoid feeling too much shame, which is never a good thing to do.
That’s where the concept of sunk cost gives us a guide on what to do. It doesn’t matter what you’ve already spent. That time and money is gone. It only matters whether spending what’s left is worth it or not. Business school 101, but one of the hardest lessons to internalize.
In other words, stop being so afraid of calling it quits. You’re playing to win the full season, not a single game. Every time you play the hero card, you’re jeopardizing the next game.
Heroics are for when you have no other choice. When you can afford to take on tremendous risk because there’s no alternative. That’s probably not today.
Daniel Higginbotham
on 20 Apr 07“the hero grabs his hermit cape” – oh man, that is great
Dennis
on 20 Apr 07This 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.
Kyle Pike
on 20 Apr 07My 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.
JF
on 20 Apr 07I can see the benefit as far as profit goes, but I don’t know if that philosophy would lead to consistent great work.
Long hours and 5x work vs. estimate does not lead to consistent great work. It leads to consistent late work which can lead to significant opportunity costs.
rick
on 20 Apr 07So what Highrise feature did we just miss out on? :)
Garth
on 20 Apr 07I 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. :)
Chris
on 20 Apr 07I 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?
Andrew
on 20 Apr 07So which feature has just been ruled out? :)
JF
on 20 Apr 07It is either something needed or it is not correct?
“Need” is a dangerous word.
There are multiple ways of implementing a feature. There are multiple implementations of the feature itself.
Version A of the feature may take 2 hours of work. Version B may take 16 hours of work. Version Ab may achieve 90% of the value of Version B in 1/4 the time. In most cases, Version Ab is the one to go with now.
There’s always time to make things better later if you later discover that the remaining 10% of the value is worth it. It’s just often not, at least not at the beginning.
In fact, you’ll learn a lot more about the remaining 10% by getting the 90% out to your customers now. There’s a good change the remaining 10% will be something else you didn’t consider.
Oliver Taylor
on 20 Apr 07This 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.
Jacob
on 20 Apr 07One 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.
Chris
on 20 Apr 07JF
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)
AkitaOnRails
on 20 Apr 07This 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.
Niket Patel
on 20 Apr 07“You’re playing to win the full season, not a single game.”
True, but I always forget when I really need to remember.
Christopher Hawkins
on 20 Apr 07Now, 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.
Even when it comes at the cost of doing your employer/project/client a disservice?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, REALLY in the software development business.
[/shameless blog-pimping]
Christopher Hawkins
on 20 Apr 07Gah, borked link.
Fixed link
Dr. Ernie
on 20 Apr 07Sounds like you’ve been reading (or should read) Seth Godin’s The Dip, about the power of positive quitting. :-)
marc duchesne
on 20 Apr 07Sounds familiar. Viva Open Source ;-) _Marc
Niek
on 20 Apr 07That’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.
Raymond Brigleb
on 20 Apr 07We call it “zero-based thinking” around here.
http://www.nightingale.com/paproductPower_Clarityaudio2641.asp
sandofsky
on 20 Apr 07Teams 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.
Sergio Bayona
on 20 Apr 07Ok, 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.
MI
on 20 Apr 07Sergio, would you be in much better shape if you routinely took a couple of days for what was originally budgeted as a 2 hour task? I know that kind of thing has happened to me plenty and I try to guard against it now. Sometimes it’s just a simple matter of moving on to something else for a while where you can get some quick wins and looking at your original task with fresh eyes.
In your case it probably makes sense to let your boss know when you get bogged down in something that wasn’t supposed to take long and let him make the call.
Chadly
on 20 Apr 07I’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!
matt
on 20 Apr 07“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.
Luca
on 20 Apr 07I 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.
Jim
on 20 Apr 07MI: 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.
Ahmad Alhashemi
on 20 Apr 07But 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.
MI
on 20 Apr 07Jim: It’s all about the relative value of what you’re working on now versus the value of what you could be working on if you weren’t bogged down in that task. Clearly, there are some tasks that are important enough to slog through no matter how far over budget time-wise you get. As I suggested to Sergio, in your case it would make sense for your programmer to come to you and let you know that the project you had them on was going to take significantly longer than initially planned, and let you decide where their efforts would be best spent.
As far as your 6 month integration project is concerned, we would probably break that up into smaller, more bite-size chunks so that we wouldn’t get bogged down for 6 months before showing any results. Not only does it get more immediate impact for our customers, it greatly reduces our exposure to sunk costs.
James
on 20 Apr 07I 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.
Ted Goas
on 20 Apr 07Sounds 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?
freaktopia
on 20 Apr 07good god people! don’t turn off campfire when you are four hours overdue on a project – turn that cr-p off /right now/...
Mortimer
on 20 Apr 07Kill your darlings. Next.
Divya
on 21 Apr 07I 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.
Michael Chui
on 21 Apr 07This reads like a summary of Seth Godin’s The Dip.
Seth Werkheiser
on 21 Apr 07Gee, have you been spying on me at work lately, or what? hehe
Daniel McLaren
on 21 Apr 07Only 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.
Rich Collins
on 21 Apr 07Learning how to solve hard problems is almost always worth the effort.
DHH
on 21 Apr 07Jim, I’m glad I don’t work for you, then. I would have been fired long ago. Despite needing this lesson for myself just recently, I’ve also executed it successfully lots of times. I’m the master quitter at 37signals.
And btw, if a feature is worth $50k, you’re all set. I’m talking about giving up on problems that were deemed to be worth x but turned out to cost 5x.
Re: The Dip, I’ve not read that but will definitely check it out.
Stephan Tual
on 21 Apr 07Very, very good. Will be passing that note around the office :-D
Anonymous Coward
on 21 Apr 07Next 37signals hire: a copy editor.
Dennis Eusebio
on 21 Apr 07@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?
JF
on 21 Apr 07So basically you’re saying to go after the “low-hanging fruit” in the beginning because those will provide the best return?
Correct. You’ll often find that the low hanging fruit is the tastiest for the development team and your customers. There can be an apple at the top of the tree too, but it’s often not worth the climb. Sometimes it is of course, so use your best judgement.
Chad Garrett
on 21 Apr 07Reminds me of a certain war…
Carl Smith
on 21 Apr 07I 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.
erdos2
on 21 Apr 07My advice to you is: don’t start a startup.
Rebort
on 21 Apr 07Reminds 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.”
Barry
on 22 Apr 07A 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.
Des Traynor
on 22 Apr 07David, 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
Leo Klein
on 23 Apr 07“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.
Eugene Sutula
on 23 Apr 07Nice 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. :)
Steve Roberts
on 24 Apr 07Sometimes 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.
Frédérick Dubois
on 26 Apr 07This 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.
j_king
on 26 Apr 07I 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.
j. andrew
on 27 Apr 07I’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.
This discussion is closed.