Better Developers == Better Software?

I read a very interesting short essay from Joel Spolsky today: Joel on Software - Hitting the High Notes.

This concept of "better developers == better software" is something I have known for quite some time, but couldn't really prove. It is good to see that I am not alone in having a hard time proving the concept. It is also good to see that some very bright minds have come to the same conclusion as I, and that they likely got there first. :-)

Joel is right on the money when he is talking about why he formed Fog Creek Software. Good developers only want to be around good developers. They aren't challenged by working with mediocre developers. They can't innovate. They can't grow. Trying to keep a good programmer in a shop full of bad programmers is like trying to keep any Hollywood blockbuster star in horrible "B" level movies on the Sci-Fi network. It just doesn't work.

I found it funny that Joel uses writing IT software for a bank as an example of a place where good programmers won't be found. Funny because I work in an IT software group for a very large bank. Funny because I and anyone who knows me consider myself to be in the "good programmer" category. Funny because there aren't many others there who would fit that category. Fortunately we have had a few recent additions that just might. But I do worry about how long they will last.

We have noticed a huge improvement in code quality since I joined the project. But that's only because I have pruned lava flows, removed stovepipes, decreased vendor lock-in, fixed thousands of bugs nobody else could find or fix, rounded off the square wheels to fit nicely into existing round holes, etc. Had I not done it, it likely never would have been done.

But had the team been composed of 3 really good developers over the past 5 years of this project's life, instead of 9 so-so developers, the large amount of refactoring I have had to do lately never would have been necessary in the first place. We also would have a product that we could be selling in the marketplace to a larger number of the bank's customers. Instead it is a very targeted product serving only a very small number of customers. Our business unit has no capacity for revenue growth as our software can't support it. Neither can our development team.

Joel brought up the King David theory: you only need one good leader and an army of soldiers to carry out orders. The soldiers can be anyone; it is King David that determines success or failure. Like Joel, I disagree with this theory. Any leader needs a good support staff to yield successful results. The better the staff; the better the results will be. But it is even more important in the software industry, as software is still more of an art than it is a science.

But what if you have good people, but the leaders suck? It doesn't matter how good the team is, how well they get along, even if they can read each other's mind and finish each other's thoughts and ideas. If the leadership can't/won't support the team it really won't matter if the team would be able to produce the next killer-app. The team will walk away from the leadership long before the app is finished. But it will be a slow, painful process for everyone involved. Look at WinAmp. Joel danced around the destruction of NullSoft by AOL, but didn't really succeed at pointing the blame entirely on the AOL leadership.


I, and my fellow developers, share a cube farm from hell. I can't get more than 10 minutes of time without interruptions from people coming by. Consequently I only get my work done during "2nd shift" - between 7:00 pm and 11:00 pm. But I go in at 7:00 am. It is a looooooong day.

Our equipment is far too slow to keep up with us. I spend a good part of that 7:00 pm to 11:00 pm time waiting for the cheap IDE disk in my development system to compile our software. An extra $300 for a RAID-0 would have gone a long way. It would at least annoy me less knowing that the leadership actually thought my time was worth more than $300.

I spent the past 2 days hand-merging files that CVS would have done automatically in minutes. I find it very disturbing that the leadership feels my time is worth less than the license costs of GPL'd software.

So I'm pretty much in some of the worst working conditions available for a software developer in the US. About the only way to make it worse would be to have the office in a major subway station in NYC. But on second thought that might actually be an improvement - you wouldn't be able to hold conversations or meetings due to the noise of the crowd and the trains; so you can just wear headphones and focus on the computers instead. Nobody stopping by to interrupt you.


Bad working conditions leads to good programmers going mad. Good programmers going mad leads to bad software, or the departure of said programmers from the team. Either leads to a smaller profit as costs are higher than they should be. But some bean-counter somewhere is happy with the figure we produce so our leadship is keeping the status quo. And this programmer is going mad.


I've just about come to the conclusion that big companies are a very bad idea. Once you reach a certain size the status quo is good enough for such a large precentage of the company that profit margins will fall off just because a bean counter in one group feels another group should spend $3 less this year on post-it notes, thereby resulting in the affected team losing customer information more frequently, and consequently losing customers and they revenue they used to bring in.

It is a good thing our bean counters are saving $300/developer by sticking with the cheaper IDE drives, as I think they lost at least $5-10 million in gross revenue this year because our development team can't support another customer.