Book Review: The Mythical Man Month

What to say about The Mythical Man-Month?

Underrated.

If you haven't read it, the platitudes you've heard are true. MMM is a series of insightful essays on the practice of software software development. MMM was first published in 1975 and quickly reached classic status. The 20th anniversary edition clarifies a few things in some new essays, but the originals are left intact. The author, Fred Brooks, was a project manager at IBM who led the development of the IBM System/360 operating system and shares his experience and research on projects big and small. System 360 is one of the most successful computer systems in history.

One of the main tenets of the book is that:

Adding manpower to a late project makes it later.

Most seasoned developers know this to be true, or at least feel that way when they're explaining a whole bunch of context to the new guy two days from the deadline. Naturally, this does not prevent "optimistic" project and resource managers from trying this stunt.

I was not expecting many surprises from MMM since I already knew that adding people to projects close to deadlines just makes it later. However, I was thoroughly surprised to find not just one or two, but most of the 18 included essays capture some timeless truth of the software development process. I've captured two pages of quotes and notes for inclusion in presentations and design communications. In addition to the MMM aphorism, my favorites are:

• Conceptual integrity is the most important consideration in system design
• Productivity is constant. Higher-level languages can increase productivity 5x.
• Plan to throw one away; you will anyhow.
• One must assume there will be lots of bugs and plan an orderly procedure for snaking them out.
• Approaches to addressing essential parts of the software task: buy instead of build, rapid prototyping to establish requirements, grow software organically via iteration, identify great conceptual designers [and let them work]
• I [Brooks] believe the hard part of building software to be the specification, design, and testing, of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

Brooks said all this in 1975! 33 years have passed and you'll still get arguments on each of these points in many environments. People are pretty good at ignoring prior art.

The only criticism that I can levy at Brooks is that his writing style is a bit...dry. Obviously, I think it's good stuff, but MMM's not going to leave you rolling in the aisles. So, if you're trying to clue-in your management, I'd suggest giving them Peopleware first and then follow-up with The Mythical Man-Month.

Book Review: Collective Intelligence

Have you ever wondered how:

• Google comes up with its search results
• Amazon recommends you books/movies/music
• spam filters decide good from bad

Well, Toby Segaran not only explains these topics and more in Collective Intelligence, but he does so in a way accessible to software developers that haven't worked on machine-learning problems before. He even provides working Python code for all the algorithms.

Oh, and Collective Intelligence reads incredibly well. I could not wait to get home and get back to it -- and when I went in to work the next morning, I usually had a new idea or two of how to improve our software. I also started implementing the most important examples in Groovy to make sure I got it.

If you are a Senior Software Engineer or "better," this is a must-read. Proper application of the algorithms in this book are a great way to simplify your system and avoid getting nickel-and-dimed to death with new ways to prioritize/categorize/slice-and-dice your domain data.

Book Review: Mastering Regular Expressions

I just finished the Jeffrey Friedl's Mastering Regular Expressions. My previous regexp education has been driven by the necessity to scan a log file or search or replace a snippet in a source tree -- that is, haphazard. Friedl's book really is worthy of its title and it should carry The Definitive Guide as its subtitle.

Friedl is a Regexp Master and reading this book is really an excellent way to improve your understanding of the theory, implementation, and application of regular expressions.

As a practical result of this book, I have noticed I am more confident in applying regexps in my text editors (UltraEdit and IntelliJ IDEA) for both search and replace -- particularly for "captured groups." This is useful for taking code and turning it into documentation that non-programmers can read.

Book Review: Agile Development With SCRUM

There's been a lot of press in the software industry over the past few years about Agile development processes. SCRUM has been one of the most talked-about (hyped?) processes and has possibly the most ardent supporters. Ken Schwaber and Mike Beedle's 2001 book Agile Development with SCRUM (ADwS) is the definitive book on SCRUM by the guys who invented it. My conclusion:

Believe the hype.

I've been putting off this review while searching for an approach to describe just how much I enjoyed and agreed with the software development process described by ADwS. As an engineer with training in control systems, probabilities, and statistics, I really connected with the controls-based approach SCRUM uses to eliminate estimation error. As a software developer, I relish the idea of being able to work toward one set of achievable goals for a month before switching directions. As a manager of software projects, I like the idea of having something releasable to my customers every month.

If you're interested in learning more about the SCRUM software development process, I suggest reading Chapter 2 of ADwS and checking out the Control Chaos website. I'm sending these links on to my project manager now...

I also need to purchase a copy of ADwS so that I can read/review it yearly along with Peopleware and The Pragmatic Programmer.

The Art of SQL - Book Review

The Art of SQL teaches the general skills and describes the subtlties necessary to use a relational database management system (RDBMS) properly. Stephane Faroult focuses on why and when the strategies he details are appropriate. This is not a tips 'n' tricks for [PostgreSQL / Oracle / MySQL] book.

I really enjoyed this book and highly recommend it to anyone responsible for designing an application's data model or improving an existing one.

