Bruce's Company

I am slowly making my way through Joel On Software's complete archive. This is a fairly large archive, and one might wonder why I am putting myself through this. As a matter of fact, I'm not "putting myself through" anything; I'm having a jolly good time doing it because the articles are so insightful and entertaining. Many of the principles that Bruce's Company will be founded on will simply be links to Joel's archive.

Today I read his article on craftsmanship. The gist of it is, craftsmanship is expensive, but worth it. In certain cases. The classic Joelism, where he likens an aspect of software development to some real-world case, occurs here:

The moral of the story is sometimes fixing a 1% defect takes 500% effort. This is not unique to software, no sirree, now that I'm managing all these construction projects I can tell you that. Last week, finally, our contractor finally put the finishing touches on the new Fog Creek offices. This consisted of installing shiny blue acrylic on the front doors, surrounded by aluminium trim with a screw every 20 cm. If you look closely at the picture, the aluminium trim goes all the way around each door. Where the doors meet, there are two pieces of vertical trim right next to each other. You can't tell this from the picture, but the screws in the middle strips are almost but not exactly lined up. They are, maybe, 2 millimeters off. The carpenter working on this measured carefully, but he was installing the trim while the doors were on the ground, not mounted in place, and when the doors were mounted, "oops," it became clear that the screws were not exactly lined up.

This is probably not that uncommon; there are lots of screws in our office that don't line up perfectly. The problem is that fixing this once the holes are drilled would be ridiculously expensive. Since the correct placement for the screws is only a couple of millimeters away, you can't just drill new holes in the door; you'd probably have to replace the whole door. It's just not worth it. Another case where fixing a 1% defect takes 500% effort, and it explains why so many artifacts in our world are 99% good, not 100% good. (Our architect never stops raving about some really, really expensive house in Arizona where every screw lined up.)

You might think that his point is that craftsmanship is not worth it. On the contrary, he thinks that it is worth it, because that's how you differentiate your product from competitors'. Differentiation from the competition is hard, therefore it should not surprise us that craftsmanship that differentiates is hard.

The company that I would most like to work for in the world is actually not Joel's (Fog Creek), or Google, or Microsoft, but Pixar. Every single thing they have ever produced, going clear back to the 80's, has been of a ridiculously high quality. And I credit one man above all for that achievement: John Lasseter. One thing that Lasseter likes to say around the Pixar offices is, "We sand the underside of the shelves." In other words, in their work, they take care of every last detail, even the stuff that almost nobody is ever going to see. That careful attention to detail permeates the whole process, the whole company, and it results in the fantastic movies that just blow away everyone else in Hollywood. (Okay, it's not the only reason, but it's a big one.)

Now. The astute reader might be saying, "Ah, Bruce, but that's exactly what Alan was doing when he was bugging you about the tiny little details in the app you were working on that you complained about so much." But there's a fundamental difference: it was an internal app. And even Joel, after his big speech on craftsmanship, acknowledges this difference in his concluding paragraph:

Craftsmanship is, of course, incredibly expensive. The only way you can afford it is when you are developing software for a mass audience. Sorry, but internal HR applications developed at insurance companies are never going to reach this level of craftsmanship because there simply aren't enough users to spread the extra cost out. For a shrinkwrapped software company, though, this level of craftsmanship is precisely what delights users and provides longstanding competitive advantage, so I'll take the time and do it right. Bear with me.

When I make software that faces the public, and I really, really care about its success, I will sand the undersides of its shelves. Some might say that if you sand the undersides of your internal apps, then that attitude will transfer over to your public-facing apps. I think there's something to be said for that, but I think there's more to be said for using time efficiently, and, after all, I know when I'm working on something internal and when I'm not, and I can make the leap.

Once again I am broadening this blog's horizons (or, in other words, diluting its purpose) with a post that is neither a rant nor sage counsel nor even funny. But I think it somehow relates to life in the working world.

I read a couple of things on the web over the last few days that struck me as similar in that they were both so typical of people from that part of the country. So here I present a quiz. See if you can tell where the authors of each of the two different blurbs are from:

