Late projects are late one day at a time - Signal vs. Noise (by 37signals)

Late projects are late one day at a time Jason 09 Aug 2006

55 comments Latest by Varun Mathur

“How does a project get to be a year behind schedule? One day at a time.” -Fred Brooks, software engineer and computer scientist

55 comments so far (Jump to latest)

Anonymous Coward 09 Aug 06

Speaking of late projects. When’s Sunrise coming out?

SH 09 Aug 06

Doesn’t a project need a deadline to be considered “late”?

JF 09 Aug 06

Mr. Coward, we don’t have release dates. It’s a great way to make sure things are never late.

We release things when they are ready to be released, not based a we-can-predict-the-future schedule.

Priorities shift, products change, new ideas bubble up, we discover new techniques and concepts, mistakes are made, external circumstances reveal themselves.

All those things make schedules a waste of time. They don’t account for surprises, new opportunities, gut feel, and human error. Schedules are too theoretical for our tastes.

The only time we start thinking about dates are when we’re really close to release. Then we can say “let’s try to get this out next Monday” or “Let’s do what we can over the next couple week and then go live with it.” Our schedules are relative.

Since we’re not that close to release we have nothing more to share at this time, sorry.

RailsBlob 09 Aug 06

Projects can be made late by using Javacs. Jason Freud and DDT are my hero. Rails make my projects earlier than when I started, so I am finished before I begin.

Relatively easy for a Haxcker!

Brandon 09 Aug 06

Not to shift topics again, but are you guys going to be bringing on any new talent to help with these new projects or are you planning on staying as small as you are now (for the near future, anyway)?

How many guys are you up to now?

JF 09 Aug 06

Brandon, we have 7 people and are thrilled with our team and team size at this time.

Scott Teger 09 Aug 06

Late projects are late one CHANGE at a time.

Clients seem to figure out the worst possible time in production to tell you they’ve been thinking about a feature change.

Good answer JF. Its done when its done… trick is telling a client that :)

Anonymous Coward 09 Aug 06

JF,

I thought that you guys like to brag about building apps in a 3 month time period. You’ve been talking about Sunrise since the beginning of the year, right?

Another Anonymous Coward 09 Aug 06

Great advice! I’ll tell that to my next real world client and see if they appreciate my straight-forward, shoot-from-the-hip style. Then, I’ll come by the 37sig office to bum some leftover donuts to feed my starving family! YAH!!!!

I’m sure if you have throngs of sycophant fan-boys waiting w/ hard-on’s for the next magical to-do list app, then you can be loose with the release date, but anybody that deals with clients for one-off custom projects pretty much has to live and die by the promised release date.

And if I’M a client paying for a service, you’d better believe that I want a completion date signed in stone up front. I’m not gonna let my own business flow get held up because “Schedules are too theoretical for (your) tastes”.

Michael 09 Aug 06

I hope people don’t take this to mean “never take a holiday or a weekend”. One day at a time….

JF 09 Aug 06

Mr. Coward, It usually takes us about 3-4 months to develop an app, yes, but you are thinking in terms of contiguous months on a calendar. We don’t think that way. We think in terms of total time.

We may spend a month here, take a few months off there to take care of some more pressing issues, work another month or so, do something else, etc.

We also tossed out most of what we did for Sunrise earlier in the year because we stumbled onto a significantly better way to design and build it. The initial version was too complex for our tastes. The newer, simpler direction is what we’re following now.

dave rau 09 Aug 06

More comments about comments:
If you’re complaining about 37 signals projects and timelines then you don’t have enough to do.

JF 09 Aug 06

Another Anonymous Coward, I wasn’t suggesting to you how to run your business, I was answering a question about how we run ours.

dave rau 09 Aug 06

Why are people so willing to be mean on the web? Why are people so willing to be mean to 37 Signals on their own web site? Just because you’re mean doesn’t mean your meaningful; ha.

Nathan 09 Aug 06

