Five Books To Read If You Want My Job

This came out of a conversation I had today with a few other test leads.  the question was, “What are the top 5 books you should read if you want my job?”  My job in this case being that of a test development lead.  At Microsoft that means I lead a team (or teams) of people whose job it is to write software which automatically tests the product. 

• Behind Closed Doors by Johanna Rothman – One of the best books on practical management that I’ve run across.  1:1’s, managing by walking around, etc.
• The Practice of Programming by Kernighan and Pike– Similar to Code Complete but a lot more succinct.  How to be a good developer.  Even if you don’t develop, you have to help your team do so.
• Design Patterns by Gamma et al – Understand how to construct well factored software.
• How to Break Software by James Whittaker – The best practical guide to software testing.  No egg headed notions here.  Only ideas that work.  I’ve heard that How We Test Software at Microsoft is a good alternative but I haven’t read it yet.
• Smart, and Gets Things Done by Joel Spolsky – How great developers think and how to recruit them.  Get and retain a great team.

 

This is not an exhaustive list.  There is a lot more to learn than what is represented in these books, but these will touch on the essentials.  If you have additional suggestions, please leave them in the comments.

Review: Peopleware

The book, Peopleware by Tom DeMarco and Timothy Lister, comes highly recommended by Joel Spolsky and Jeff Atwood over at the Stack Overflow Podcast.  It is probably most famous for its repudiation of the idea that cubicles make a better work environment for programmers than offices.  There is a lot more to this book than just an attack on cube farms, though.  The book dates from another era of the technology industry.  It was first written in1987 with an update in 1999.  Most of the content ages very well though.  It carries a lot of sage advice that managers today would be smart to read.  Alas, the book appears to be out of print at present.  Check your local library.  That’s where I got mine from.

The book begins with a discussion of people and shipping quality software.  Among the insights are that you can’t squeeze more than a certain amount of work out of people.  If one demands a lot of overtime, people will slow down, do more of their own things on your time, and otherwise use up the time that was supposed to be gained.  The authors make the argument that quality, if allowed to be driven by the team, will be higher than if driven from above.  Peoples’ innate sense of quality is probably higher than the user demands.  Based on these statements, the authors refute the notion that the only way to get work done is to set tight deadlines.  The idea that work grows to fill an allocated space is—they say—false.  I’m not sure I fully agree.  Work does expand to fit the allocated space.  The solution is not, however, to set insane deadlines to squeeze out the work.  Instead, the solution is to set a rational deadline and keep track of progress via frequent checkpoints (ala scrum).

My favorite section is that one which talks about people.  The authors assert that great people are born, not grown.  That’s not quite true.  They are born with innate talents and then grown to greatness.  The key point though is that those born without the right abilities will never be great.  You can’t teach everyone to be a great programmer.  Sorry.  Because of this, and the difficulty in getting rid of someone once hired, it is important to set a high hiring bar.  It is better to hire and then retain the right people than to hire the average person and try to grow them into above average performers.  It’s also important to retain stars.  Invest in them. 

Beyond individuals, teams are important.  The authors spend some time talking about what makes great teams work.  Unfortunately, they don’t give a formula for creating one.  No one seems to know how to do this.  Maybe some day we’ll figure it out, but for now the consensus seems to be that they just happen.  Managers may not be able to create a well jelled team, but they can certainly prevent one from happening.  The authors calls this “teamicide” and give several examples of behavior that causes it:

• Defensive management – Managers must trust their teams.  Attempts to succeed despite their failure only poisons the environment.
• Bureaucracy – Paperwork and policies that are arbitrary and disrupt the work flow.  If management is more interested in paperwork than results, the team notices.
• Physical separation – People interact better when they sit near each other.
• Fragmentation of time – Give people only one top priority at a time. 
• Quality-reduced Product – Management cannot demand a shoddy product or the team will stop performing.
• Phony deadlines – Deadlines should be real (and realistic).  Fake ones to force out more work just cause people to check out.
• Clique control – Let people group up.  It’s called a team.

There’s a lot more in this book.  If you can find a copy, get it and read it.  There’s a lot here for every technology manager.

Review: The Effective Executive

I read The Effective Executive by Peter Drucker because it was highly recommend on the Manager Tools podcast.  Despite what its name may imply, it isn’t written to company executives.  Instead, Drucker defines an executive as anyone with decision making ability.  This certainly includes all managers within a modern technology company and most of the frontline staff as well.  Drucker outlines 4 major areas of concentration for becoming more effective.

The first is your time.  Here the advice boils down to measuring where you spend it.  Time is the one thing everyone has in the same quantity and you can’t get any more of it.  If you want to make effective use of your time, know where you spend it.

