An Unreasonable Man

I was having a frank discussion with my boss this evening, trying to work out what's keeping our tiny development team from performing better.  He, nice man that he is, pointed out that "you are a reasonable man, he is a reasonable man, (the third member of the team) is a reasonable man--what is it that keeps you three from being an effective team?"

It wasn't until about 3 hours later that I realized what at least part of the answer is, and it's the root of what's been "wrong" with this team, and indeed, what's "wrong" with many development teams.  I am emphatically not a reasonable man. Where making software is concerned, I'm a distinctly unreasonable man. In fact, I'm pretty sure I'm a complete son-of-a-bitch. And the people I have loved working with the most are, themselves, unreasonable people. As you might imagine, this can cause a lot of friction in a development team, if the rest of the team is full of reasonable people who expect reasonable behavior.

In my defense, I'm pretty sure you can't make adequate software by being reasonable.

Any non-trivial application which is reliable, maintainable, usable, and transparent contains thousands of details, each of which, by itself, is barely noticeable. Each one smooths an edge: putting a button exactly where you expect it to be, performing a complex calculation so the answer to the question you're about to ask is immediately available, presenting a mass of data in a form you can quickly and easily understand. Each time a new feature is added, each little fix in the last iteration runs the risk of disappearing accidentally. Each time you smooth an edge or tweak a data retrieval or add another feature, you run the risk of slowing down, or displacing, or completely breaking something that was previously judged "good".  In the press of schedules and customer needs and work to be finished, it's easy to lose track of the fact that you're building something that needs to work with 1000 times the amount of data you routinely test against, or has to be installed by someone whose primary experience is with spreadsheets and word processors, or has to run on a machine that's 1/3 as fast as your giant development box.

If you test everything every time you deliver, and review your big objectives every few days, and test as many ways as you can to simulate what your customers are going to do with your software, and watch really hard for better ways to do what you're doing, you have the barest chance of making something they'll use. If you're fanatical, you might, just might, manage to make all these details line up, and someone will love your software enough to pay good money for it.  If you don't--you're doomed.  Your stuff won't get used.  Your users, if there are any, will constantly look for other ways to do what your stuff does. Your early reviews will be bad, and people will stay away in droves.

On top of that, complex software will always be far worse once it gets out into the real world than we envision it when we're writing it--there are simply too many things out there we don't anticipate in our little development and test environments. It's going to fail in ways we couldn't have anticipated, no matter how fanatical we are until we ship.

So I'm a fanatic. I obsessively test to make sure I didn't break something. I insist that the edges line up and the corners are smooth and the code just works no matter what is thrown at it. I can't ever be satisfied. I must constantly work to improve what we have done--making it faster and easier and better-looking and more reliable and easier to upgrade.

If we we can do all that--we'll still have to cut corners to make deadlines.  We'll still have to ship with features unfinished, and known bugs, and corner cases that throw exceptions, and installation issues that we didn't foresee, and users who just don't understand the UI, and odd data problems.

We may ship, but if we aren't fanatical, we won't have customers, at least not for very long.

So: I'm a test-obsessed, objective-driven fanatic. I can compromise for a release or two, but I'm going to hold you to your end of the compromise, and in the end, I'm going to be completely unreasonable about finally finishing that feature, or unraveling that chunk of spaghetti code, or fixing that long-running query, or smoothing out that broken data structure. If you're not just as unreasonable, I'm pretty sure I don't want you on my development team.  After all--if you're "reasonable", you're constantly willing to compromise the quality of my product--and I already know that's a recipe for failure in the market.  Why would I allow that?

I'm not a reasonable man.