Another Anonymous Coward, They’re only one-off custom projects if you have an attitude like that. If your customers where happy with your work, like 37signals are, then maybe the idea of customers actually looking forward to your products wouldn’t be so alien to you. If you view every project as a one-off you’re not going to get repeat customers.

Tommy 09 Aug 06

Well I have a question for people here. I am an former ad agency suit that now works on the corporate site for a small software/content company. Our price point is high, very high (average customer $5,575/year, some $30,000 +).

Our tech department is given a deadline by management (insert the owner). They start work, and as Jason has said, other things come up. The three months they thought they’d have at 60 hours a week, is three months at 20 hours a week. No way on the earth they could hit the inital deadline.

But the launch date is never changed, and as the marketing dude I am told to start marketing the product. A date is given of course which everyone but the owner knows we’ll never hit (yes I push back).

The date is used and it isn’t ready and people get upset. Not pissed per say, cause these are usually pretty advance enhancements, not new features clients were expecting when they signed a contract (but that has happened as well), but disapointed none the less.

Then while we have clients asking about the last enhancement and when it will be ready (yeah, I got them interested) we’re off working on something else. And I am asked to promote something new to a group of people that are still waiting for the previous enhancement to work. That makes me job hard to say the least.

I can’t believe I am alone here … and yes, I know this is disfunctional at so many levels I don’t know where to start.

Nathan 09 Aug 06

If youe development team is operating at 1/3 of its estimated capacity, something is wrong there. Project management should be filtering the incoming work for the team. If work is building up on the developers plates that was not factored in during the original estimate, of course its going to go over the estimate. Its a constant tradeoff between taking on new work and meeting the short-term deadlines. I know the ‘Getting Real’ thing to do would be to Flex the scope and keep the launch date fixed, but that doesn’t work if there is agreed upon functionality that cannot be completed in time. My suggestion would be to either start doing more detailed estimates to see where you’re going over.

Nathan 09 Aug 06

… or to hire developers who are willing to work a ton of overtime to meet deadliens, just make sure they’re compensated afterwards!

Tommy 09 Aug 06

Nathan, were those responses related to my post?

JF 09 Aug 06

I know the �Getting Real� thing to do would be to Flex the scope and keep the launch date fixed, but that doesn�t work if there is agreed upon functionality that cannot be completed in time.

That’s why we don’t advocate specs or “agreed upon functionality.” That’s the root of the problem — saying you know everything about what you need and how its going to be implemented even before the first pixel is painted or line of code is written.

When you predict a rigid future on a flexible present you’re in trouble. Rigid futures are among the most dangerous things. They don’t leave room for discovery, emergence, and mistakes that open new doors.

Anyhow, I’m not going to repeat myself: It’s all in the book.

Patrick 09 Aug 06

I see it as a difference between the Web 2.0 products and the rest of us. With Web 2.0 it is a “take it or leave it” application and so they can afford not to have release dates and release only when ready to present the highest quality and shine. No one is imposing a “drop dead” deadline on 37 Signals that I can tell.

Stephen 09 Aug 06

Nathan,

I have yet to meet a developer that worked well with tons of overtime. Developers will work all hours of the day, but when they are just working on one project, they get burnt out. I say work less and work quality.

another steve 09 Aug 06

I think this is again a case where if you’re working on your own projects and have money floating down on you, you can flex things and not set deadlines. But if you’ve got clients paying you and you need to make money next month, there’s no way you can not agree on functionality and timelines. If you can, you’ve got some pretty understanding clients.

JF 09 Aug 06

Another Steve, before we stopped doing client work this is exactly how we were working with clients. It’s is absolutely 100% possible. We sold flexibility and they ate it up. They knew there was a better way. They’d know for years that rigidity had lead them down the path of mediocrity and frustration BUT no one had presented them with an alternative. Flexibility is golden if you know how to sell it.

To those that think there’s only one way to do anything: you’re off by a factor of 100. There are lots of ways to do things, but you have to believe in them and yourself enough to try them. You have to educate people, you have to ask people to trust you, you have to trust them, and you have to deliver. And I promise you that once you start delivering they’ll forget all about the old way of doing things.

