17. Lessons from The Elements of Style

Clear written communication is invaluable.  Business writing all too often suffers from a lack of clarity.  I have found The Elements of Style by Strunk and White to be a wonderful reference book. 

It was originally published in 1918/9 by William Strunk for a class he taught at Cornell University.  E. B. White, the children’s author, had been a student of Strunk and in 1959 a revised edition was issued with contributions from White.  In 2000 the fourth edition was issued.  As I discussed in my previous blogs about The Mythical Man-Month, a book of this age, even with revisions, is, in some areas, a little dated.  That said, many gems remain in this short (105 page) book.

Rule 17 – Omit Needless Words, is one of my favorites.  To anyone who views this as either too common sense or too prescriptive, I would suggest a careful reading of almost any email or PowerPoint presentation.  Many needless words will almost certainly be found.

A very early version of this is attributed to Blaise Pascal:

"Je N'ai fait celle-ci plus longue que parceque je n'ai pas eu le loisir de la faire plus courte. --I have only made this letter rather long because I have not had time to make it shorter."

Lettres provinciales, 16, Dec.14, 1656.  (from Cassell's Book of Quotations, London, 1912. P.718).

Subsequent writers including Jefferson and Lincoln have made similar apologies.

In the “Approach to Style” chapter there are many guidelines such as:

• Do not overwrite
• Do not explain too much (or, I’d add, too little!)
• Make sure the reader knows who is speaking
• Avoid fancy words (and, I’d add, obscure acronyms!)
• Be clear (so easy to say, all to often – hard to achieve)

While these and many other rules and guidelines should have been learned in High School; if they were, they seem to have been forgotten by most!

Another useful chapter contains a list of commonly confused words and expressions.  I still cringe every time I hear or read “irregardless”.

In my opinion (not IMHO), the proliferation of technology-enabled communication such as Twitter, IM, Chat, and even email does not eliminate the need for following common sense rules for style.   While I know that I don’t always succeed in following their advice, I hope you enjoy Strunk and White.

16. Politics and Your Brand

Politics are a fact of life in an organization.  The higher up you are in the organization, the more important they become.

Years ago I worked for a boss that was full of common sense.  The important fact he taught me about politics was that you don't have to play many of the political games, but that you do need to understand them.  If you don't, you are sure to be hurt by them.  His advice to me, which I have tried to live by for over twenty-five years, was "Be True to Yourself and Always Keep Your Integrity."   Some of this relates to a key principle of management - the need to treat everyone fairly.  That doesn't mean that you need to treat everyone the same, only that you do so fairly.

You have a Personal Brand at work whether you realize it or not.  One of the best books I have read on this is Career Warfare by David D'Alessandro.  The subtitle is "10 rules for building a successful personal brand and fighting to keep it".  Not surprisingly, corporate politics can have a large impact on your brand (substitute career, if you'd like) your actions - and reactions to people and situations - truly count.  The book has multiple great examples.  I'll share a personal one of my own.

Years ago I was hired in as a project manager for a project that for a large variety of reasons was a victim of "Analysis by Paralysis".  My charter was to cut what could be cut and get it completed and implemented.  I cut much and two weeks before go live we had a review with the CEO (who I had never met).  I had gone over my presentation with the IT Director and the CFO multiple times and we thought it would take thirty minutes and then we'd have a brief demo.  Instead the review went from 10:00 am to 5:30 pm with a short break for lunch.  It then continued until 7:00 pm for the demo.  Simply put - it was brutal and I felt like the target.

Afterwards I was in the IT Director's office and I asked two questions:

1. What happened?
2. Should I start looking for a job tomorrow?

He told me to not worry; that I had done fine and that the point of the review was to ensure that the IT Director and CFO never had as a long a project again.  And in the fifteen years until the CEO retired, there never was.

More importantly, from a personal perspective, was that I passed the CEO's test and until he retired he took and active and positive role in my career.

In today's world your brand is also impacted by Social Media, so think before you post that picture.

15. The Mythical Man-Month - Part 4

This week I’ll finish discussing The Mythical Man-Month.  

