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!

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.

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 :)

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.