Why big version trains are always late - Signal vs. Noise (by 37signals)

Why big version trains are always late David 15 Aug 2006

33 comments Latest by Harry Nieboer

There are many reasons why you shouldn’t smack version numbers on web applications, but the most important is to avoid a feature creep detour.

When people hear “version 2.0”, they think it’s the last call for the only feature train in a good long while. If you miss it, you’ll have to wait for the big three-oh to board. Nobody likes waiting, so they rush and they push to make this one.

Now the big version that started out with a clear vision, one or a few great ideas, suddenly gets bogged down by feature freeloaders. When the 2.0 train is already hauling those heavy weights, surely no one will notice this little thing or that little thing.

And what could have arrived in weeks turns into months. In no time short, your feature train is so overloaded that it seems like its not moving at all. Or going backwards. Certainly there is no one who can tell you when it’ll pull in.

So stop it. Don’t alias your next big feature idea “version 2.0”. Call your big idea by its name and it’ll be much easier to spot the freeloaders. Once they have to pay full scheduling fare, you’ll probably realize that they weren’t that important anyway.

That’s why we’re calling the next major revision of Backpack the “Widget Overhaul” and not Backpack 2. And that’s why we’re calling the one after that “Backpack Business” and not Backpack 3.

33 comments so far (Jump to latest)

STe 15 Aug 06

I don�t get the whole business of giving applications numbers or names.

You can tell people about the changes, you don�t need to give it name or a number.

Why not just leave it at Backpack?

DHH 15 Aug 06

Backpack isn’t changing its name. “Widget Overhaul” and “Backpack Business” are internal feature names. This post is saying that even internal version names are to be considered harmful.

STe 16 Aug 06

Agreed

David,

Do you not apply this mind set to Rails?

What version are we on, now?

Version 2.0 is getting closer, is it not?

I’m aware of the web application note above.

My attempt at a joke.

I never was very funny.

Jamis 16 Aug 06

STe, the post is about web apps, not frameworks. For things like frameworks, version numbers are good, because they allow developers to talk about and compare specific releases. For a web application, there’s no real need for a handle like that.

Michael Ward 16 Aug 06

You need to know what version of a framework you’re running - what features are available, what bugs are present, what does it play nic with, do I have the latest security patch. All good arguments for a version number.

However, a web app, of which there is only one instance, does not need a version number - you’re always running the latest version. You know that and the developers know that, no version numbers needed.

Matt Lee 16 Aug 06

What about a web app that isn’t hosted in the style of Basecamp and co? Like $GENERIC_PHP_FORUM or Wordpress? Surely we need to know version numbers for those, to keep up to date with patches and such?

Joe Ruby 16 Aug 06

Widget Overhaul? Nah…Widget Fidget. ;P

Matt: If you are distributing software then version numbers matter, if you aren’t then they don’t.

Of course, it doesn’t mean we need to use big version numbers for distributed software - but marketers like them.

Rob Grady 16 Aug 06

While every company and team may be different but for those of us managing website product roadmaps, working with extended teams, and doing weekly maintenance releases, a numbered system can be a great option. In my world, I agree that going from 1.0 to 2.0 is too big and will have everyone trying to get their features (product requests) in that release which potentially causes feature creep and ultimately schedule slip. I manage it through smaller buckets and actually having the framework provides a process and guidelines to classify requests and get them actionable. For those requests not prioritized and assigned to the Roadmap, they go in the parking lot for periodic review by the product and executive team.

2.0 : Major Release
2.1 : Point Release
2.11 : Maintenance Release
Parking Lot: Feature Requests not prioritized or assigned to a release

Thijs van der Vossen 16 Aug 06

I’m with Peter, let’s bring back the development blog! :-)

Scott Annan 16 Aug 06

Would a rose by any other name smell as sweet?

Call a grouping of enhancements, bug fixes, improvements, add-ons whatever you want, and use whatever naming convention helps you (or your users) understand the process.

What I think is important ultimately is that webapps (all apps) continue to evolve and don’t suffer from mega-release scope creep. I agree with David and have followed Rob Grady’s process almost to a tee (hence the development of our software) and what I have learned is to keep moving it forward.

And if you choose to move forward, but not to name each group of improvements, I think the application should smell just as sweet.

Aditya 16 Aug 06

From a marketing point of view