Chapter 11 – Plan to Throw One Away describes the need for prototyping.  As Brooks comments, “Where a new system concept or new technology is used, one has to build a system to throw away…”  Obviously many more systems have now been built than when this was written, but the caveat on planning for something remains valid.  Years ago I saw a company decide to learn a new development technology by writing a custom order processing system.  Needless to say, they should have planned to throw the first one away!

Chapter 12 – Sharp Tools describes how critical is it to have appropriate tools.  Here again, time has changed the tools but not the necessity of having good ones and knowing when and how to use them.

Chapter 13 – The Whole and the Parts describes how applications are commonly built of components.  This chapter discusses various approaches for testing them – an early description of unit and integration testing. 

Chapter 15 – Hatching a Catastrophe starts with my favorite quote in the book:  “How does a project get to be a year late?   … One day at a time.”   One of the section headings, “Milestones or Millstones”, describes the reluctance, even today, of many IT people to commit to a schedule – or to even develop one!   The concepts covered here are 100% applicable today.  Consider Brooks’ description “For picking milestones there is only one relevant rule.  Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness.” 

The other quotation starting the chapter is from Sophocles:  “None love the bearer of bad news.”  The good project manager doesn’t shoot messengers but instead creates an environment where people are encouraged to speak the truth.

Chapter 15 – The Other Face describes the importance of documenting the work so that it is maintainable later.  While approaches may have changed, the need is still there.

The Epilogue consists of one paragraph.  To conclude this series of Blogs on Brooks’ work I’ll quote the first sentence:  “The tar pit of software engineering will continue to be sticky for a long time to come.”

14. The Mythical Man-Month - Part 3

This week I’ll continue discussing some of my favorite chapters from The Mythical Man-Month.  

Chapter 5 - The Second-System Effect describes the dangers of the second system someone designs.  On the first one the designer is careful, noting additional features (aka bells and whistles) to be used next time.   As Ovid observed about two thousand years ago:  Add little to little and there will be a big pile.   The second system is an unmanageably large pile of poorly integrated features.  The good designer learns from this and the third and subsequent systems are better.  This is truly human nature.

Chapter 6 – Passing the Word describes how critical is it to have every one on the team on the same page when it comes to certain key concepts and standards.  In addition Brooks describes how change control should be handled.

Chapter 7 – Why Did the Tower of Babel Fail? describes how critical communication and project organization are – especially for a large project.  As Brooks observes “The Tower of Babel was perhaps the first engineering fiasco, but it was not the last.”

Chapter 8 – Calling the Shot covers estimating how long a project will take.  While the examples are dated, the concepts are clear.  As Ben Franklin said in Poor Richard’s Almanac, “Experience is a dear teacher, but fools learn at no other.”

Chapter 9 – Ten Pounds in a Five-Pound Sack is probably the least applicable chapter in today’s world.  When the book was written, writing efficient code was important; today it is a largely ignored concept except in processing large volumes of data or in the development of low latency programs for trading where even the geographical location of the data center is considered.

Chapter 10 – The Documentary Hypothesis is “Amid a wash of paper, a small number of documents become the critical pivots around which every project’s management revolves.   These are the manager’s chief personal tools.”  I believe this to still be true today.

Next week I will cover the remaining chapters.  I hope you can see how applicable these 35+ year old concepts still are.

13. The Mythical Man-Month - Part 2

As mentioned in the previous post, I plan on discussing some of my favorite chapters from The Mythical Man-Month.   What better place to start the Chapter 2 - The Mythical Man-Month!

To start with it is important to recognize four types of tasks:

1. Perfectly partionable task
2. Unpartionable task
3. Partionable task requiring communication
4. Partionable task requiring complex interaction

For type 1, adding people to the task will always reduce the elapsed time.  While not realistic for most project work, the model is clear.

For type 2, adding people to the task has no impact on the elapsed time.  The stereotypical example is it takes one woman nine months to have a baby - adding more women does not reduce the time!

For type 3, adding people to the task helps reduce the elapsed time, but the burden of communication increases as people are added so the benefit diminishes with each additional person.

For type 4, there comes a point where adding more people increase the elapsed time!  When Professor Brooks wrote this there were not robust collaboration tools available.  Those tools and better processes probably push the inflection point further, but it still exists.

The net result is Brook's Law:  

         Adding manpower to a late software project makes it later!  

The key learning is good project and resource planning.  The project manager needs to know where additional resources will help and where they will hurt.

