What’s the best way to give developers space?

August 13, 2013 | 1 comment

Like all my new posts and articles, this piece originally appeared on werd.io.

Software developers are not technicians. Whereas technicians are employed to do practical work involving technical equipment, the development process is more akin to writing. Paul Graham was absolutely right when he pointed out that:

[...] Of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

Making requires concentration, creativity and skills. In turn, those things require the right environment, talent and practice. All three can be cultivated.

As a CTO (and, in effect, product manager), part of my role is to protect the team I work with and ensure that they have the right environment to do their creative work. Depending on the startup, the resources and the context, how well this works is a mixed bag.

Most developers I know work with great big headphones on. This isn’t an accident; think of all those scenes in The Social Network where someone can’t be interrupted because they’re “in the zone”. It’s a great big social signal that says, “I’m working”. Completely understandable: regaining your concentration after an interruption can take a very long time.

More than a set of kick-ass headphones, though, a productive environment needs to be cultivated. Here, asynchronous communication becomes important – developers tend to prefer communicating by email because they can do it in a natural break, without replying right this second. Similarly, meetings need to be scheduled carefully. Non-developers sometimes have trouble with this, and perhaps see it as an anti-social trait. It’s not: you’ve got to leave people alone to work. If you’re looking for a frenetic pace and for something to always be going on, I’d hazard to say that a software company shouldn’t be your first port of call.

(The flipside of this is that developers have to remember to send those emails and be communicative. Nobody likes a black hole in their team.)

I’ve been thinking a lot about this lately, and would love to hear your thoughts:

If you’re a developer, what do you do to maintain your concentration?

If you’re a CTO or a product manager, what do you do to help ensure that your team has the creative space to do their work?

If you’re a non-technical manager, how do you prefer to interact with your technical teams?

#productivity #productmanagement #development

Bug tracking

March 9, 2009 | 4 comments

All software has bugs; the trick is to find them and remove them as quickly as possible while balancing against the other development you have to do. This is where bug trackers come in: they allow developers to project manage these activities while allowing users and other members of their organization to submit issues while not interrupting the development workflow.

Even though every software project needs a decent bug tracker, finding one isn’t easy. Everything seems to have a downside:

  • Bugzilla, while very powerful, has a near-psychotic user interface – or at least, I nearly went psychotic trying to use it. I’m the technical lead of an open source project with a computer science degree and twenty-five years of programming under my belt; an ordinary user stands no chance of reporting issues in a meaningful way.
  • Lighthouse is really simple and integrates well with email and things like Basecamp. Unfortunately, it’s so simple that certain features – like a drop-down menu that allows users or developers to suggest the priority (or complexity) of an issue – have been deliberately left out of the mix with no hope of inclusion. That means there’s no way of saying that a massive privacy flaw is more important than a minor rendering error, except by integrating with another product.

In the end, Trac seems to be the best solution. Integrations with the Eclipse development environment and Subversion source code repository (through plugins) are a definite advantage, and although the web interface leaves a lot to be desired, it’s nothing like Bugzilla.

The perfect bug tracker needs to encompass these two values:

  • Project developers must find it a significant help, not a hindrance.
  • Users (and project managers) must be able to easily submit useful bug reports, issues and feature requests, and follow progress on them.

Useful bug reports are ones that aren’t duplicated and effectively describe the problem so that the guesswork required on the part of the programmer is minimized. In some ways, both bullet points would be satisfied by a bug submission wizard that falls back to an integrated form once users have become used to the process. At any rate, it requires some empathy on the part of the user interface designer, and more of an emotional approach to the interface design.

In the most perfect world, this would also be fulfilled:

  • In an open source project, external developers must find it easy to contribute code through the same interface.

I’d be interested to hear recommendations for any other products – or to hear any bug tracker horror stories from developers and users alike.

Image Lucanus cervus taken by CCCvrcak and distributed under a CC attribution license.