The Art of SQL is written in a very personal, humorous way and I could tell I was learning from Faroult's hard-earned lessons. I read most of this book while attending an "Art of Teradata" class / seminar taught by a top-shelf Teradata consultant. Both the Art of SQL and Teradata are strong proponents of properly normalized data models and I have to say I've drunk that Kool-Aid. That I've also fixed several de-normalization problems probably helps with that, too.

Remember...schemas are forever. This book can help you to avoid creating a mistake or help you get out of one.

Hidden Value - Book Review

Stephen: Honestly? No, I wouldn't hire you as a sustainer.
Jen: Are you kidding? I sustained RTD and MID for years!
Stephen: [hmm...the truth might not have been a good idea]

Hidden Value is a book by Charles O'Reilly about people, companies, culture -- and how the right mix can accomplish great things. I'd go so far as to call it a great, even inspiring, book. I took notes.

The central idea of the book is that by fostering an environment of:

• teamwork
• accountability
• collaboration
• autonomy
• trust

companies can yield the benefits of employees who take ownership of their work environment and do the right thing to improve it.

Manage less, trust and verify more.

Nice.

Hidden Value also emphasizes the importance of hiring people that fit will fit into the company's culture. Cultural fit is considered more important than an aptitude for specific skills. Herb Kellher, longtime CEO of Southwest Airlines is quoted as saying:

"We draft great attitudes. If you don't have a good attitude, we don't want you, no matter how skilled you are. We can change skill levels through training. We can't change attitude."

This is a fabulous approach for a large company, especially one such as Southwest Airlines where a star pilot is probably not more than 10% better than the median pilot. This probably still applies to a good extent in a small software company. The difference between a star and the median developer in the software industry is probably 100-1000% when measuring both quantity and quality. However, I don't think it's possible to hide a bad attitude from a customer in a small company. The attitude of developers is bound to bleed into a small software company's products and services.

If a company treats its people like people, and not assets, then it is in a great position to ask its people to treat its customers like people too. Customers like being treated like people because they are people. Having happy customers makes it a lot easier to get and maintain a positive income statement.

QED or something like that.

So, would I still tell Jen I wouldn't hire her as a sustainer? I don't know. I do know I would have broadened my "interview" question from:

"Have you used Perl or another scripting language to automate system maintenance?"

to:

"Have you ever written a program to automate something you found repetitive or error-prone?"

I think this is a much better question because it focuses more on the desired behavior than a particular skillset. I certainly agree with Herb that a scripting language skill can be taught, whereas the desire to automate work that can be automated is not likely to be taught. It's probably best not to pay someone while you wait for a behavior "light" to come on.

The Tipping Point - Book Review

The Tipping Point is a Design Patterns book for creating social epidemics. I feel like I can utilize Gladwell's concepts regarding epidemics to reach, grow, and serve customers better.

Verdict: This is good stuff.

The book describes "how little things can make a big difference." This idea is certainly not new and you could imagine plucking this phrase from a context of quality, customer service, or even oil filters. The 'little things' Gladwell describes are sociological in nature and he distills his thoughts into three change agents.

The Law of the Few
Gladwell postulates that fads, epidemics, and other changes that occur in large groups of people are actually the result of the influence of a few highly-influential people -- the Pareto Principle (aka the "80/20 rule"). He calls this the Law of the Few. The key roles in the Law of the Few :

• Maven - someone who is the go-to person for answers on a broad topic such as shopping, travel, or computers; this person is compelled to stay at the leading edge of knowledge on the topic and shares his knowledge enthusiastically with everyone around him
  
• Connector - someone who interacts meaningfully with hundreds or even thousands of people on a regular basis; Connectors are the reason "Six Degrees of Kevin Bacon" works
  
• Salesman - someone who is highly effective at persuading other people to take action; the effectiveness is derived from not just the logic of the Salesman's argument, but in the emotional connection made with the person being persuaded

Stickiness Factor
Gladwell also argues that whether an idea bursts into popularity or fades into the darkness is also influenced by the idea's Stickiness Factor -- which is merely the tendency for an idea to stay alive within a community. I especially enjoyed this section as Gladwell described not only how Sesame Street and Blue's Clues were made sticky to the target audience, little kids, but how they measured and improved stickiness before broadcast.

Power of Context
Gladwell's third and final "little thing" is the "Power of Context." The idea is that people are influenced by the environmental factors around them: weather, road closures, location of friends, and usability. Brilliant.

Conclusion
The Good:

• case studies and other examples of the tipping point theory in action
• naming the three key roles that create social epidemics is an effective shorthand

The Bad:

• a bit redundant at times
  
• re-invents Metcalfe's Law, by quoting Kevin Kelly and his "fax effect"
  

None of the ideas presented are particularly brilliant when taken alone. The brilliance is in the ability to synthesize these ideas into a strategy that enables and supports Mavens, Connectors, and Salesmen in doing what they do naturally -- start an epidemic.