Once you know where you spend your time, how do you decide where to apply it?  The next piece of advice involves making a contribution.  Determine where you can most make a unique contribution to the organization and spend your time there.  Ask yourself, “What can I contribute?”  For the rest, try to delegate to others.  Set the bar high and determine what active contribution the position should be making.

Next up is building on your strengths.  This is very similar to Now, Discover Your Strengths.  Drucker advocates hiring and rewarding people for their strengths, not their weaknesses.  I think he dismisses weaknesses a bit too cavalierly.  A significant weakness can overwhelm someone’s strengths.  It can make others view them negatively which can create a negative feedback loop.  However, his advice to focus hiring on strengths instead of a lack of weakness is on point.  People will accomplish a lot more in their area of strength than in a place where they are merely not weak.

Finally, Drucker talks about making effective decisions.  Toward this end he recommends concentrating on only one thing.  Have one focused initiative at a time.  Clearly define what the “boundary conditions” are.  By this he means understanding the specifications the decision must satisfy.  Build action into the decision.  A decision without action has no impact.  Measure the effectiveness of the decision.  This ensures not only that the decision was right, but that it stays right.  He also dedicates a whole chapter to making decisions not between right and wrong but between two courses of action neither of which is clearly right or wrong.  His advice here is essentially, argue both sides.  Don’t make the mistake of jumping on an early decision.  Instead, thoroughly vet each of the alternatives.

Overall I found this a good book.  Perhaps not as good as the hype, but useful.  I found myself doubting the reviews during the first part of the book.  The advice seemed solid, but obvious.  The second part which discussed decision making, however, was much more useful.  I truly enjoy the last three chapters.

Now, Discover Your Strengths

This is the title of the follow-up to First, Break All the Rules by Marcus Buckingham.  The first book was brilliant and really challenged the way we think about what makes someone successful at their job.  Now, Discover Your Strengths attempts to follow up on that with an in-depth discussion of “strengths.”  Strengths are a combination of knowledge, skills, and what the authors call talents.  A talent is “any recurring pattern of thought, feeling, or behavior that can be productively applied.”  Basically, it is your innate ability to do something.  If you aren’t born with a talent for, say, public speaking, no amount of training will make you Steve Jobs.  If you don’t have a talent for abstract thinking, you’ll never make a great programmer.  Sure, you can become competent at either, but you’ll never make it into the elite of your career discipline.

This sounds about right, but the authors don’t do a lot in this book to justify the position.  There is some talk about the way our brains develop neural pathways.  This may be the reason but the evidence in the book is not sufficient to really make the case.

The core of the book revolves around the premise that you will become much better if you focus on your areas where you have talents (these are your strengths) than if you spend a lot of energy trying to remove your weaknesses.  There is a lot of good anecdotal evidence for this in the stories of Tiger Woods, Cole Porter, and others. 

Unfortunately, the book spends a lot of time on StrengthFinder which is a questionnaire consisting of 180 questions, the answers to which will reveal which of the 34 identified strengths you possess.  The questions felt a lot like those you would find on a Meyers-Briggs test.  With the purchase of the book you can take the quiz once.  It will then tell you what your top 5 strengths are.  I was unimpressed with the test.  While Meyers-Briggs usually aligns well with how I view myself, this one didn’t.  It had elements I think are pretty far from my strengths and didn’t have things I think are.  Either I have a very wrong view of myself or the test is flawed at least in my case.  I suspect the latter.  Maybe I wasn’t able to understand what the questions were asking well enough.  There were several that could be interpreted in very different ways.  Whether or not the test is accurate, the information about the strengths themselves is paltry.  Each gets about a paragraph describing it and a page telling managers how to deal with someone who has it.  I’d like to see a lot more discussion for the individual what to do with their strengths.  This was almost wholly lacking.

The end of the book asserted the case that organizations should focus on strengths instead of skills.  An example of this is hiring for strengths and not specific knowledge or skills.  This may be a good idea, but I don’t feel the case was made strongly enough.  It was more assumed to be true than truly justified.  Even if true, it will be very hard to implement.  Should an organization make each interviewee take a test before being hired?  I’m sure the owners of the test would love that, but it sounds impractical.  It also ignores the ramp-up time someone with only strengths and no present skills takes to become productive.

The overall theme of the book—to pay attention to strengths and not weaknesses—seems right.  I’m persuaded that this is true, but more because of preconceived notions than because of the book.  The follow-through seemed weak.  This is disappointing because the first book in the series was truly eye-opening and much better justified.  Overall, I can’t recommend this book.  Borrow it from the library and read the relevant portions in a day or two. 