We’ve done it and you can do it too. Don’t let anyone tell you you can’t. Don’t let anyone tell you there’s only one way. Don’t let anyone tell you rigid timelines and specs are the only way to work with clients. It’s simply not true. It may be what people are used to, but there are much better ways if you just give them a try.

Michal Migurski 09 Aug 06

The book that quote is from, “The Mythical Man Month”, is total genius. I just finished my copy, after it sat on my Amazon list for 2 or 3 years too long. It’s fascinating how much of it is still current, even though he’s talking about programming methods barely two steps removed from punch cards. The essays throw a great historical light on agile programming, too: he doesn’t use the term, but the ideas were all there 30 years ago.

I especially like Brooks’ distinction between programs and systems, and their varying relationship to maintenance cost: “Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”

Or, as Brooks quotes C.S. Lewis: “That is the key to history. Terrific energy is expended—civilizations are built up—excellent institutions devised; but each time something goes wrong. Some fatal flaw always brings the selfish and cruel people to the top, and then it all slides back into misery and ruin.”

Aaron Kassover 09 Aug 06

A different approach of working with your clients requires a different approach of selling. If your clients are requiring you to draw up lots of detailed specs and make all kinds of promises about what you�ll deliver when before anyone even knows the details of what it�s going to take to get youthere, it�s up to you to educate them to a better way. Sell them on your approach and your skillsets. Discuss the challenges the problem will face and detail out how your approach is better suited to overcoming these challenges. If you need to, give them examples of how this has worked well in the past.

Whatever you do, don�t give away design in the sales process! I�ve seen it happen way too often where firms rush a quick design concept, spec document, or site map to try to give their prospective client a concrete idea of what they�ll get. Remember, if you�re a services firm, you should be selling your services and not some end deliverable.

Aaron Blohowiak 09 Aug 06

are these idiggiots or what? so much flame for such a simple quote. It is true that projects get late one day at a time. So do bills, anniversary presents, birthday cards, mentrual cycles, &c.

z 09 Aug 06

speaking of the getreal book. any plans on printing it?

i’ve the pdf copy, but wouldnt mind geting a paper copy as well. its easier to read this way.

sorry for offtopic.

mike toreno 09 Aug 06

to jason fried: have you ever heard the term “exploratory programming”? it refers to the idea of developing software software in order to learn more about the problem and to resolve ambiguity about what the final product should include. it’s an idea that stems from Lisp/AI programming.

the best way to make a simple but powerful user interface to a project management/bug tracking/CRM/whatever web app is likely not a priori clear. software product development is to me an organic process where you ought to be able to change your mind about things.

that’s what you kind of seem to be getting at here.

and don’t worry about the haters.

JF 09 Aug 06

Mike, I don’t worry about the haters, believe me. It’s fun to play with them every once in a while, but they stopped getting under my skin a few yeas ago.

Nathaniel 09 Aug 06

A saying that got thrown around the large Government contracting organization I worked for:

You’ve got time, scope, and budget. Choose two.

And guessing by a Google search for “time scope budget” and the 55.7M hits, I’m guessing we weren’t alone in that conclusion. Interestingly, the top hit is 37signals SVN.

Kenny 10 Aug 06

Why do so many people read SvN just to say bad stuff about 37s?

There must be better ways to spend your time.

How about getting your project done be deadline?

James Head 10 Aug 06

To answer your question about why people read to say bad stuff, - it’s simply a symptom of success.

People look at (and look up to) 37signals’ success. The look for guidance and wisdom for how they can bring that success in to their own products and projects. Unfortunatly it does not always translate. 37signals has a philosophy that works for them, with their style of product. But as a few people have posted already, it’s not applicable to some real world situations.

I look at 37signals and am envious of their ‘web 2.0 rock star’ lifestyles, - but it’s simply not applicable for 90% of people’s real world daily churn lives. Jason then sometimes makes a seemingly flippant one line post, - and the hordes come in abusing and trolling because it doesn’t fit and it’s not a real solution. They offer a style of development that a certain type of application can benefit from, - but it’s not a total solution for all.