1. [This appeared on Oddpost's FAQ list]
Where did the name Oddpost come from?
It’s the usual story really. Iain and Ethan were at the ’99 mandala sand painting retreat in Tengboche when the bang lassis they’d enjoyed in Chitwan finally started to kick in, and as they knealt on the cold stone floor of the monastery a yak outside began choking on some grass, making a noise like “ahd! ahd! ahd!” at the very moment their rinpoche began chanting in another room “pohhhhhhhhh stuh! pooooooohhhhhhhh stuh!” Ethan glanced over at Iain’s canvas. Iain looked over at his. They’d both of course painted the very same thing: ODDPOST.

2. I never go to a certain fake-Italian art-themed restaurant, because once I ate there and the waiter, who had gone beyond rude well into the realm of actual cruelty, mocking our entree choices, literally chased us down the street complaining about the small tip we left him.

I stopped going to another hole-in-the-wall pizza-pasta-bistro because the owner would come sit down at our table while we ate and ask for computer help.

I really, really loved the food at a local curry restaurant with headache-inducing red banquettes and zebra-striped decor. The katori chat was to die for. I was even willing to overlook the noxious smell of ammonia wafting up from the subterranean bathrooms. But the food inevitably took an hour to arrive, even when the place was empty, so I just never went back.

Answers:

1. That's right! San Francisco! Where else could it be? Where else are you going to find people who are just so darned pleased with the "multi-cultural opportunities available" and the "amazing diversity of ethnicities" that "enrich the community" in so many ways? And of course they need to share it with the world by working it into their FAQ, regardless of how contrived an excuse they need to come up with. And by so doing they have enriched me, their humble reader. How special is that?

2. The anwer is Manhattan. Although of course San Francisco also would have been an excellent guess. But Manhattan is really the place with the world-famous reputation for cuisine. If you ever need a reason to vomit, just ask any Manhattan denizen what their favorite eatery is. They will wax rhapsodic for the next 15 solid minutes (at least!) about that Brazilian place on 43rd and Lexington or the Ethiopian bistro at 12,000th and Hickory. And don't forget the deli with the amazing turkey pastrami on rye. The whole point, of course, will be to show how truly cosmopolitan they are with their sophisticated palatte and diversity of preferences together with their open mind concerning all languages and cultures. And oh by the way, it's a darned good thing they live in Manhattan, because you just can't get these things in flyover country. And it goes with saying, there's nothing worse than a chain.

Now, it so happens that I've been in Manhattan a few times, and had, oh, maybe a dozen or so meals there. I admit, not necessarily a huge sample size. But the funny thing is, I've really never had a memorable meal there. Nothing that I would ever consider to even approach the average meal that I've had at Outback or, say, The Cheesecake Factory. I mean, sure, the meals have been okay. Nothing wrong with them per se, other than paying about twice as much as what they're worth. But nothing memorable. I'm sure it's just been bad luck more than anything, and if anybody out there wants to give me a recommendation, I'd be very open to it, and I might even hop on a plane right now just to try it out. But just to show you that I'm not the complete rube I sound like, it so happens that there is a restaurant in the tri-state area where I've had some of the best meals of my life, called Fornos of Spain. But it's located in (gasp!) Newark. The horror!

But there's another interesting thing about #2. It comes from the blog Joel On Software, which is one of my favorites, and which I plan to quote extensively on this blog, because Joel is a software guy who truly gets it. Now, this particular quote came from the foreword that he wrote for a book on his bug-tracking system, and his point with the restaurant example is that he ended up always going to a place called Isabella's, not because the food is good, you see, but because you never have a bad experience there. And the reason you never have a bad experience there is because they have completely debugged the dining experience, through years of perfecting the process and writing things down in manuals and training employees. In other words, they're a chain. They may have only one location (I don't know), but they act like a chain, they smell like a chain, and they quack like a chain. That's what makes a chain a chain: they've debugged the entire process and they've got everything written down in manuals so that it can be duplicated over and over in restaurant after restaurant. Joel, of course, would never admit it, but that's what he's praising: a chain.