Managing Humans

I just finished reading Managing Humans by Michael Lopp, aka Rands in Repose.  Michael is a 15-year veteran manager from Silicon Valley.  He’s worked for such notable companies as Netscape and Borland.  He has a lot of good advice based on this experience.  The book is a compilation of blog posts so you can probably get by without buying it if you really want to.  However, there is a lot of good stuff in here and having a copy to mark up is handy.

If I have something negative to say about the book, it is that it doesn’t have a well defined audience.  Despite the title, the book isn’t all aimed at managers.  Some of the book is telling managers how to think.  Some is telling employees what their managers are thinking.  Still others are aimed at those starting a company.  A 4th audience is those trying to land a job and going through the interview process.  Each of these sections have good essays dedicated to them, but it also ensure there will be essays that are useless to everyone reading the book.

The best essays cover the subjects of meetings and employees. 

On meetings, Michael dedicates several essays to the sort of people you’ll find in meetings and how to help those meetings succeed.  He also gives advice about how to determine a meeting is doomed so you can leave.

On employees, he explains the concept of the “free electron” which is that rare super programmer and how to keep them happy.  He talks about analyzing poor performance and then acting on it.  One great tip is determining what the real problem is by creating a 2x2 grid comparing motivation and skill.  In a point that hit home with me, Michael pointed out that sometimes what appears to be a motivation issue can really be a skills issue.  Someone who once had great skills but who has been coasting on past accomplishments may have low motivation because their skills have atrophied.  In this case, skills training may be the solution to the motivation issues.

If you are managing a team, read this book.  If you want to understand what your manager is likely thinking, read this book.

One more note, the writing style is very irreverent.  If you are easily offended, you may find yourself wincing at times.

Review: Tribal Leadership

I just finished the book Tribal Leadership by Dave Logan et al.  It's one of the better leadership books I've run across.  The authors stress the need for leadership to develop a "we" culture instead of an "I" culture.  The authors call this a stage 4 culture and the leadership style Tribal Leadership.  The advantage of moving to a culture that embraces group success over individual success is the ability to accomplish more.  A group of individuals acting as induhviduals cannot reach the heights that a group acting in concert can.

The authors identify five group cultures:

Stage 1 - Life Sucks - People in stage one believe that all of life sucks.  The world is oppressive and there is nothing the individual can do to fix it.  This is the culture most likely to be found in prison or the projects.  It is not something seen often in corporate life.

Stage 2 - My Life Sucks - People in stage two acknowledge that life can be good, just theirs isn't.  The blame is externalized.  Something is in the way of their success.  It might be their manager or the company's rules.  Stage two is marked by complaining, but not action.  Employees in a stage two company will form bonds of shared oppression.  If you've seen The Office, you've seen a stage two culture in action.

Stage 3 - This is much of corporate America today.  People in Stage 3 say "I'm great" and mean "I'm great and you aren't."  Stage three is all about individual excellence.  People in this stage can produce amazing results, but it is tiring.  Everything is a struggle against those less excellence than one's self.   Power is hoarded.  Help is unidirectional.  People at stage three tend to burn out because every success take such great personal investment.  This is the hero culture typical of companies like Microsoft for much of its history.

Stage 4 - "We're great" is the mantra of stage four.  The corollary is "You are not."  Cultures at this stage work together--putting the good of the group above the good of the individual--against a common foe.   This might be Apple's operating system group against Microsoft or the Live Search team as it comes together to take on Google.  Cultures at Stage 4 can operate more efficiently because they can share information and build upon each others' successes.  People are happy about the success of others instead of being jealous.

Stage 5 - "Life is great."  This is stage 4 without the common foe.  It is working together for the betterment of mankind (or some such) without the need of a common foe to unite the tribe.

The book focuses primarily on the Stage 4 culture and the leadership style necessary to achieve it.  It should be noted that the "Tribal Leadership" style of these authors is very similar to the "Level 5 Leader" described in the book Good to Great.  Stage Four cultures and leaders exhibit the following behaviors:

1. A desire to work together.  To get to stage 4, you have to have gone through stage 3 and become disenchanted with the limitations of personal success.
2. Shared core values.  People must be on the same page.  It is important that each member of the group be able to make decisions in line with all the others.  Having a shared set of values enables this.  Each decision can be reached by asking "What do our values have to say about this situation?" and following  where that leads. 
3. A "noble cause."  The group needs a shared goal.  If core values are how a company operates, a noble cause is what it shoots for.  The authors say this cause must be "noble" but I'm not convinced it does. Any shared vision that all are bought into would seem to do.  Noble is, of course, better than ignoble. 
4. The use of "triads."  Communication should be decentralized.  Imagine the situation where a manager is trying to coordinate the work of two employees--Jane and John.  If the manager goes to John and then takes that information to Jane, this is an example of 2 dyadic relationships.  Manager::John and Manager::Jane.  Instead, the manager should encourage John and Jane to work together or perhaps for the three of them to meet together.  This sort of communication does not happen in a stage 3 culture because knowledge is power and having knowledge flow through you is a way to concentrate said power.
5. Using values and cause to work toward an outcome.  Actions must be informed by the values toward the cause.