All in all, - I suspect Jason loves it.

Does apple have a little disclaimer on all their computers “this machine might not be the best choice for everyone in all situations”? No. But they also don’t have open comments on a blog at apple.com

right. i need a coffee.

Jen 10 Aug 06

Because 37 said F*&^% to BusinessWeek but at the same time, proudly says in the frontpage “Basecamp - Business Week Best of The Web 2005” and “Backpack - Business Week Best of The Web 2005”.

Anonymous Coward 10 Aug 06

Tommy, I’d like to recommend to you the book “behind closed doors” from pragmatic programmers. It adresses your issues in a very simple and straight forward way.

http://www.pragmaticprogrammer.com/titles/rdbcd/index.html

The Troll Again 10 Aug 06

Why do people are eager to attack 37sigs? Because they (especially Jason) can come off as pretentious a-holes sometimes. I don’t hate their success, and I think they’re incredibly smart. I would love to have the ability/talent to be able to sell a product to the people MAKING the websites, instead of just trying to sell the same website to different clients. However, if 99% of your audience is the average-joe web developer, coming out with a post which basically brags about your ability to shuck deadlines is bound to get you some flame.

Think about it; WE are 37signals’ customers. Those of use who buy the books and have Backpack and Basecamp plans. We’re the client, and Jason is right here telling us that they’ll get that next new product launched whenever the f*** they get around to it.

Now yes, I know that I don’t HAVE to buy their stuff of course, but the whole thing smacks of arrogance. 37signals knows that they have a captive audience of web developers ready to snap up their new products and they seem to have become a little more arrogant because of it. That’s all I’m saying.

Ryan Heneise 10 Aug 06

I suspect that what Jason is talking about has a lot to do with setting expectations. We are not (yet) a hugely successful firm, but then again, we’re not that old yet either. But I think so far we’ve done a good job in helping each of our clients (and ourselves) to have the right expectations. We typically define a “roadmap” that fairly loosely (at least compared to a functional spec) defines where we’d like to end up with a project. Sometimes we also define dates, but we don’t judge the success or failure of the project by whether or not we reach a deadline. We’re more interested in the end product, and our clients appreciate that.

JF 10 Aug 06

We�re the client, and Jason is right here telling us that they�ll get that next new product launched whenever the f*** they get around to it.

I don’t know which post you’re reading, but it sounds like it’s the one in your head not my actual words above. I said we release our products “when they’re ready,” not “whenever the fuck we get around to it.” You’re inserting the “fuck” and the attitude.

“When they’re ready” means when we think they’re great enough for our customers. We don’t want to release something we’re not happy with because if we aren’t happy with it our customers won’t be happy with it. We want to release things that are valuable, useful, and polished. A release date/schedule has nothing to do with those things. Releasing the product when it’s ready has everything to do with those things.

but the whole thing smacks of arrogance.

Yes, your comment does smack of arrogance. It’s full of attitude, twisted expectations, entitlement, and alternate realities.

Anonymous Coward 10 Aug 06

The Troll Again, go away already. You’re negativity is out of control and misguided. You are making up words and then attacking them as if Jason said them. You are making up attitude and then attacking it as if Jason has it. Your bitterness and jealously is getting in the way of your reason.

37signals doesn’t owe you anything outside of the products you pay for. Just because you pay for Basecamp or Backpack doesnt mean they owe you Sunrise or any future product. Paying for the book doesnt mean they have to release products on YOUR schedule.

Get over your anger and come back when you have something productive to say.

Rahoul Baruah 10 Aug 06

To Kenny:

I disagree. The vast majority of comments here are “fan-boy” comments - the ones that aren’t are shouted down faster than someone saying “I love Windows ME on slashdot”.

How many comments on this thread disagree with 37s? How many are marked as troll?

Personally, I think that 37s have managed to position themselves somewhere where the process they use means that deadlines aren’t important. I can even see how that can work with custom projects for one-off clients - but you need to select the “right”clients for it. Not everyone has the luxury of selecting their clients.

