Getting Real: Release something today 23 Sep 2005

18 comments Latest by my site picks

The most important thing in software development is motivation. Motivation is local — if you aren’t motivated by what you are working on right now then chances are it’s not going to be anywhere near as good as it could be. In fact, it’s probably going to suck.

What kills motivation quick? Long, drawn out release cycles. Long release cycles insert too much time between celebrations, and quick wins that you can celebrate often are incredible motivators. When you kill the quick wins you kill the motivation. And that can kill your product.

So, if you’re in the middle of a 1, 2, 3 or more month release cycle, dedicate a day a week (or every two weeks) for some quick wins. Ask yourself “What can we do and release in 4 hours?” And then do it. It could be a new simple feature, or a small enhancement to an existing feature, or rewriting some help text to reduce the support burden, or removing some form fields that you really don’t need right now.

When you find those 4-hour quick wins you’ll find celebration. And with celebration comes motivation. And with motivation comes better products. And with better products come happier customers.

18 comments so far (Jump to latest)

Dan Boland 23 Sep 05

What kills motivation quick? Long, drawn out release cycles. Long release cycles insert too much time between celebrations, and quick wins that you can celebrate often are incredible motivators. When you kill the quick wins you kill the motivation. And that can kill your product.

This might be the truest thing you’ve ever said.

LB 23 Sep 05

Ask yourself “What can we do and release in 4 hours?” And then do it.

I can see your point about motivation, but I personally would still stick to the old saying ‘If it’s not broke, don’t fix it’

Anton Kovalyov 23 Sep 05

Is this from eXtreme Programming? I mean, the idea is from XP.

Eddie 23 Sep 05

You should “Quick win” and release today the capability to email in reminders to backpack.

:)

zack 23 Sep 05

3 or month release cycles. try a year! kill me!

JonathanW 23 Sep 05

Though the sudden appearance of authenticated feeds in Basecamp sure caught me by surprise!

Mark 23 Sep 05

You’ve just described our software development team where I work in my day job. Quick wins probably saved our hides after 911. The tricky part is where you make 40 or 50 of them and then have to support them with a small team. Any suggestions?

steven 23 Sep 05

This theory is sound, but easier said than done. After a few tries it is now working for us.

You cannot try this, you need to do this and do it quickly.

When we built our app we used basically all of the “workshop” advice.

However, when you are practicing “quick, half ideas and using small teams” for the first time, it is VERY important to (not) do the following;

Do not overplan the simplicity factor, make quick mistakes the same you would try to make “quick wins” and don’t be afraid of less-than-perfect releases.

We had the problem of trying to make plans to make things simple, which sort of kill the benefits of acting quickly.

Act quick, alter quick.

Sean Abrahams 23 Sep 05

What you’re basically describing here is producing reinforcers, which has been analyzed and described in detail by the works of B.F. Skinner and behaviorial psychology.

I suggest reading Skinner as Self-Manager.

I installed a motor and began to wire in the bulb when Fred suggested that we plug the device in the wall. ‘‘Why?’’ I asked, ‘‘It’s not finished yet.’’ ‘‘Well, to see it go, of course,’’ Fred replied, his eyes illuminated. In other words, let’s produce a reinforcer.

Chris 24 Sep 05

This is so true. It’s especially true when you have clients who keep asking “what’s happening?”, “when is this going to be ready”.

The “if it ain’t broke don’t fix it” adage doesn’t apply quite so much because these quick wins allow you to become intimately and frequently involved in the whole codebase, which often means that when new requests or bug reports come in, you can identify the solution more readily and optimally.

Arcanum XIII 24 Sep 05

It’s not because you work fast with a small team that you are working only on ONE thing all your live…
So if it’s not broken, don’t fix it can work here too : you just work on something else. Or you can do things better. Whatever you want :)

Rags 24 Sep 05

I think Jason, the author, got the gist completely right but stated a cause-effect relation that I do not agree with. But let us stick to the point I think is valid. The author calls for short software release cycles as opposed to long drawn out cycles. You probably will see the same stated in many ways in some of the software development methodologies like eXtreme Programming (XP), Spiral Model, Iterative development, [Read More] No Ads in my page by the way.

Mohit Maheshwari 24 Sep 05

The “quick wins ” do work as a motivation factor surely for the production team as well as the client . However in my experience of being involved in Outsourcing of New Media projects , I have seen these quick releases lead to a lot of client change request which may not be neccessarily part of scope of work when the project started. Also , some non involved clients may take a while before they understand the work is only haf baked and there is more yet to come .

It could lead to alarm signals sometimes in cases of non involved clients.

thanks
Mohit

Josh Poulson 25 Sep 05

Problem is that cycle times should really match customer expectations and not necessarily engineer expectations. Give customers new releases too often and they might think your product is buggy. You might miss the “glow” of a growing product adoption by confusing your customers.

My belief is that it is far more motivating to an engineer to go talk to someone that uses the product and have the engineer think of ways to meet what the customer expects and show his or her creativity by innovating: make something that delights the customer because it was not expected but it meets their need.

Long cycle times are a downer, unless there’s a good reason for them. If it takes a year to make a really critical feature, the engineers won’t hate it.

Rahul 25 Sep 05

Masturbation is the best quick win.

copongcopong 26 Sep 05

in a group or team project … bad code, no DRY principle, ton of rework would kill motivation

Don Wilson 27 Sep 05

You can’t suggest that throwing something together in an hour or two is a good thing, nor can you suggest that saying “If it ain’t broke don’t fix it” is a good response either. To be a good developer you have to learn how to balance yourself between the two and choose when it’s best to change, not set a sole path for all products.

Post a comment

(Basic HTML is allowed)

NOTE: We'd rather not moderate, but off-topic, blatantly inflammatory, or otherwise inappropriate or vapid comments may be removed. Repeat offenders will be banned from commenting. Let's add value. Thank you.