The Ideal Development Job

Someone asked me recently what I felt was an ideal job in an ideal company in software development. I hadn't thought about it in quite those terms before, but I've been thinking about it a little since.

So what would I look for?

The Team
I'd want a capable team of skilled people, who are both willing and able to self-organize. I'd want them to have gelled already, or be very capable of doing so. It's nice if they have enough opinions in common that they don't argue about approach, but enough areas of difference that there's a healthy desire for discussion.

I'd prefer this to be a team that I like on a personal level as well; I have to spend near a half of my waking hours with these people, so I'd rather enjoy it. Besides, teams gel better when they get along, are willing to spend a little time outside the office with each other, and maybe have lunch on a semi-regular basis.

The Process
This is more a question of broad strokes than it is the details. If the process is relatively agile, focused producing software, good communication and a tight feedback loop, I'll probably be happy with it. The farther down the path it is towards big-up-front design, waterfall processes, the more likely it is that I'll be struggling to accept that problems this causes.

That said, regardless of the actual approach, as long as the process seems to fit the environment, if people are behaving in a functional manner, I can probably live with it. The important thing is to reach the desired goals, not the process, the politics, the constraints or any of the other areas where people often get trapped in dysfunctional behavior.

It's just been my experience that agile processes encourage functional behavior, and that many other processes tend to discourage it.

The Company
A company that's building a product, not offering professional services. I've done both, and I can live with both, but I prefer the long-term focus of a product company. Professional service companies have interesting variety, but are too subject to the immediate whims of their clients.

Similarly, the larger the audience for the product, the better. Again, this isolates you from the whims of a single client to some degree. It's not that I believe that customers should have no input on a product, just that they shouldn't have you over a barrel.

The company should also have good representation in management of people who understand software and how to build it, and are in close communication with the software team. This is important to me because, well, I build software, and company projects rarely succeed without some kind of informed executive representation.

This 'close' communication is, by my definition, honest communication. I've seen too many instances where the communication from a software team up to company management resembles the "telephone game", where no single datum can make it from the team to management without being transformed so radically that it can't be recognized.

The Product
The more people who can see it, the better. It's fun to share your work with the world. This means that consumer software is interesting, more so than business-software, and general business software is more interesting than really niche software.

That said, the subject matter helps. If the subject is exciting, that might make a reduced audience worthwhile. And if it "helps the world" in some way, rather than being parasitic, even better.

Technology
Finally, the technology counts for something. Don't get me wrong, technology isn't the reason why projects succeed or fail (for the most part). But most of us developers enjoy learning, staying current, expanding our skill-sets and our horizons, so a chance to take on some technology now and again is both fun, and likely to help attract and retain good developers.

Whether 'new technology' means Ajax, Java 1.5, Ruby, Steve Yegge's NBL -- well, that's less important.

And so?
Does your company sound like this? Tell me. :) Have your own ideas? share 'em.