If someone comes up to me and says here is X thousand pounds to write a system - but it needs to be finished in N weeks because “that is our year-end”, or “that is when our new factory comes online” (or whatever) then I’m currently in a position where I have to take the job - if I think I can complete in time. Which means that the deadline and my estimating skills are vital.

Luckily, I seem to be better at estimating than most.

JF 10 Aug 06

We mark people as trolls not because they disagree (we’re happy to have a healthy, meaningful debate), but when they anonymously spray the comments with obscenities, vapid comments purely intended to light a match, or personal attacks that don’t add any true value to the discussion. Those comments don’t benefit anyone and aren’t welcome here.

This is our house. If you don’t like our rules don’t come in. When I’m in your house I live by your rules. When you’re in our house you live by ours.

It you wouldn’t say the same thing to someone face-to-face then don’t say it here. Comments aren’t excuses to be disrespectful or mean. If you have a point to make, make it maturely. Otherwise please don’t bother.

dreed 10 Aug 06

37s being in the hosted application market affords them the right to release new products and new versions of current products whenever they want, and to Jason’s comment, the “right” time is when the product is “right”. Those of you in the installed product market don’t necessarily have that luxary, at least with new feature releases. Chances are your customers are paying a yearly maintenance amount over and above the license cost of the software, and as such they will tend to demand a feature release now and again. I think that is just the way it is, but would love anyone’s advice on how to get the same flexability with an site installed product base.

Des Traynor 10 Aug 06

This page confuses me.

1) Why the fuck did everyone lose the plot because JF posted a quote by Brooks? It’s a reasonably well known quote. Why does everyone decide “Oh Goody, lets get some fighting going on”

2) What is so meaningful about that quote? I’ve read it many times in many places, and it seems to be the default meaningless end to a conversation about schedules.

Projects go over budget, one dollar at a time

Software gets buggy, one bug at a time

Software gets bloated, one feature at a time

James 10 Aug 06

You can eat a whale. One bite at a time.

Bob 10 Aug 06

Is there anyone here that has worked on a large project that actually ended up being completley finished (as it was originally planned) in good time before the deadline??

I’ve worked on many software projects, all of which require teams of 20 - 100 people and which last at least 6 months. Every time, without fail, the run up to the deadline is a manic, stressful, unpleasant experience and most people are very happy to see the back of it once it’s finally sapped the life out of us. It’s not one manager that’s causing this or any working processes, ive worked with tons of different teams and their varying working practices but it’s always the same.

There must be another way!

I appreciate the idea of releasing things when they’re ready, it’s a good thing that you guys are doing but that doesnt apply in my business where we sell our products in the shops, we have deadlines such as Christmas which we cant move.

Someone must have worked on a project that finished in good time before the deadline???

sammy 10 Aug 06

A couple of responses to comments earlier in the thread.

Aaron Kassover: Whatever you do, don�t give away design in the sales process! I�ve seen it happen way too often where firms rush a quick design concept, spec document, or site map to try to give their prospective client a concrete idea of what they�ll get.

Oh Lord, yes. Preach it. I’ve seen companies… hell, I’m watching a company go under right now (not my company), whose modus operandi was “take the version of this system that we built for client X, actually install it for client Y, then make changes to it until they feel like it’s worth paying for.” Of course, since they’re getting the use of the software plus customization for free, their incentive to “accept” it as a semi-final product is precisely nil. It’s a rule I learned from my father years ago - if you don’t put a value on what it is you’re selling, your clients won’t either.

Des Traynor: What is so meaningful about that quote? I�ve read it many times in many places, and it seems to be the default meaningless end to a conversation about schedules.

It’s basically a reminder. I’ve seen a lot of management bloviating about what drives projects to go over schedule or over budget, and they always seem to be focused on finding the “root cause.” It’s a neurosis: “Hey, now that we’ve systematically identified every tree in this contiguous area, I propose calling it a “forest”. All in favor?”

