Reapplied Engineering

So I blew a few hours reading thru 37signals’ book, “Getting Real,” a book consisting of essays regarding the various and sundry tasks related to developing a web application.

My review? Full of shit. Basically, if you happen to developing a publicly-accessed, sold and marketed web application that has a knowledge domain that any college graduate can understand, you can follow the advice given by the book. It does have some good bits but for the most part it’s basically a story of how 37signals built their application, and, in traditional self-righteous 37signals form, they believe their single three-or-four-year experience starting a single company with a few apps means they know what’s best for us all. I have a huge ego and generally enjoy rubbing shoulders with those with huge egos, but come on, I don’t have my head in the sand.

Where are they wrong?

• Functional Specifications. They spend so much time shit-talking functional specifications, I’d believe they all worked for Big 5’s before. Yes, if we all worked on little, unimportant applications that had simple business logic and, in fact, had almost no functionality beyond the interface and data storage itself, this would be possible. In reality, the world is a very complicated place and most of the time the programmers don’t have a fucking clue what they’re writing. That’s why some business process genius or logistics guy or pricing guru or insurance actuator man has to tell you exactly how things work, which turns into a spec. Yes, in the magical lala-land that 37signals dreams of we can all be at harmony and know our knowledge domain perfectly, but in reality, we have a 3-month deadline and I don’t have time to learn enough chemical engineering to write a mission-critical application for a biotech company. Something as simple as a quoting application took months and months of time here at work because there was no spec.

• Customer Testing. Apparently they’ve never worked in an environment where one or two or five companies are paying you for something and you only get to talk to a few of their employees. They aren’t going to let you waste the end users time with some beta bullshit you free love hippie. If you’ve got a $49/mo application and can afford to drop a client or two by pissing them off, then you might be 37signals. Giving your customers access to the test site is a surefire way to sign your schedule’s death warrant. Most people who push paper for a living and don’t build things (MBAs) have a very hard time conceptualizing and envisioning future enhancements and how they fit into the current framework. That’s why they don’t build things for a living. They don’t understand that bugs are fixable and software is an agile thing. These are the people you’re usually giving access to the test site. Just say no. If they insist, follow an Agile approach and break the requirements down into bite sized pieces and implement features in those stages.

• Interface First. This is insane. If you’ve got any non-developers in the process, they will jump right in and ask you why the hell it isn’t done already, because, to them, the interface IS the application. Wouldn’t it be nice if we were all so enlightened? Also, you’ll probably need to know how the application will function before you can really design an interface. They might disagree, but the bottom down approach I understand where they’re coming from though. It would be best to design both the interface and the functionality together. Oh wait, the last specification I built involved both of these elements.

Joel Spolsky pretty much outlines all of this in his books and blog, and they actually quote him in Getting Real. The funny part is they selectively use his ideas as backing for theirs, such as when they advocate extended periods of quiet time for developers. Joel is a huge fan of functional specifications and I’m pretty sure his decades of experience with projects of all sizes wipes the floor with these “hot shit” 20-somethings.