Chapter 3 - The Surgical Team describes the criticality of role assignment.  Studies have consistently shown order of magnitude productivity differences between individuals.  Having the right people doing the right tasks is a second key.  

Chapter 4 - Aristocracy, Democracy, and System Design covers what we would probably now call System Architecture.   Put another way, design by committee is rarely a good thing - in buildings or in applications.  Professor Brook's key point is the necessity of Conceptual Integrity.

Next week I will cover some more chapters.  My hope is that these brief comments will make you want to read the entire book

  

12. The Mythical Man Month - Part 1

I first read The Mythical Man-Month by Frederick Brooks, Jr. in 1980, five years after it was published.  A second edition, commemorating its 20^th anniversary, was published in 1995.  Amazingly, it has never been out of print and over 250,000 copies have been sold. 

Ed Yourdon, a well-known and widely published technology author said, on the publication of the second edition, that it is one of best software books ever written.  His review can be found here: http://yourdon.com/personal/books/gentech/mythman.html

I find the book to be thought provoking and have re-read it every five or six years as a sanity check.  That is amazing when you consider that the book is the result of Brooks’ work at IBM as the project manager for OS/360.  The total project took 5,000 man-years – an astounding figure then or today.   The book’s chapters cover various key learning’s in software development.  Each opens with a picture and a quotation from various sources including Ovid, Ben Franklin, President Truman, and Goethe.  My favorite is from Chapter 14:  Hatching a Catastrophe:

            How does a project get to be a year late?

            . . . One day at a time.

I have read various reviews of the book that complain that the text is dated.  To be sure, some of the references to the specific technologies are dated.  That said, I believe those readers are missing the key points to the book.  The errors that the author describes from forty years ago are still being made today.   Brooks is said to have commented that his book is called the “Bible of Software Engineering” because “everybody quotes it, some people read it, and few people go by it.” (Wikipedia).

I gave a Data Warehousing Conference talk several years ago titled “Lessons of the Mythical Man-Month applied to Data Warehousing”.  In preparation I had sent a draft of the slide deck to Professor Brooks for his review.  He kindly did so and sent back some interesting comments.   

My hope in this Blog is to quicken your interest and hopefully prompt you to pick up a copy and read it.   Over the next several weeks I will cover some of the book’s chapters that have resonated the most with me.

11. Collaboration

Collaboration:  “the act of working with another or others on a joint project” (The Free Dictionary – online).  Such a simple concept and yet all too often, one that is poorly executed!   Almost all work can benefit from effective collaboration as not many solo projects remain.  There are so many factors and tools that can come into play to help ensure effective collaboration.   Some of them are:

Leadership:  Good leaders help ensure a collaborative culture through both words and deeds.  Reward systems can either encourage or discourage effective collaboration – be sure that you are incenting the behavior you want.

Hiring:  Ask questions during interviews about work in groups and the role the candidate played.  This can reveal a lot about a person.  Don’t hire a loan wolf into a collaborative team environment.

Geographically Dispersed Teams: Into today’s environment, this is almost the norm.  While not absolutely critical, long distance collaboration usually works much better if the team members have spent time face-to-face, including team-building socialization time.  When I had staff in the UK I followed their Cricket, Rugby, and Football teams.  The resultant connection really helps.  The same can be said for following activities in their home state / country.  Non-US people know so much more about the US (not all accurate, but much is) than most US citizens know about the rest of the world.  Adding something like BBC to your news sources helps.

Tools:  There are so many tools these days that help collaboration.  Some of them are shared work areas like SharePoint or Lotus Notes Databases.   Video conferencing, especially Telepresence units, make a significant difference.  Use them regularly.  If they are not available, use teleconference calls often. 

  

Clearly Defined Roles:  All projects suffer without clearly defined.  Remote collaboration projects suffer even more.

Example:  Years ago I was forced into remote work environment for a month.  I had been working closely with a co-worker for he previous four months and so we knew each other well.  During one phone call he told me:  “I can hear your body language.”  If we had not spent time together first that subtle communication would have never occurred.  Therefore the lesson is that the less you know each other, the more careful you need to be about documenting decisions and having clarity around issues.

Most of my examples have been about remote collaboration, but the points remain for local teams as well.  Share your experiences.