Not seeing the forest for the trees is a problem. But failing to see the trees because you feel like you’re missing something unless you tackle Everything As A Whole is a problem too.

lisa 10 Aug 06

Seriously, trolls. Be a man (or woman). If you have a controversial request or comment, at least have the balls to sign your name. I think the lot of us would be more receptive if you weren’t hiding behind an anonymous moniker.

Ryan Schroeder 10 Aug 06

This is a great post! I love how it started has one little quote but we really got some good stuff in Jason’s comments. Speaking of which, Jason are you (or possibily a clone) available to come in and run the company I’m currently contracting with? We’ve got a date driven deadline that can’t be moved and the features and changes are starting to pile up! They need a dose of Getting Real!

Jeff - a coworker of the troll 11 Aug 06

This is what happens when I take one little day off.

I work with the troll - the troll says he’s sorry, and was having a horrible day yesterday, for what that’s worth (not much).

I think we might share an outgoing IP, so we’ll see if this gets posted.

So, anyway, nice weather we’re having, eh? See that sky this morning? Talk about blue.

Duane McCollum 12 Aug 06

I am in the middle of project planning right now. I scanned several of these comments and derived some axioms from them:

1) Don�t give away design in the sales process (Statement of Work, either) .
2) Not seeing the forest for the trees is a problem. But failing to see the trees because we feel like we’re missing something unless we tackle Everything As A Whole is a problem too.
3). Expensive projects (or work statements) always look better on paper
4) The design/work statement stated up front, and subsequently estimated and commited to, is not what actually gets built —or more rightly what should be built.
5) Apply the “bite-off-only-as-much-as-you-can-chew-one-step-at-a-time” principle.
6) Get feedback from the client and agree on what you�ll deliver in short review cycles (based on feedback from what was delivered). I�s a lot less risky for all parties involved.
7) We don�t have all the answers —-but we can try work out most as we go.
8) We’ve got time, scope, and budget. Choose two.

Mark 13 Aug 06

The troll said he’s sorry? This must be Internet History!

Matthew Stibbe (Bad Language) 14 Aug 06

Amazing that a quote (albeit a good one) can generate a zillion comments and trigger a conversation, trolling aside, that illuminates an important point.

Anyhow, back in the days when I ran a computer games company we had a saying “you can have any two of fast, cheap or good.” Another quote I remember fondly is “there are three secrets that guarantee timely software development, but nobody knows what they are.”

Katie 14 Aug 06

> Anyhow, back in the days when I ran a computer games company we had a saying �you can have any two of fast, cheap or good.�

I hope this isn’t inappropriate or vapid, but I first remember seeing this expression in the late 1960’s on a dusty placard in the garage where my parents took our car to be serviced, up on the wall with the jokes about trading your wife for a fishing boat. It’s also a common expression in the construction and engineering worlds. Just a reminder from an IT geezer that the IT industry didn’t invent the concept of deadlines.

In fact, we can go back to medieval times to find examples of clients (e.g., the Catholic church) hiring the great architects of the day to design and build cathedrals on their own schedules with no fixed deadlines. Of course, their timeframes were measured in decades or centuries, as opposed to the quarters we deal with nowadays. I’m sure the serfs got pinged on their annual reviews if they didn’t meet their deadlines, though.

Moving on to the Renaissance, here’s what Michelangelo had to say about deadlines:

“I cannot live under pressures from patrons, let alone paint.”

Here’s an extract from an online bio of Michelangelo. Can anyone relate?

“His next ambitious project was the sculpture of David, more than 12 feet high, in 1504. Now his fame grew and he took on far more work than he could actually complete. This frustrated and saddened him as he expected perfection from himself in his work. He became increasingly absorbed in his work and took little care of his appearance. He even had trouble keeping servants because of the squalor in which he lived. He slept in his clothes and barely took time to eat, satisfying his hunger with a piece of bread.”

Katie
Eagerly awaiting Sunrise

Varun Mathur 14 Aug 06

Jason,

Your first comment to the AC was awesome ! It more than made up for the almost non-existent blog post.

Thanks for the wisdom,

Varun