

The Don Stewart Method: write code every day, release a project every week - ionfish
http://www.shimweasel.com/2011/05/08/the-stewart-method-how-not-to-suck

======
rizumu
“Another flaw in the human character is that everybody wants to build and
nobody wants to do maintenance.” Kurt Vonnegut, Jr. quote

~~~
auxbuss
I love maintenance. But that's because I'm usually called in to build what
should have been built in the first place.

So perhaps it's better to say that I like to make things work. And to me,
working implies maintenance over time. Which itself implies that maintenance
is possible and viable.

------
unshift
disagree with releasing a project every week. what makes a project worth using
is continued maintenance, thorough tests, comprehensiveness, and battle-tested
API; not just a few snippets of code you uploaded somewhere on a sunday.

~~~
SingAlong
Co-incidentally, a few months back I took up this vow. My stats were bad. I
completed 2 small projects every month instead of 1 per week. But still the
motivation levels were higher to do something better the in next schedule.

IMO, the size of the project being small is the key.

Building bigger stuff may sound nice, but not everyone can spend time on
something for too long. It's not time as in hours or days. But time as in
motivation. For me long development times, without releasing prototypes would
be de-motivating. I love to show it off to people and hear them call it "cool"
or atleast "good idea, but not usable". So then when you have a prototype in a
week, you can make your next project as working towards v1.0 of the previous
week's project.

Disclaimer: The site is down, so I haven't read the post. I read the title and
the comments were interesting, which pushed me to post my experience.

~~~
gburt
Could you tell us more about your projects (to whatever level of detail you're
comfortable)? I'm interested in exactly what scope you were able to pull off,
and if any of them turned out profitable.

~~~
SingAlong
Thanks for asking. I have no problems talking about them.

All the opensource stuff listed here <http://akash.im/code> since Jan-2011,
were according to the 1-per-week rule and none of them commercial. The arduino
ruby gem was a little bit popular. When there's only 1 project in the month,
you can assume that I've been working as a remote intern or have been doing my
last freelance work :)

You can see that I clearly did not keep up with the 1-per-week expected
results. Like I said, it was 2 per month in the end, but I still practice it.
Along with it, since last month, I also make sure I read one-interesting-
paper-a-month (was the Amazon Dynamo paper last month).

Yet to work on something this month. This month, it'll mostly be a scheme
interpreter (R7RS-small spec draft#1) and a light-weight key-value store for
fun and then (possibly) get a job as a remote full-timer at some startup
(remote jobs are tough to get I guess).

Besides, what opensource stuff do you write? (just interested in stuff and
trying to make friends to collaborate).

------
geek_silk
cached version -
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://www.shimweasel.com/2011/05/08/the-
stewart-method-how-not-to-suck)

~~~
ecyrb
Somewhat related, Don's site: <http://donsbot.wordpress.com/>

------
6ren
_code every day_ : writers say "write every day"

 _reduce scope_ : similar to "release early, release often", "iterate", it's
always valuable to consider what is important and what is important (how can
you tell? that a feature exists is more important than some quality of that
existence: being easy-to-use, fast, efficient, correct for all cases,
flexible, general, reliable - all those things you care about!), how can you
perfect something before you know what's wrong with it? (e.g. maybe you
misunderstood the problem).

I think releasing often is harder for commercial projects (who would pay for
something incomplete? maybe they will if there's promise in the project, and
they are _really_ concerned about a problem it can solve: _the value of code
comes from user situations, not the code_ ). I should try this. What's the
worse that can happen? Nothing (i.e. it's ignored).

------
bryanp
This attitude is why so many open-source projects are shit. That said, the
habit of shipping often is a good one to have. But I think it's important to
follow through and deliver something of quality every time you ship.

~~~
neutronicus
In no way is Don Stewart responsible for anything being shit.

~~~
bryanp
I totally agree. My point is that misunderstood and/or misused this attitude
can lead to trouble.

------
ozziegooen
In the beginning validation is more important than maintenance. A one-week
project is kind of the equivalent of a developed Lean landing page; it's just
there to see if the idea will begin to stick.

------
mwotton
author here. so, this was an object lesson in not running every single one of
your services on a single ec2 micro instance. sorry about that.

~~~
latch
Don't know anything about typo, but an alternative to throwing more hardware
at it could be to optimize your site.

My story (redis/mongodb) peaked at the same time as yours, and my linode 1024
($40/m), which also houses about 7 different projects, didn't go past 5% cpu
usage.

Going with Disqus lets you outsource the only dynamic part of your blog post.
This lets you set a long cache header, or at least to serve it from cached
memory. Even if you don't outsource your comments, I bet caching the page for
2-3 minutes in memory would solve most of your problems.

Also, cache headers on your other assets wouldn't hurt. Nor would moving away
from Apache. Sounds like a good weekend project :)

~~~
mwotton
turns out i had typo configured to serve everything through rails, as well as
having 10 instances running. not a happy combination.

------
peterbotond
my way: write code everyday, and write at least one test case every week, and
release as needed.

release every week, problem: users are unable to learn and adjust, specially
humans, and of course the others' codes.

------
blhack
The site appears to be down hard :(.

What types of projects are you talking about releasing every week? I can't
imagine that they're terrible complex, are they?

------
rokhayakebe
The only problem with building too many things is you will not have the time
to give every project a chance to succeed.

~~~
pyrhho
I disagree. Having more released projects increases the chances that at least
_one_ of them will succeed, or at least start to show some promise.

Though, it probably depends on the kinds of projects. And assuming, of course,
that the quality is decent enough for a first iteration.

------
ddemchuk
I think a better variation of this method is to break down your big projects
into 1 week iterations for new features. It will feel like new projects each
week, you'll be adding value to a product rather than starting fresh each
week.

When you're not just hacking and instead trying to profit and run a business,
you need to be constantly improving and iterating.