This post is neither a rant nor sage counsel; just something funny that happened in a meeting last Friday. The Four Developers, Scott (the "product manager" or something like that), and Jim the Consultant were talking (at length, naturally, and somewhat aimlessly) about how we're going to implement this massive credit card processing system over the next few years. At one point somebody asked Scott if any applications built for this sytem were going to have to support the briefcase model.

"Talk about 'briefcase model,'" Scott responded.

Yes. He really said that. "Talk about 'briefcase model.'" He did not say, as any other reasonable human being (including me, since I'd never heard of it either) would have said, "So, uh, what's a briefcase model?" He said, "Talk about 'briefcase model.'"

Of course, the critical question to be asked at this point (but which, I regret to say, I failed to do), is "Has Scott seen What About Bob?" Because of course, that's where that's from. Dr. Leo Marvin "psychoanalyzes" Bill Murray (Bob) at the beginning of the movie by simply saying "Talk about" whatever the last thing was that Bill (Bob) said.

If Scott has seen What About Bob?, then why in the world would he try to emulate the guy that the movie mercilessly lampoons as a pretentious, over-credentialed windbag, especially when Scott's job title is one that is particularly prone to allegations of being filled by pretentious, over-credentialed windbags? "But Williams," you say, "he was trying to funny!" Ah, but he was not. Scott is a funny guy (even "ha-ha" funny), but I know him well, and he was not trying to be funny. Particularly in meetings like this, he takes himself very seriously.

If Scott has not seen What About Robert?, then where did he get it from? Do people actually say this? If so, then what's wrong with all those people, that they've never seen What About Bob? And how come the have-seens don't tell the haven't-seens? In any case, how could such a transparently pretentious verbal tic survive for so long? Is it one of those things like "dude," where you start out saying it because you're being funny, but then it works so well that eventually you're just saying it out of habit, even when you're being serious?

So what we end up with, here, is Two Americas. On the one hand, you have people who have seen What About Bob?, and on the other, you have the people who haven't seen it, and so they still say "Talk about 'X'," and the former are secretly snickering at the latter, who are going to very angry when they find out about it, I can assure you.

As you can see, Scott's saying this completely blew my mind. I still don't know what to think.

Anyway, the conversation went on. Dave offered an explanation. Apparently it's an application where you can work offline for a while, and then later on come back online and the data automatically syncs up with the centralized database, or whatever.

"In other words," said Dave, "can the user still work on the application without any connection to any network at all--with his ethernet cable completely unplugged."

"Or any wireless access or anything like that," added Alan.

Again: Yes! He really said that! He actually thought it was necessary to specify: oh, by the way, and no wireless network access either. As if he was afraid that Scott was going to come back a couple of days later and say, "Hey guys, I figured out a way to get this briefcase model thingie to work without an ethernet cable. You just configure all the computers with wireless access! Bahda-bing bahda-boom!"

Oh, my. Hilarious. Perhaps there will be more entertainment in this new job than I'd thought. And by the way, I'm using a new, wrong spelling for Alan, for, uh, privacy purposes.

Okay, all that patience-and-tolerance stuff that I preached last time about how Allen's email ticked me off, but then he followed up with and long and reasonably convincing face-to-face explanation? Forget it. Well, maybe don't forget it, per se, but there are certainly limits to that approach.

I made a few more additions and improvements to the Requirements tab yesterday, and asked Allen this morning if he had any feedback on it. "There's your first mistake!" I hear you saying, but in reality, it was inevitable. As I said last time, I can't very well expect to just do everything myself how I jolly well please and then expect everyone else to like it or lump it. And by actually asking for the feedback, I look like a "team player." I also asked him to email the feedback to me so that I'd have a written record to refer to (but the real reason was that I didn't want to put up with him talking at me for another half-hour).

Well, I got what I asked for, all right! 16 bullet points, 31 lines, and 316 words (according to Word's Word Count feature). My favorite, I believe, was the suggestion that I make the the "minimum size" for the Add dialog bigger so that it doesn't look dumb when people resize it to the minimum amount. They can, of course, immediately resize it so that it's larger again, but apparently we don't want to subject them even for a moment to the horrific sight of having to see the dialog smaller than it was ever intended to be. Remember: this is an internal app!

My least favorite suggestion concerned the moving of the Other Requirements text box from the Requirements tab to the Add dialog box. We had discussed this earlier; he favored putting it in the Add dialog, while I favored the Requirements tab. Since I'm the one doing the implementation, by golly, I put it in the Requirements tab. A reasonable person, finding themselves disagreeing with my decision, would have either talked to me personally, or, since I asked for an email, said something to the effect of, "You know, I really think that the Add dialog is a better place for that, because of blah and also blah and blah."

Did Allen do this? He did not. Instead, he wrote this:

- Remove the button labeled 'Remove "Other"'
- Change the "Other" checkbox to a label
- Move the "Other" label and associated edit field to the "Add Requirement" dialog
- In place of using a checkbox to determine the presence or absence of an "Other" field, use the presence of text in the "Other" edit box to signify the presence of an "Other" requirement.
- When there is text (such as "This is sample requirement") in the "Other" edit box on the "Add Requirement" page, make it show up in the list of Requirements and make it look something like the following: ("Other Requirement: This is a sample requirement")
- Decide between using "Other" or "Other Requirement" for the label as well as the text shown in the list view
- Consider using a descriptive label that explains how to use the "Other" edit field

In other words, he simply gave me step-by-step instructions for moving this feature one item at a time from one form to the other. Are you kidding me?! This man is insane! I mean seriously, what normal person would do this?

Sure enough, a few minutes after the email arrived, he came by and wanted to talk about the items. I was still fuming from the email itself and in absolutely no mood to discuss it, so I told him I was leaving for lunch in a few minutes. He said okay, just come get me when you get back. Needless to say, I did not come and get him, and fortunately he didn't bug me all afternoon.

The interesting postscript to all this is that after the email I went over to Jamie and asked her which way she preferred, and without any prompting, designed a solution that was essentially exactly like Allen's. So I switched it over. The point, however, is Allen's extremely oddball way of reiterating his suggestion to me.

Lately I have been working with Allen on a "quick Windows app" that is supposed to be a better, more usable version of the "BackOffice" (not to be confused with anything Microsoft does; this is a credit card agent app) product that we bought from Lighthouse software. The original BackOffice app was a truly awful mess from a usability standpoint, and we didn't use the vast majority of its features, so coming up with some kind of an improved app is pretty much a slam-dunk. I have been working on the "Requirements" tab, the details of which I won't get into.

I figured I was about 90% done with it and ready to move on to another part of the app this morning when I got an email from Allen giving me some feedback on my work. Here is a sample of some of what he said:

- make the "Add" dialog an always-on-top style form
- make the "Add" dialog resizable
- set anchors on buttons so they will move with the form when the form is resized
- set minimum size for form
- where feasible, make buttons a consistent size (I've been doing 68x21 for a lot of them, many I still need to standardize, for some that size is too small)
- include merchant Internal ID and merchant DBA in titlebar
- standardize size of border around the controls (8 pixels?)

I don't mind saying I was a bit ticked off on receipt of this feedback In the first place, I didn't ask for it. In the second place, it deals almost exclusively with these ridiculously small details that the average person could not possibly care about. This is an internal app, for crying out loud! Not only that, but the project is on a highly compressed schedule--the whole darned thing is supposed to be done by the end of this week, and there are huge chunks of functionality yet to be developed. And lastly, it set off my highly sensitive turf-infringement alarm. I believe in ownership. This is my thing, so I should be able to implement it how I want.

Oh yeah, and at the bottom of the email, he said the following:

Changes that you agree and don't mind doing, just go ahead and change; changes you don't agree about, let's discuss until we have consensus; changes you think would be fine but don't know how to do or don't want to spend time doing, let me know and I can help.

This was actually quite a brilliant little addendum on his part, because it was effectively a pre-emptive strike on my favorite method for dealing with such feedback: to ignore them.

Now, there are a number of problems with my initial, primal response, but we won't go into that just yet. The main point of this post is thus: shortly after I received the email and commenced stewing about it, Allen came into my office and talked to me about it. Now, he wasn't there to apologize for it or anything. Of course not. Why should he? Instead, he went through and talked to me about each item, explaining why he wants it and what the other possible options may be. After he (finally) left, I realized the following:

(a) You have to have a consistent look and feel across the application. Sure, I might want to "own" a piece, but obviously that doesn't mean I can just make it look any way I like.
(b) If I "own" a piece of a project, but I never ask for feedback on it, then I simply must expect to receive unsolicited feedback. It is unacceptable for a developer to expect to have carte blanche over feature implementation.
(c) Some of the suggestions were better ideas than I had originally thought.

There are still plenty of caveats, here. The whole internal app argument I think is still a pretty good one, and there's lots of time being wasted. But the point is, had Allen just sent off the email and assumed I'd take it with grace and gratitude, I not only wouldn't have done any of it, I would have been exceedingly ticked off and added that incident to the memo I'm preparing internally for when I leave because "I really can't work with these guys." But since he followed up the email with a personal visit, I am considerably less offended by its contents and a lot more open to implementing several of its suggestions.

Feedback in an organization is essential. Four eyes are always better than two, etc. But the delivery of that feedback is absolutely crucial. Delivered wrong, it offends the feedbackee and makes him feel like his ownership has been undermined. Here is how feedback has been handled at my previous companies:

1. At Tenfold, they made a conscious effort to have a very abrasive culture. They get smart people with big egos but who aren't afraid to back down from a fight. The reason why this works is because everybody's smart, and so everybody respects each other. That's understood. The reason why it doesn't work is that it just gets real old getting yelled at. Also, 99% of companies can't bring together the kind of brainpower that TenFold had.

2. At Digital Harbor, things worked okay at a developer-to-developer level within the Utah office. Nice guys. Also, there was a formalized testing team and process where they would log bugs to the database. There were two very big problems though. One was that the local (Utah) guy over developers just wasn't very smart and didn't know beans about the code. Having to take feedback from him was just ludicrous. The other big problem was that the head of development over the whole company was in Virginia, and he was just about the biggest jerk I've ever known in my life. He was smart, but not practical, and he assumed that everyone was dumber than him.

3. At BullySports, I had an ideal situation working with Grant, who was essentially my dev manager. But there were only two of us, and we were friends anyway, so we worked together well. There were never turf battles; each knew that the other owned certain areas of the code, and frankly had no desire to intrude on the other's territory. Mutual respect, in other words. We also had a lot of power within the company (though far from absolute, as I'm sure you'll see in future blogs) and so when feedback came from other, non-technical parties, we were free to ignore it.

I notice that as I write this, I'm blurring the lines between feedback and management in general. Obviously it's hard to draw a line, but in general I'm talking about feedback in situations similar to that described at the top between Allen and me.

So what's the ideal method? Well, first of all, you need to be working within the structure of Bruce's Ideal Software Team, which I will delineate in a future post. But beyond that, you need to be very careful about the way you deliver feedback. Be nice. Humble. Leave the door open for other viewpoints. And choose your battles. And unless you have specific authority in the context of the company, you must achieve by persuasion, not by executive fiat.

Last month I started working at the 4th company in my 6-year career. Which sounds worse than it is; not counting this one, which I'm still at, that averages out to close to a 2-year average per company. But the point is, I'm starting to get to be a bit of an expert at different cultures in mostly small companies. And they're all wrong. Which leads me to believe that the only way I will ever be happy is if I start some company. Unless I go and get my Ph.D. and become a researcher somewhere and get a nice chunk of autonomy, but I doubt that will happen because I no longer have the patience for school (that ran out with about a year to go in my masters program), and I also believe that I also need the profit motive to be present in order to be happy. I could be wrong, though.

Since I believe that inertia is the greatest force in the universe, I must concede that most likely I will never start my own company. But in case I do, I will want to remember the wisdom I collected while bouncing around all these other companies and make sure that I do the good things and (more often) not do the bad things. And if I don't, then maybe somebody else will someday see these postings and find the advice valuable. Or perhaps someday I will be in a position with a discernible sphere of influence in the which I can make a difference. We shall see.