tony makes THE WEB APP
john uses it for 20$ per month

tony adds 10 new features, he calls them features and nuthing but that

john says nice i get more features

tony says ill have to charge 23$ to keep improvising

john says wtf for some silly features?

tony adds 5 new features and tells john we are moving to version 2.0 please update plan for best results

john pays happily

perception is important

Ross Patterson 16 Aug 06

Software version numbering is critical. Think it isn’t? Try living without your Subversion or CVS revision numbers for six months. Version numbering gives your community a common frame of reference and enables them to discuss the evolution of the software over a period of time.

“Version 2.0-itis” is a completely different problem. It’s been made worse by O’Reilly’s silly “Web 2.0” thing, but it’s been with us for a long time, almost as long as people have been writing programs. Fred Brooks wrote about it in The Mythical Man Month, where he called it the “second system effect”. The only reason people treat 2.0 as the “last release” is because you let them do so. It’s bad project management, and if you let it happen you’re just a grunt coder, not a software engineer. Anyone can write programs, but building highly functional reliable software systems takes more than just l33t c0d3 skillz.

DHH 16 Aug 06

Ross, the sequential numbering scheme of Subversion and CVS merely tracks the number of checkins. It doesn’t have anything to do with the concept of artificially constructed versions as discussed here.

None of our applications have used public version numbers and that doesn’t seem to have hurt the community by not supplying a common reference. The common reference is the software that’s available to everyone now and the individual features as they are released.

Again, this naturally only applies to hosted web applications. That’s what we’re talking about here. Frameworks, desktop apps, etc all need version numbers because upgrades are voluntary, distribution is cumbersome, and everyone won’t be running the same version at the same time.

In any case, this is a charge against using version numbers internally for web applications. The Getting Real book features an argument for why you shouldn’t use them externally either, but that’s a slightly different one.

> Of course, 37signals has called it Basecamp 2 internally for some time ;-)

Peter, we called it Basecamp 2 for a short time. Consider it a lesson learned. That experience was one of the seeds that germinated into this post.

Alexander 16 Aug 06

This seems to be the same principle as using personas when designing software. The idea being that by giving something a meaningful name, rather than a generic label, it is easier to relate to and see what *shouldn’t* be included.

Rami Kayyali 16 Aug 06

Actually, in the world of Web applications, the scenario goes something like this:

- Tony makes the web app.
- John uses it for $20/month.
- Tony adds 10 more features, calls them features and nothing else.
- John says nice, and tells Jane about them.
- Jane starts using Tony’s web app.
- Tony now gets $40/month instead of charging John $23/month.

Of course perception is important, but it doesn’t work with people the way it does with corporates. Big wigs love version bumps. We, on the other hand, don’t.

CJ 16 Aug 06

Just out of curiosity, and I don’t mean to hijack the thread, why the need to call the same ole web, Web 2.o. Is it just a way for the younger guys and gals getting into the biz to feel like they are making some headway with the same tools we’ve been using for the past ten years? The web is getting to be a pretty “long train” without needing to add a Web 2.o designation.

cvfoss 16 Aug 06

Absolutely brilliant post. I can think of plenty of examples of software that had big plans for v2.0 and either had to delay a product because they couldn’t add all the features by the release date or drop a lot of the significant features that made it v2.0 (i.e., Firefox).

matt m 16 Aug 06

For APIs, version numbers are essential for dependency management. For Web APIs, being able to specify the version in the request allows for smoother transitions.

Doug Whitehead 16 Aug 06

So, what new “Widget Overhauls” can we expect to see in Backpack 2?

random8r 16 Aug 06

Ah… zen koan of the day.

“When is version 2.0 not version 2.0?” :-)

By calling Backpack 2.0 NOT Backpack 2.0, you’ve still called it Backpack 2.0. Annoying isn’t it? Trying to change away from something?

I’ve been thinking a lot about death lately. What is death? Death is change, right? It’s BIG change. Probably the biggest change we have as humans. Yet we can’t cope with it. It’s too big.

Just like your version 2.0 or 3.0. You’re trying to get away from it, because it has with it all kinds of association and trauma. You’ve got to mourn your versions in a way, because they’re so big.

We need small. Why? Beause if we make death and change and process the same thing as this moment, moment to moment, we realise there’s no end. Death is simply unknown.

