Then my supervisor at my Fielder resigned. I became the entire web design department, and we were beginning redesign of the website. My new supervisor deferred to my judgment on how to proceed. I knew nothing about managing projects or relating to management.
That is when I came across Spolsky’s book. The book is composed of articles taken from his blog as well as some new material. Here are a few quotes from the introduction that express the feelings I had at the beginning of this project and now eight months later with the project still incomplete.
“You never asked to be a manager. Like most software developers I know, you would have been much, much happier if they would just let you sit and code quietly.”
“Managing software projects has nothing at all to do with programming. If all you’ve done so far is write code, you’re probably starting to discover that human beings are perhaps a smidgen less predictable than your garden-variety Intel CPU.”
“As a result, many software projects fail in some way or another, either overtly or covertly, because nobody on the team has any idea how a successful software project might be run. So too many teams never deliver their product, or take too long to deliver the product, or deliver a product that nobody wants.”
The Practice of Programming
One of the opening chapters discusses “The Joel Test.” It contains 12 simple questions, but it allows anyone involved in a software development project to determine the successfulness of the team. Our department got a 2 out 12.
Four chapters are devoted to writing functional specifications. “A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.”
I have to say that I geeked out after reading these chapters. I spent several days writing spec detailing how the new site would work. I even incorporated humor as Spolsky suggested to make the specs easier and more enjoyable to read. I showed them to our committee and they briefly flipped through them. They have sat on shelf for the last eight months.
To round out the first section, Spolsky covers how to create a simple project schedule in Excel, bug fixing, and Fire and Motion. This is borrowed from military tactics. Fire at the enemy [project issues] and move forward.
Managing Developers
One chapter is devoted to guerrilla interviewing. Any programmer interview should include an impossible question and a solvable programming question. These questions allow the interviewer to see the problem-solving process and the skills of the programmer. Do they use a naming convention for their variables? Do they plan before beginning to code?
Spolsky advises in the chapter entitled “Things You Should Never Do” that a developer should never scrap existing code and start from scratch. I faced this situation after coming on at Fielder. The decision was made to use a content management system (CMS) called DotNetNuke to develop the new website.
I spent several months beating my head against the wall trying to make it work. I finally convinced my new supervisor to permit me to write my own CMS for Fielder. In this instance, it worked out because I was able to tailor the CMS to the needs of Fielder and I wrote it in a language I am very familiar with. This ties in with the iceberg secret.
With software, the user interface, with all the graphics and fonts, composes 10 percent of the work while the programming is 90 percent of the work and goes unnoticed. So when a nonprogrammer sees a program where only 10 percent of the user interface is complete they assume that only 10 percent of the project is complete.
This happens every time I try to show off new functionality on the website. I might show them how I can switch translations of the site with a mouse click. Instead of oohs and aahs I get, “I don’t like the font color” or “Is that the picture we decided on?”
At the same time, most every page on the new site is devoid of copy. So every meeting, I get the question, “Where are we?” I have to remind them that my 90 percent of the programming is done. I just need copy from them. But since the site is empty the natural thought is that it’s a programming issue.
Being Joel: Random Thoughts on Not-So-Random Topics
In the final chapters, Spolsky discusses how to be successful when developing a software business. One chapter is simply titled, “Getting Things Done When You’re Only a Grunt.” Another chapter discusses how each company must either choose the organic growth model of Ben & Jerry’s or the “get big fast” model of Amazon.
Conclusion
I thoroughly enjoyed this book. It wasn’t too heavy on the Computer Science (I’m a sociology major turned programmer). He provided a great deal of useful business advice in an entertaining way. I wish this book had been available when I tried my hand at self-employment. I would recommend this book to anyone in software, management or just wanting basic tech business principles.