Mike Mason’s Fire Your Development Team Theory

I've been stewing over a post by Mike Mason at his blog Agile Thinking for a couple of days. I make no secret of the fact that I come at this whole writing about tech thing from the perspective of a former developer, so when he titles at post “Startups: Fire Your Dev Teams” you tend to sit up and take notice.

And most of the folks who are commenting on his piece certainly did just that.

However, even as a former developer, I am still only a user now, even if my eye is just a bit jaded when I'm using a product. And while it may not seem nice or pleasant or smart to those commenters, what he is saying makes perfect sense from a usability perspective. The problem, however, lies in how start-ups are structured.

As in every field, there are all sorts of different developers. Some are great at innovation. Some are better at the day-to-day grind of bug fixes. And another group might be good at working quickly under pressure, perfect for getting something up and working quickly while others are more efficient with a slower pace that allows cleaner code.

When start-ups are getting off the ground, they can't afford to have the development staff to cover all these types. They usually go for the working quickly under pressure type of programmers to get a product off the ground in time for launch. But there's nothing wrong with pointing out that this type of programmer often gets bored very quickly in fixing that code later on, or gets mired in the mentality that the code “got the job done” and doesn't see value in refactoring the code.

Mason's post doesn't suggest firing the development staff; the title is hyperbole for those commenters who didn't bother to read the whole article. But time and time again you can see apps that got off the ground quickly, were innovative, and then ground to a screeching halt (or limped along) once they needed to scale. All he's suggesting is moving these developers on to other things in the company as it grows and making sure that your developer team is the right fit for the current job.

There are obvious examples of sites, even those left over from the first dot-com boom, that could have benefitted from Mason's advice. Take Epinions for example. I've been a member of the site almost since the beginning, and at this point, trying to add features or change something in how the site operates is like trying to turn the Titanic. Much like the tiny little house with crooked addition after crooked addition piled on top of it, sites like Epinions have issues with database integrity (multiple listings of exactly the same product) as well as user interface simply because no one involved with the development ever said “You know what? There's a better way to do this” and started over.

Sure, there will always be products whose initial architecture manages to scale well. But you look at apps like Twitter with its frequent outages, especially under load, and realize that sometimes, it's easier to just start over and then port over your user base to the new system rather than keep trying to plug holes in the dike with your fingers. And what may seem exorbitantly expensive in the near term might pay off in the long run if you are truly building a site you intend to have some longevity.