You can’t know the unknown. We try to “know” death by calling it death. In the same way, you’re still calling your version by “SOMETHING”. But what you really want to do is let people know of continual improvement. Little changes.

The trouble with (Western?) humans, is that we nominalize everything. We make everything a THING. We talk about Death, and Versions, and Breaking Up, and the In breath, and the Out breath.

That’s fine to do, so long as we realise that AT THE SAME TIME, IT’S CONTINUAL PROCESS. There is no such thing as a POINT, once you realise a line sits beneath it, and that there’s a plane sitting behind that line, and a solid sitting behind that line, and so on…

We need this realisation, because then life is a smooth-form ride, and there are no bumps. Things happen “to an unseen rule” and that rule is flow.

So I ask you, David, why are we still on the “version” bandwagon? Why aren’t we on the “feature” bandwagon? I think this is probably what you’re trying to get across in your post.

But for that matter, why are we still on the “feature” bandwagon? Why aren’t we on the “change” bandwagon? :-)

And then, the question arises… If you’ve built a very clean nice tool, why does it need to change at all?

Is it not better to create a very good hammer, and then create a very good saw, than to create a saw-hammer that will fit lots of needs?

We need SIMPLER tools which work VERY well together, not more complicated ones. Because then if our hammer breaks, we can use another one we happen to have. We don’t keep all our eggs in one basket.

The number of clients I have whose Entourage dies, and then all their email is unrecoverable is GREAT. Why? Entourage on Mac stores ALL the email in one single file. Terrible for data corruption, email corruption, or even just plain old backing it up.

Apple Mail, on the other hand, stores all its mail in .mbox style folders, which have each email in a separate file.

This not only means I can go in low-level and remove corrupt emails that become a problem, but things won’t stuff up as easily.

So, you’ve built a good hammers, and a nice saw. You have our attention because of it.

Now you have our attention, I hope you’re building more “different tools” rather than a “big fat tool”. We want to hear about how you’re building other cooler hammers which can be used directly instead of the first hammer you built, and other saws, and other tools which we haven’t imagined yet, and how they change our lives, and help us in the day to day tasks we do.

Sure, make Backpack a “big name” which fits across several different “little apps”, and make them work nicely together, and even give us alternatives for the “little apps”. But don’t build us an Entourage. That’d be sad!

Thanks. Daily, I appreciate that you’ve spearheaded by starting down the Rails framework. Daily I appreciate all the code that exists because we have this thing available to us.

Much respect!

It’s kinda funny that one of the ads via the deck is for Dreamweaver 8.

That’s not very agile. An ad for Textmate: now that I’d like to see!

It’s even funnier than when you click through that logo, you get a link which has “cfusion” in it… I’m guessing that’s a reference to cold fusion. But cfusion = confusion in my books ;-)

Anyway. Talk it up talkers! :)

Mrad 16 Aug 06

Good point David. I’ve been fighting the “feature train” for awhile at my company, but it hasn’t been from external folks - it’s been from the stakeholders and other developers within the company. There’s always the “this would be a great additon” and “wouldn’t it be nice if it did this” that get tacked onto a list for the next version. It all results in us falling short of our expectations for our products.

But I really like the idea of naming a version after it’s enhancements. Good call.

Keeran 17 Aug 06

Hi guys,

Given that 37S and Getting Real appear to follow the mantra of “give them value and they will pay for it”, do you find any difficulty in balancing value with revenue potential? I.E. do you arrive at a scenario where you have to decide if a feature becomes extra value to the existing customer or something that should be put into a new plan?

I only ask because I think you produce products which are bang on for their cost, and because of the nature of Getting Real and Less is More, I would hope that if you were to produce more features they would be worth paying for…if you see what I mean?

Cheers,

Keeran

Nathan Bowers 17 Aug 06

Agreed. If you publish a web app your users don’t care and don’t need to know any version numbers.

Of course you should have your own internal version numbers. For example, we do an svn branch with names like RC1.2 for every release candidate.

DHH 18 Aug 06

Nathan, this article is about internal version numbers and the statement that they’re a bad idea. External version numbers are _also_ a bad idea, but for different reasons.

Mathew Patterson 18 Aug 06

I don’t think it is clear from the article that this is about internal version numbers. Certainly it reads differently to me now that I know that.