A recent management talk I attended made the point that leaders set direction and then let their employees determine the best path toward success.  The job of the leader is to set the direction, align the team members around that direction, set the values for the group, and then be responsible for the growth of the team.  This sounds a lot like Tribal Leadership.

The end of the book feels a little utopian, but if you ignore the final chapter, there's a lot of useful ideas here.

Just a Geek

I just finished reading Wil Wheaton's "Just a Geek."  It recounts his struggles after leaving Star Trek.  Today Wil Wheaton is a prominent Geek.  He has 3 books, a popular blog, and was the keynote speaker at PAX 2007.  However, for the 15 years between leaving Star Trek: The Next Generation and today, he really struggled.  This book is a look into his mind during that tumultuous period.  He was a has-been who couldn't get work as an actor.  He was a husband and a dad and couldn't provide enough money to pay all the bills.  He was struggling with who he was and with his decision to leave Star Trek before it was over.

The book is basically a collection of blog entries from WilWheaton.net and his previous site.  However, unlike some books that are mere collections of blog entries, there is a lot of additional context around the entries that you'll only find in this book. 

Wil holds nothing back in his descriptions of what he was going through.  He had it rough for a while.  His style and openness makes the reader care about him as a person.  This isn't a book to read to get all the dirt on his life.  Rather, it is a book to read to understand Wil Wheaton the man.  It is an inspiring read.  To see him overcome his doubts and fears.  To watch him brought to his knees and admit defeat only to renew himself for victory on a new front.  One cannot help but be inspired by his story.  I find myself looking forward to reading his other material.  I read his new blog, but only irregularly.  I got tired of reading about his poker games.  After reading this book, it will go back on my regularly read list now though.  It looks like poker is taking a lesser role once again.

Has anyone read his newest book, "The Happiest Days of Our Lives" yet?  Is it any good?

On the Edge

I started On the Edge:  The Spectacular Rise and Fall of Commodore this summer but had to put it on hold as I went back to class.  Now that class is done, I have a few weeks to read what I want and finishing this was my first order of business.

On the Edge tells the tale of the rise and fall of one of the great American computer companies:  Commodore.  You've seen me refer many times on this blog to stories about Commodore and the Amiga.  My first computer was a Commodore 128 and I spent most of high school and college on an Amiga.  While the C= 128 was fun, the Amiga was just amazing.  It was so far ahead, it took the PC nearly a decade to catch up.

This book recounts the brilliant engineering and terrible management that characterized Commodore throughout its history.  Apple had Steve Jobs.  Microsoft had Bill Gates.  Commodore never had that great leader.  It had leaders, but none of them were great.  They never understood the market.  It was Jack Tramiel's company during the Commodore 64 days.  He had something with the PET and the VIC-20 and the Commodore 64.  But to him it was never a computer.  It was just a commodity to sell and he failed to understand how to leverage his great hardware into something bigger.  He cut R&D funding.  He pushed for too many compromises on the altar of cost reduction. He fired nearly everyone who did the best work.  Chuck Peddle created the 6502 and the PET.  He was the leader of the engineering group at Commodore and had great vision for computers.  Tramiel saw him as a threat and fired him.

I didn't realize that Commodore had the sales or the opportunities it had.  Despite what we've been taught to believe, the Apple II didn't start off too well.  Commodore and Radio Shack both outsold it in substantial numbers.  The Commodore 64 not only used the 6502 processor, but Commodore created and owned it.  The same 6502 that was at the heard of the Atari and Apple computers and even the NES.  They had their destiny in their own hands.  They could have created a 16-bit version or at least made it faster.  Instead, they fired all the staff responsible for creating it and lost a great opportunity.

Around the time the Amiga was acquired, Tramiel himself was fired by Irving Gould, the financier of the company.  Gould wouldn't keep management in place long enough to let a real strategy be executed. He too felt threatened by those who were his biggest assets.

Brian Bagnall does an excellent job chronicling the years of Commodore.  The book seems to be based largely on the recollections of people like Chuck Peddle and Dave Haynie but includes a myriad of other sources.  The book follows the personalities rather than the events.  In this way, the reader comes to know these men and can feel for them as they are jerked around by management.

