My early New Year's resolution is to ship more next year (why wait for next year to start?). With this in mind, I decided to write about increasing productivity in web app development (more posts coming!). In this first part, I will look at the principles behind getting more done quicker. In the next parts, I will look into the points marked with ** in more detail.

Based on a look at the top 400 or so questions tagged "productivity" on Stackoverflow, the five principles of web application development productivity are:

1. Know your tools

Learn all you can about your particular language, framework and tools. Doh!

Explore other people's solutions to your problems and learn best practices.

Use version control; diff tools, project/bug/feature tracking; virtual machines; VPS/platform-as-a-service providers when needed.

2. Define your problem well

Get obsessed about your project: think about specifications, UI and implementation mechanisms when you're not coding. **

Don't get bogged down on details, and try to identify the most valuable parts of the project. Don't get too "clever" about features; gold-plating carries an opportunity cost.

If you use something more than three times, make it reusable and think about how future features will influence the architecture.

Invest time in creating tools for recurring and error-prone parts of your project.

3. Keep yourself and your team on track

Eliminate distractions; communicate frequently enough but keep it brief.

Stick to a MVP; avoid scope creep.

Have a detailed to-do list. Keep to-dos small and specific enough that you can tick them off. If you can't determine whether the task is done, then refactor the description until it is unambiguous and small enough. Finish one task at a time.

Time-box your iterations and tasks (e.g. Pomodoro technique): set deadlines and create pressure by making a commitment (e.g. tell someone).

"Accept that everything is a draft. It helps to get it done. Laugh at perfection. It's boring and keeps you from being done."

"The point of being done is not to finish but to get other things done." In other words, get the first version done and then move on to the next most important thing. Get back to it if feedback indicates it's important.

Try to keep any projects/project iterations to less than a week long, so that your ideas about how it should work won't start diverging wildly from how your users actually think. Get feedback from real customers to re-orient yourself. If this not possible, try to involve someone else to bounce ideas off.

4. Write less code

Think more about what you are writing and how to do it more intelligently.

Think about code organization for code reuse.

Use a language that allows for easy/quick constructs.

Use a framework that provides good classes/functionality for your problem.

Use standardized boilerplate code: CSS frameworks, boilerplate distributions... **

Use libraries: emailing, captchas, admin, accounts... **

5. Create fewer bugs

Use xUnit for your language and do TDD.

Automate testing: e.g. Selenium, continuous integration.

Next part

In the next part I will discuss boilerplate code and problem definition in detail. See you soon!

References:

Comments

Markus Koljonen: It's all good, but whatever happened to user centered design? All these tips seem to revolve around the thought that the developer does their development all alone in a vat and that understanding of the user comes by thinking hard, which rarely really works. So put those mad coding skillz into best use: involve your target users with the concept development, UI testing and development priorisation!

Mikito Takada: Hi Markus,

You are absolutely right and I should have given a bit more context for this post: I'm attending Garage 48 in Helsinki in January ( http://www.garage48.org/events/helsinki-2011 ) and I wrote this post with that in mind.

So I don't really mean that a single developer should carry the world on their shoulders; there is a lot that can be done to better match user expectations and wants as well as having a real process for team activities - it's just that when you have 48h and are just a developer, then the extent to which you can get user feedback and develop team working methods is limited...

Markus Koljonen: See you there ;)