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.
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.
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.
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.
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).
I think it's all about context. If you are working on a single large project, it's reasonable to treat a concrete completion of a a part of that project as a "release".
For example, I'm working on recoding my mogade project. It'll take a couple months for the hour or two I spend on it a day. However, this week I managed to "release" the leaderboard component of it.
This is a particular method of training: like a kata. Obviously you aren't going to be able to build every sort of application in a week, but if you take it on as training, then your big applications will go faster too.
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).
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.
just because you're trying to improve doesn't mean you have to share your bad code with the world.
there's nothing wrong with writing code and trying to improve, but there's something to be said for being a good editor and not releasing every keystroke you type. why release that which isn't good or useful?
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.
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 :)
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.
