code.isdangero.us

On sustainable development

July 13, 2009 - 3 Comments - development process company culture

Josh Susser at has_many :through has a great post about Discipline and creativity in the software industry. I find his comments on a sustainable development pace particularly striking:

One of the things I like best about working at Pivotal is that we consistently work at a sustainable pace. I can’t believe how many startups advertise jobs where they say that they expect you to work “startup hours”. I won’t even consider working at a place like that ever again. It’s not just because I don’t like working that way myself, but because I think companies that expect and require that kind of pace from their developers are just going to screw themselves and burn out their developers. They’ll either get real about what they can sustain, fail, or figure out how to deal with a high attrition/turnover rate.

I have had the experience of working at a startup which always demanded “startup hours” between tight, overlapping deadlines and indecisive clients, coupled with an organizational failure to adequately respond to their ever-fluctuating requirements. For the kicker, the company also pushed “startup compensation” in return for this unsustainable pace.

Any time a bug made it into production, management would come down on the team for failing to write quality software. In one instance, they made the decision to take away our ability to SSH into the production boxes, thinking that the solution would be to make the Director of Engineering the gatekeeper through which all code had to pass before being deployed. Not only did this severely slow down our cycles and thus serve to make the tight deadlines even tighter, but it made debugging production issues into a task which only the Director of Engineering could perform. For a company which could be juggling as many as half a dozen projects or more at once, this served as a ridiculously tight bottleneck for a team of engineers who were already having to work well into the evening hours on a fairly regular basis.

This “startup” had been profitable for a well over a year and for the majority of its existence by the time the situation had come to this. With a PR company, regular Fortune 500 clients, and sales teams for both the East and West coasts, it was seeming less and less like a startup which works hard and plays hard and enjoys the work, and rather more like a large, aging company riddled with bureaucracy and an unyielding determination to squeeze as many hours out of its engineers as possible for as little expense as possible.

The result was a very tense development environment which was not at all a fertile ground for innovative ideas from the engineering team. Not that it mattered, as management had made it abundantly clear that they did not care about beautiful code so much as they cared about just getting the work done as quickly as possible for sub-median pay. And yet they expected the code developed under these conditions to be perfectly bug-free by the time a project went live.

This problem manifested itself in several other little details, too. For example, the CTO one day decided to remove a number of toys that we had brought to the office for our enjoyment. Namely, they were these cushy little cloth spiked balls from Ikea that we called “dragon eggs” which we would occasionally toss innocently at each other for fun. They all ended up the CTO’s file drawer under lock and key. There was no good reason for this and only gave the office the oppressive ambiance of “no fun allowed”.

Any time a developer wanted to use a new plugin or tool, it had to be approved by the Director of Engineering first, which is ridiculous considering that the work the company did was primarily 6-8 week projects. If this isn’t a limited enough scope to trust a lowly bottom-level engineer to try new things, then what is? I remember when I had opted to use jQuery in a small admin console I was developing for a client, on a project for which I was the sole developer. Rather than receiving praise for my initiative and my insight into modern JavaScript libraries, perhaps some questions about why I had gone with jQuery over the other options, I got a lecture about why such decisions should go through him first.

Needless to say, I don’t work there anymore, and several of those who still do have been very vocal about their own discontent. Engineers are creative people, and when a poor working environment restrains that creativity, the result is rapidly diminishing morale. And while I learned a lot and had the opportunity to solve a variety of interesting problems during my tenure there, equal in return was the wisdom I gained to never tolerate such conditions again and to look for the warning signs at any company I consider working with in the future.