As someone who grew up on Commodore's machines and who faithfully read every Dave Haynie post on FidoNet for years, I found it painful to watch the company I knew and loved die.  It was painful when the Amiga died in 1994.  It was painful to relive them reading this book.  I enjoyed it though.  If you are one of those who drank the Amiga Kool-aid during it's decade-long run, grab this book.

The book is also insightful for those of us working in the technology industry today.  Commodore died not because it couldn't create competitive products, it died because it made bad decisions.  Bad non-technical decisions.  The moral of the story:  it doesn't matter how cool the technology or how good the engineers.  If a company has poor management, it will fail in the long run.  Something to consider before your next job interview.

iWozn't Impressed

I just finished listening to the unabridged version of iWoz.  It's basically the autobiography of Apple cofounder Steve Wozniak.  I was hoping to get an understanding of the early days of Apple.  I've read several books on the subject but this is directly from someone who was there.  Alas, I was disappointed.  Less than a quarter of the book covers his time at Apple.  This is a book about Steve Wozniak, not necessarily about the time he spent changing the world.  Steve seems more interested in telling us about his pranks and his high school science projects than about the time in his life that made him famous.  Steve goes into excruciating detail about his early days and then blows by his time at Apple in short order.  He writes in a style that comes across as arrogant.  I don't think he really is, but that's the way the book is written.  He thinks very highly of himself.  Unless you really want to learn about Steve Wozniak the man, skip this book.  If you want to learn about Apple, grab Infinite Loop or Insanely Great (more about the Mac than the Apple //).

Dreaming In Code

I finally finished Dreaming in Code by Scott Rosenberg.  It was initially hailed as the Soul of a New Machine for a new generation.  As such, it fails.  Its depiction of the process and the characters involved is just not that compelling.  It's not poorly written, it just isn't outstanding.  It is, however, an interesting look into the realm of software process theory.

Scott was given inside access to the team creating Chandler.  Chandler is Mitch Kapor's project to create a new e-mail/calendar application.  Something akin to Outlook but much more flexible.  Scott tells us about the formative stages, the constant changes in direction, the endless meetings.  Some interesting characters like Andy Hertzfeld were part of the team.  As a description of a software project, it is palatable, but not exciting. 

We're given a view of what can only be described as a failure.  Chandler may become a success eventually, but it's taken over 4 years and is still not ready for prime-time.  It is this failure that provides the interesting part of the book.  Many software projects run aground, but most do so behind closed doors.  It is rare to have a chance to observe a failure and analyze what happened.  Perhaps this opportunity will give us some insights into why things failed which can be applied to avoid failures in our own projects.  I've posted elsewhere with my ideas on this.

Scott seems to have decided that a description of a failed software process was only moderately interesting and gives us an overview of much of the modern theory of software project management.  He references the writings of Fred Brooks, Alan Kay, Joel Spolsky, and many others.  These discussions are interspersed throughout the text and make up the bulk of the last third of the book.  In my opinion, the book is worth reading just for this content.  It's a great introduction to the subject and would make a good jumping-off point for more detailed research.

Overall, I recommend reading this book if software theory is something you find interesting.  If you are looking for a history book telling the story of a small team creating something amazing, stick to the original classic.

Failure by Committee

I'm reading Dreaming in Code and it's occurring to me at least one of the reasons that Chandler failed.  Chandler, if you don't know, is the Personal Information Manager application that is the subject of the book.  In my mind, Chandler failed because they didn't know how to make decisions.  Mitch Kapor tried to run the team in a democratic way.  Everything was decided by committee.  In my mind, he ran it so democratically that it had insufficient leadership.  For all decisions the book reads as if the team tried to create consensus.  Sometimes it is better to just pick a direction and ask people to follow.

This is basically why Andy Hertzfeld left the team.  He said, "To make a great program, there's got to be at least one person at the center who is breathing life into it.  In a ferocious way.  And that was lacking."  Think about Steve Jobs' role on the Macintosh team.  He drove the project forward.  He generated consensus by leading, not by hoping it would magically materialize just because a group of people was talking.  Instead, Kapor gets the group in a room, lets them discuss for a while, and then leave without really coming to a conclusion.  Decisions, once made, were often second-guessed by the next group of people as they tried to re-establish a new consensus.

An example is the design for the backing store.  There was an argument about whether to use ZODB or a traditional database or a resource description framework based on the concept of triples.  Any of them would probably have worked to one degree or another.  Yet, instead of picking one and going with it, they spent literally two years making that decision (Spring 2001 to June 2003 as I read it).  In the mean time, every other part of the project could only make marginal progress because everything relied on this underlying piece.

Joel Spolsky said he thought the program failed because it didn't have a central vision.  I think I'm saying something similar but from a different angle.  A solid vision is a decision.  By itself, it isn't enough, but it's necessary to start.  Chandler didn't have that vision.  It wasn't to be "revolutionary" but what does that look like?  No one defined revolutionary.  That meant that the project kept changing.  One of the early ideas was an address book but when Andy Hertzfeld left, the idea had been virtually dropped.  This despite the fact that he's written one.

What should we take away from this?  A successful project must know how to make decisions.  To do that, it helps to have a vision.  Vision doesn't magically materialize from a group talking together.  Instead, it is driven by one individual or perhaps a handful of individuals.  Those individuals don't have to dictate the vision.  Instead, they can cultivate it.  Cultivating requires encouraging those things that support the visions and helping to weed out those that don't.  Without direction, a group of people is like a garden without anyone to weed it.  The good ideas will be overrun by the bad and in the end it won't be very productive.

Talking is best when the outcome is a decision.  A decision is most likely if there is a shared criteria by which to judge outcomes.  The vision can be that criteria.  Without some bar to hold decisions against, they can always be second-guessed.  "Is this repository good enough for the project?  We don't know, but this one over here is better for some things."

Getting Real In Software Development

At the recommendation of one of our designers,  I just finished reading the book Getting Real by the people at 37 Signals.  This is the company that created Ruby on Rails and several web tools for managing business.  This book distills their philosophy of software development down into a series of 91 short essays.  The philosophy track very well with the concepts espoused by the Agile movement.  I found most of what they had to say thought provoking and much of it useful.  As with any book on this subject, you have to be careful to tailor the advice to your particular circumstances.

The basic tenets of the book are to think and work simply.  Products should be focused without a lot of disparate features.  They should do one thing and do it well.  They should ship early.  The development process should be streamlined without excessive documentation.  To facilitate this, the teams should be small.

The book forced me to re-examine the way I think about features.  Is there a more simple, first approximation that we can make?  It's too easy to shoot for the moon up front.  That can be daunting though and perhaps deter even starting.  Think about the minimal amount of work needed to get the job done.  Flesh things out later.

Here are a few of the points I found most interesting in the book:

• Make Opinionated Software - Most of the time users don't need all of the switches and options we allow.  Make a logical decision which satisfies most people.  That's better than overwhelming people with a myriad of subtly different choices.  I think of a certain API I worked on years ago that had something like 4 different synchronization models.  Sure, there was always the perfect one available, but you had to think about it.  Two (sync, async) would have been better.
• Don't Do Dead Documents - If the document won't substantially affect the process, don't make it.  Don't write up a spec that gets thrown away as soon as coding starts.
• Less Software - If you can solve 80% of the problem with 20% of the code, consider if that is enough.  It's easier to maintain the 20% than 5 times that amount.
• Get Well Rounded Individuals - Don't hire for specific skills.  Hire for smarts.  Smart people learn and you'll probably be doing something different in a few years anyway.
• Ride Out the Storm - Don't let a short-lived firestorm change the way you do things.  Wait for things to calm down before making decisions.  This applies well beyond software.

Much of what this book suggests applies a lot better to a small team doing web software than to a larger team doing desktop software.  The focus on simplicity only goes so far.  There is a time and a place for complexity.  Word is more complex than WordPad but it also solves a lot more problems.  Similarly, Vim is a lot more complex than notepad but it's a lot better for the task of coding.  Getting real doesn't deal with the need for that complexity.  I tend to think 37 signals would stop at WordPad.  They do have their own word processor and it's intentionally simple (although not quite WordPad simple).  Still, there's a lot of insight in their philosophy.  Consider it carefully before dismissing it.  I recommend the book.  It's a quick read and I'm sure you'll learn something.  I did.

As far as I can tell the book is available only from 37 Signals itself.  It isn't on Amazon.  You can buy it from the web site or view the free HTML version online.  I like killing trees so I read the paper version.

Showstopper!

I just finished reading Showstopper! by G. Pascal Zachary.  It recounts the creation of Windows NT starting with the hiring of Dave Cutler in October 1988 and ending with the shipping of the first version of NT on July 26, 1993.  The book puts a lot in perspective.  NT took nearly 5 years of grueling work.  The book spends a lot of time talking about the impact work on NT had on the personal lives of the team members.  Many didn't see their families much at all for extended periods of time.  It wasn't uncommon for people to pull repeated all-nighters.  We seem to have learned something from this in the past decade.

The book also calls out the contribution of the testing teams.  This is rare in these sort of books.  I've read about the creation of the Mac, the IMP, the XBox, etc. and almost never is testing mentioned.  It's good to read a book which recounts not only the work done by developers but also the heroic efforts of the testers.

If you have an interest in computing history or in the development of large systems, this book is a good one to pick up.  It puts you in the middle of the creation of the OS that runs on so many computers across the world.

I also ran across this interesting paragraph talking about the app-compat work:

The conflict stemmed from the differing priorities of the two sides.  Intent on refining their general model, programmers didn't want to distract themselves by fixing bugs.  Meanwhile, testers wanted to test.  This was a pointless activity when they saw the same bugs week after week. (p. 257)

That sounds a lot like what I was mentioning in my post about single-focus roles.  Each side is so focused on what it is tasked with doing that it doesn't take into account the needs of the other side.

Recommended Reading for New Test Developers

I've previously written about how to teach yourself to be a test developer.  That post included an extensive reading list.  It assumed that you were a tester and wanted to learn to be a test dev.  What if you are a new CS grad and you just got hired as a test developer?  What should you read to get a leg up on the competition?  What follows is my list of recommendations.  Some of this list assumes you'll be working in C++.  If you are going to be working in C# or Java or some other language, you'll have to make substitutions.

Testing Skills:

I'm not a big advocate of formalized testing skills.  There are those who think there is as much to learn about testing as there is about design and development.  I don't happen to subscribe to that philosophy.  Testing isn't trivial, but I'm not convinced it is rocket science either.

My only recommendation in this area is James Whittaker's How To Break Software.  This book is very practical.  Not a lot of theory but it will give you a good, working knowledge of how to test software.

Programming Skills:

With a CS degree you should have learned the basics of programming.  I liken this to learning a written language.  You know what sentences, verbs, and nouns are.  This makes you capable of writing but doesn't make you a good writer.  School projects tend to be small and throw-away.  You don't often have to deal with large code bases and the quality of the code itself is often not related to the grade achieved.

The Practice of Programming by Kernighan and Pike.  This gives you a lot of tips on how to write good software.  Short and meaty.  A great book.

Refactoring by Martin Fowler.  This book consists of two parts.  The first part explains the concept of refactoring.  How and when to make pre-existing software better.  The second part is a lexicon of refactoring patterns.  These are recommendations to handle specific situations in code.  The latter half of the book I find less useful.  Feel free to skip it.  However, the first half is extremely useful.  Make sure to read this.

Design Patterns by Gamma et al.  Also known as the "Gang of Four" book.  The most enlightening part of the book is the first few chapters.  It shows how to design an editor using an object-oriented approach.  I personally found this to be an "a-ha" moment.  If you didn't cover design patterns in school, read this book.

Design Patterns Explained by Alan Shalloway.  Great explanation of practical use of design patterns.  Read this before you start designing programs.  You'll find yourself writing better code and you'll find maintenance a whole lot easier.

Advanced C++ Skills:

These books will help you go beyond the basics.  Going back to my written language example, consider this to be like gaining a strong vocabulary.  You can communicate your ideas with just basic vocab words but to communicate the nuance, you need a deeper understanding of the language.

Effective C++ by Scott Meyers.  If you feel comfortable with C++, this is a great next book.  It will help you to avoid many of the gotchas in C++.  This book will help you be a better programmer at the syntax level and have a much deeper understanding of the language as a whole.  Skip the More Effective C++ book though.  It's not a bad book but there are better uses for your time.

Inside the C++ Object Model by Stanley Lippman.  Deep explanation of how C++ works under the covers.  If you want to be a coding guru, give this book some of your time.

These are my recommendations.  There are certainly books that I missed.  What recommendations do you have?

Interview with Clayton Christensen

The Innovator's Dilemma is an eye-opening book that everyone in the technology industry should read and understand.  I recently ran across an audio interview with the author, Clayton Christensen.  In it he gives a brief explanation of the main thesis of his book.  That is that there are certain types of technology that are disruptive.  They are at first underperformant of the market but allow for new uses.  Over time, they become good enough to subsume the previous solutions.  A good example is that of the PC.  When the Apple // and IBM PC first launched, they couldn't do the work of real business.  For that, you needed a minicomputer.  Over time, however, the PC became powerful enough to do everything that a minicomputer could and eventually totally replaced the minicomputer.  In his book, Clay uses examples as diverse as hard drives and earth moving equipment.  In this interview, he also starts to flesh out what he calls the "Law of conservation of modularity" which attempts to explain how the ability to make profits in a market changes over time.  He talks about how this affects Intel and how it will affect the software market.  I don't know that I agree with all of his characterizations but it is definitely thought-provoking.

 

Naked Conversations - Live

   Yesterday I went to see Robert Scoble and Shel Israel talk on campus.  It was a stop on their book tour.  It was an enjoyable hour.  Their presentation was better than many book tours I've attended.  First, it was on topic.  They discussed what they talked about in their book.  It is amazing how many times an author comes around shilling one book but spends the hour talking about something wholly different.  Second, it wasn't just the book.  Sometimes authors come and read a portion of their book out loud.  Thanks, I'll read the book.  Third, they were very extemporaneous.  They had a roadmap but still interacted with the crowd.  A lot of interesting questions were answered.

   For those who haven't read the book (that includes me right now), the basic thesis seems to be that corporate blogging is displacing traditional PR methods.  You get a more authentic connection with your customers when you keep it real than when you sanitize everything before it is sent out.  Sure, there can be mistakes made without the PR-filter, but that's exactly what makes it so valuable to customers.  As a user, I find that I rarely read about a product on a company's web site any more.  It is trying too hard to get me to buy and not hard enough to educate me.  Instead, I'll go read reviews or look in the forums.  Blogs can fill a similar role.  Bloggers from within a company can be great advocates for their products but still be informative.

   I think Robert and Shel are probably taking things too far.  There is a place for both corporate bloggers and PR.  Having a designated, official mouthpiece can be good.  It gives the ability to answer a question definitively and give people confidence that the answer won't change (soon).  At the same time, it will always be suspect because it is so one-sided.  Corporate blogs, if done right, should be more personal and less partisan.  They help put a human face on a business.  People are still, at the core, emotional creatures.  A human bond is worth more than lots of perfectly crafted press releases.

It's not the idea

I had a chance this afternoon to see one of my favorite writers and thinks, George Gilder.  He came to Microsoft to speak.  Anyway, he said something very interesting.  He stated than patents are not all that valuable because they are open.  Usually having the idea is not worth much until someone can reduce it to practice.  An example he used was that of the microprocessor.  This was something many people had the idea of doing.  It wasn't terribly useful to have that idea until someone figured out to actually manufacture such a beast.  Once that happened, the idea became valuable.  This knowledge about how to do something is what he calls a "latent."  This is an interesting idea and it has, I think, two implications:

1. Companies which are obsessed by patents may be going down the wrong path.  The next Microsoft or Intel won't come from having the right patents but rather having the right latents.
   
2. The USPTO should look very critically at "idea" patents.  If something is an actual mechanism of creating something (a latent which is being made open), a patent may be warranted.  If, on the other hand, this is an idea before its time, it should be rejected.  The only purpose the latter can have is to stop someone who has an idea about *how* to do it from doing it.  Imagine someone patenting the idea of the microprocessor.  It would have made it impossible for companies like Intel to have done what they did.

George Gilder works at the Discovery Institute.  His newest book is called the Silicon Eye.

Recommended Books On Testing

Another question I was asked via e-mail.  "Do you know of any good books that explain the testing process in detail? I noticed you mentioned Debugging Applications for .Net and Windows, but I am looking for a book that really explains the basics of 'I have this API/application and I want to test it'. "

Let me say up front that I’m not a big fan of testing books.  Most of what they say is obvious and they are often long-winded.  You can learn to test more quickly by doing than by reading.  Unlike programming, the barrier to entry is low and exploration is the best teacher.  That said, Cem Kaner’s Testing Computer Software gets a lot of good marks.  I’m not a huge fan of it (perahps I'll blog on my disagreements later) but if you want to speak the language of the testing world, this is probably the book to read.  Managing the Testing Process by Rex Black gives a good overview of the testing process from a management perspective.  Most testing books are very process-intensive.  They teach process over technique.  How to Break Software by James Whittaker is more practical.  I have read some of the book and have heard James Whittaker speak.  As the title indicates, the intent of the book is to explain where software is most vulnerable and the techniques it takes to break it at those points.

Part of the difficulty with testing books is that there are so many kinds of testing.  Testing a web service is fundamentally different than testing a GUI application like Microsoft Word which is again wholly different than testing a multimedia API like DirectShow.  Approaches to testing differ also.  Some people have a lot of manual tests.  Some automate everything with testing tools like SilkRunner or Visual Test.  Others write code by hand to accomplish their testing.  The latter is what my team does.  Most books on testing will either distill this down to the basics--at which time you have no real meat left--or they will teach you a little about everything and not much about anything.  Read the 3 books I call out above but make sure to adapt everything they say to your specific situation.  Treat them as food for though, not instruction manuals.

Do you have a favorite testing book that I haven't mentioned?  Share your knowledge with others in the comments.