8 good habits in web development

At Usersnap, we have over 20 (summed up) years of experience in well organized web development. We figured that track record allows us to call out the good, the bad and the ugly in the industry. Let’s start with the positive stuff.

1. Use a bug tracker

The inbox of a Head of Development tends to fill up over the day with feature requests, bug reports and snippets of user feedback. Sometimes you’ll even receive emails with a whole bullet point list (if you’re lucky) of requirements, pain points and random ideas. While it’s great that people take the time to give – at times very extended – feedback, it’s not really useful as is.

Using a bug tracker / project management solution like Basecamp or Trac you can reorder tickets and nothing gets lost, as tasks are only closed when they are done. Set a milestone, add keywords (so your co-workers can find your ticket easily), add a priority level and make sure to cc the person in charge of ‘fixing it’. Even if that’s yours truly. In the description, try to provide a user story. And make sure your summary is descriptive, you can use humor for your commit messages if you really have to (i.e.: when it’s done), but you’ll want your ticket to be clear.

2. Take responsibility

Be precise and targeted. You should know who can do what and who is available for an additional task. When in real doubt about who’s responsible, you can do a CC. But make sure to remove all others from the CC, as soon as you found the right person to assign the ticket to.

[otw_is sidebar=otw-sidebar-1]

3. Fix and test

Before somebody starts working on a task, it’s important to reproduce the real issue and to document the way to do this. Once the issue is fixed, ideally the reporting tester will still sign this ticket off.

4. Plan!

Do some sort of sprint planning (name it Scrum, Agile, what ever name you like) together with your team and clarify what’s important in the next iteration and what’s not. Don’t leave it to your developers to come up with their own personal strategy and execute accordingly.

5. Single sign off

Have a single instance (person or team, regarding on your company size) which will sign off every release. It’s important that this instance did not write the code to release – in doubt (or if you are a small team) – change this role often. Why? Everyone can push to the live system. Even if you have continuous tests enabled, eventually some test code or filler content will leave your dev desk. Which is not cool.

6. Create feature teams

Create feature teams, that means a whole team works on a feature, and not on “the backend” or “the frontend”. I’ve heard from this idea the first time in Budapest from a friendly Yammer developer. They pushed this to the max which means: even fixing bugs is a feature team and those are rotated often. This means, everyone has to be prepared to fix other’s bugs, but, notably: not their own. A great idea for building great software.

[otw_is sidebar=otw-sidebar-2]

7. Did we mention testing?

Sometimes it’s really important to do releases quick. But the time needed to test the feature is absolutely necessary. Nothing can spoil a weekend like a showstopper bug on an eCommerce platform which could have been avoided using proper tests. Bottom line: if you are in the situation to release untested code, your planning is bad and you should feel bad. And remember: implementing a new feature or developing a fix takes less than a third of the whole time needed for the whole process (talking to customers, deploying, quality assurance, …).

8. Always keep optimizing

It’s important to always think about ways how to optimize your application. Let me share my boilerplate – three steps to ultimate development success – with you:

1. Make it work.
2. Make it right / beautiful.
3. Make it fast.

Keep to the order of this list and you will get sustainable results. Plus: you are sure that your optimizing bases on working and correct code, not a work in progress code heap.

For a next post I’ll rant about all that can go wrong in a development process, i.e. the bad in The Good, The Bad and The Ugly. In the mean time I’d love to hear about your development best practices, in the comments!

If you want to see a result of executing this good points, try Usersnap. It will even help you staying on track during development and quality assurance.

[otw_is sidebar=otw-sidebar-4]