Dave Concannon

Sometimes life runs smoothly. You frequent an upmarket restaurant for a delicious meal, engage in stimulating conversation with friends, and whittle away a relaxed hour or two while lightening the proprietor's cellar of Chilean red. Other times you find yourself performing a death-defying contortionist escape from a locked bathroom stall after your cries for help go unheard for twenty minutes. Fortunately, the latter example is extremely rare. Unfortunately for the author, it is based on first hand experience.

The establishment in question had a point in their favor - I'm the sort of placid fellow who values the bragging rights from a daredevil escapade more then the exertion, embarassment, and potential danger of the situation, and was easily placated with a complimentary drink. My significant other felt quite differently about being left at a table on her own for twenty minutes, and wrote to the restaurant with a list of grievances. There was never a reply, and until I read Gavin Kennedy's "Everything is Negotiable" I couldn't figure out why.

Kennedy's work is based on his decades of international experience as a professional negotiator. The material is presented in a humorous fashion - negotiators are classified as falling into one of four character types, with their various traits epitomised in different farmyard animals. Each chapter starts with a multiple-choice self assessment, which gauges how you would approach the type of problem which is later clarified in the chapter. This approach is supplemented with four assignment-style quizzes interspersed through the book, which allow the reader to tackle a more in-depth problem and gradually reinforces the lessons in the mind of the reader.

The author addresses varied topics of interest to potential negotiators, from how to prevent conceeding to people in strong positions, resisting intimidation, addressing the other parties self-interest, to how to deal with threats. It surprised me, however that Kennedy leaves the topic of how to research a negotiation uncovered. Excluding this, the book is packed with amusing anecdotes and witty asides and reads easily. Some of the lessons to be learned from the book include:

• Never accept the first offer - Any experienced negotiator comes to the table with an offer that they would love you to accept, but which they fully expect you to negotiate. It's not a negotiation if you capitulate immediately!
• Never give anything for free - "If" is the most powerful word in your vocabulary. Anything you compromise on must by counterbalanced with something of equal value. Any concession should be conditional - "If you want me to compromise on X, then you must agree to Y."
• If you are not representing a principal, invent one. - Blame a fixed price or deal terms on your boss/wife/mother-in-law! Displacing responsibility to this other party (if you back it up with credible evidence) strengthens your position.

So what have I learned from my houdini-esque restaurant experience? Firstly, if I'd wanted anything in compensation I should have kicked up a fuss at the time; Any leverage I had disappeared as soon as I left. Secondly, a list of grievances just makes people defensive - without a concrete suggestion as to what would resolve the issue, there was no incentive for the restaurant to do anything but ignore the letter. Thirdly? Don't leave the table without your mobile phone.

In the two months since our departmental library was augmented, I've read through around eighteen of the seventy five books recommended by Joel Spolsky. I'm pleased with the pace of reading, but I have to admit that I haven't gained as much from some of the books as I would have if I were actively attempting to study them. During "Making the Technical Sale" for example, I found myself spending more time sleeping then reading - even though it's one of the books I can probably learn the most from, having no direct sales experience... maybe it was just a stressful week in work. Other books, such as "The Tipping Point" by Malcolm Gladwell, were page turners that caused me to miss my bus stop.

Throughout this process, I've been picking books off the shelf pretty much at random. I'd take a look at the availability list on the company intranet and then examine the amazon reviews, finally picking something that intersects on the curve of positive customer feedback versus catchy title. Once I'd read the easy choices that caught my attention, I was left with a lot of books that all looked good, but didn't really differentiate from each other in any way that would make me want to choose one from another. At this point I turned to the mercy of the joelonsoftware forum for advice.

The stand-out recommendation (before the discussion descended into a critique of NASA's ability to manage software engineering projects) was "Peopleware" by Tom Demarco and Timothy Lister. During the didactic process I had zoomed into the tree-level view of reading lots of interesting books, while the forest-level concept of a "Management Training Course" had blurred to the edges of the picture, I had essentially started working on lots of little problems while taking my mind off the main goal - criticially analyzing how each book applied to a management position.

In hindsight, "Peopleware" is an obvious recommendation. The world is saturated with parodies of bad management, from the pointy haired boss in Dilbert and David Brent from The Office, to the pure sociopathic malice of the boss in Office Space; this book is a successful attempt to categorise and alleviate the fundamental problems that managers cause or exacerbate within their organizations.

The authors keep a light and humourous style which never degrades into a malcontented rant, and they positively emphasise the role of management as a supporting tool to allow workers to complete their roles both more effectively and in a manner that gives the employee a sense of job satisfaction. The school of self-serving, ego-boosting, megalomaniac management is drawn out into the limelight without too much malice. Some interesting soundbites:

• Provide employees with a spacious, a noise-free, and well-lit environment. - This is absolutely fundamental to anyone working in a position where they need to use their brain. The books site numerous studies done on how the ability to work in a quiet, adequately spacious, and well-lit environment significantly boosts productivity and reduces stress and error.
• Realise that expenditure on personnel is an investment, not an expense. - Companies need to actively encourage their employees to grow their skills, knowledge, and abilities. Skimping on training, fundamental tools, or rewards for performance stifles employee morale and prevents intrapreneurship.
• Allow employees to set their own estimates. - An employee willl work harder to meet his own targets, as they see it as a challenge to themselves. This also improves their ability to estimate tasks. An employee will not work harder to meet an unrealistic target from someone else, particularly someone who is removed from the problem, or unskilled in the area involved.
• Allow employees to pick the people on their teams - Allowing employees the opportunity to work with people whom they are friends with, or whom they want to learn from motivates them to justify the responsiblility that is given to them. I think most engineers will agree that it's much easier to work with someone you get on well with.
• Aim for standardised measurements of quality, but don't make it the be-all and end-all. - If you aim for a certain level of CMM, don't turn down challenging problems that could negatively impact your CMM level. Techies in particular love a challenge, and the chance to learn a new technology or tackle a difficult problem is very rewarding in itself. And the opposite is true; Working on dull projects negatively impacts employees.

So, is this book of any benefit to the lowly developer? If you have ever been in a position where a person or process made your work more difficult, then this is the book which will allow you to objectively influence the situation to your benefit. Every manager should read this once a year, and every engineer with a poor manager should discreetly place this book on their desk.

Trying to bring ideas and technology together into something useful and / or beautiful can be quite similar to the Zen koan of the Unstoppable Force and the Immovable Object. On one side of the spectrum we have the pure techie. In the technician's world neither the unstoppable force or immovable object actually exist; physics doesn't cater for metaphysical analogies which won't obey the principle of conservation of energy. Everything can be modelled to an acceptable precision, implemented, and tested under labratory conditions.

Situated across the vastness of space from this position looking slightly puzzled by the entire affair is the user. To this paradigm of luddism, anything is possible. If Johnny Five can control a signboard with his anodized remote-control proboscis gizmo, then surely you can write me an application that can enable me to talk to the dead? "Sandra Bullock can hack computers, I saw it on some documentary about the information superhighway...can we get her in to give some training?".

Populating the vast and nebulous void between these two crude, hyperbolic stereotypes we find everyone else. Some of us will tend more towards one pole or the other (in general the distribution for people involved in engineering is probably skewed in the direction of the techie). This middle ground finds itself adopting the position of interpreter between these two factions, converting "wants" and "needs" into tangible actions that will eventually result in someone spewing out a few thousand lines of code. The process of translating the needs of the user into something which is actually possible for an engineer, let alone practical or useful is known as "gathering requirements".

Requirements capture and task estimation are among the most critical and neglected areas in software development. Jamis Buck wrote a very interesting take on how task estimations tie in closely with the assumptions made about the necessary requirements. Each side of the argument have their flaws; developers often "gold plate" projects in order to learn new technology or processes, users add in cool-sounding ideas which have no real business value and add complexity and overhead to the development process.

"Facts and Fallacies of Software Engineering" by Robert L. Glass is not devoted to estimation or requirements capture; rather it is a collection of observations about the process of engineering software, covering design, implementation, testing, and management that the author has found to be true in his decades of experience. That there are a disproportionate number of points which are either entirely devoted to, or touch on the subjects of requirements capture and estimation make this book required reading.

The author has assembled fifty five concepts he has observed throughout his career as a developer, researcher, and technology writer. To the experienced engineer there is nothing covered which should shock or provoke controversy; rather it is a refreshing reminder of the pitfalls that most projects will encounter in some form or other. In relation to the issues described above I offer these two supporting points:

• Point 9 - One of the two most common causes of runaway projcts is poor estimation
• Point 23 - One of the two most common causes of runaway projects is unstable requirements.

Other points of interest:

• Point 2: The best programmers are up to twenty eight times better then the worst. - This interesting statistic could be quite worrying for the management of project teams, or it could be an economic confidence booster. An engineer that is 28 times "better" then his peers is obviously a bargain (Unless you're paying them twenty eight times more). But if none of your engineers are more productive then the others, do you have a team entirely consisting of alpha-engineers or a team full of dummies?
• Point 28: Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal. - This would, upon first inspection, appear to be a win for the agile software development practicioners in favor of the waterfall advocates. My interpretation of this point is that a hybrid combination of a sturdy initial design, coupled with the flexible approach of agile development will serve you better then relying too heavily on one approach to the detriment of another.
• Point 21: For every 25% increase in problem complexity, there is a 100% increase in software complexity. - I think that this is one of the strongest bargaining points to use when considering whether to add a new requirement or not. The new requirement might sound amazing, and it might be an interesting challenge, but will it kick your project estimates into orbit?

The author has freely admitted that the "fifty five" is an entirely arbitrary enumeration, with the added bonus that it adds a tongue-twisting alliteration to the book's original title (Fifty five fascinating facts and fallacies of software engineering). The ten fallacies tacked on to the end are more of a wake-up call to the Dilbert school of management - in particular, a fallacy on using lines-of-code as any sort of performance measurement was something I thought was a relic of past ignorance until I had a conversation with someone who was recently berated by his employer for only producing a meagre handful of code in a given period. The fact that it was an extremely complicated bugfix which required hours of probing into murky old code, and that it resulted in a huge system improvement does not fit into such a narrow metric.

This book should not teach the experienced engineer anything new, but the sharp staccato format will reinforce experential knowledge - in particular the thought and precision which must be devoted to nailing down requirements and reigning in the estimation process. For any aspiring engineer, this book is gold dust.

Every morning, I climb on the Express bus which takes me in to Dublin City Centre where I work. It's an average journey of about an hour, although this can vary by as much as 50% depending on traffic, weather, and the whims of rioters. This can be a miserable journey at the best of times, but this morning there was the additional annoyance of a new driver - one who insists on following the journey plan to the letter of the law.

There are a time and a place for rules. We can't have the passengers lying on the floor, playing football, or sitting on the roof. On the other hand, there are minor infractions which lend themselves to a better service; letting passengers on if the bus stops at a red light (if it's safe to do so), or letting passengers off where they need to as opposed to where the planner dictates.

The latter example can almost become an unwritten rule if every driver follows it - an implied contract between the company and its customers. And so it was this morning, as around 20 passengers lined up to exit at a stop that isn't really on the plans even though the bus stops there every day. The driver pointed to his checklist, and the customers were disappointed.

My first thought on the situation was that it was a case of poor positioning. (The fact that I had just finished Al Ries and Jack Trout's two excellent treatises on effective marketing "The 22 Immutable laws of marketing" and "Positioning" back-to-back may have had some influence). The driver has been trained to drive the bus from A to B; for the service the customers expect the bus company should have been positioning him to see himself as the guy who gets passengers into work on time. Positioning can apply to people, products, negotiations, and any other situation where you're dealing with human beings, and it's a powerful technique to positively influence your clients' opinions of you.

One of the core messages of positioning is that your brand and the brand of the competition occupy space in your prospective client's mind. How you influence their choice depends almost entirely on successfully relating your marketing efforts to what they already believe about your product and that of your competition.

This key message is at the heart of "positioning", with "The 22 immutable laws of marketing" holding a supporting position by listing the optimal laws that you should follow, and provides examples of where these laws were not followed to a company's detriment. "Positioning" reinforces these 22 laws, but unfortunately uses almost the exact same examples to make it's points. Fortunately, these examples are compelling.

Some concepts covered (From both books):

• People rank things in terms of ladders - If you're not at the top, you need to position yourself relative to the top. Never attempt to go head-to-head with a competitor who already owns the position in the prospect's mind.
• Avoid the "Line Extension Trap" - Companies with a strong brand name (E.g. Coke) often add new product lines such as "Cherry Coke", or "Lemon Coke". These extensions initially result in more sales, but dillute the original brand in the long run. It is more effective to create a new brand name and market the new idea with it.
• The Law of success - Success leads to arrogance, and arrogance leads to failure. Most marketing plans are long-term investments, there's no point changing direction mid-stream - but this is often what the arrogant marketeer does when they believe that it was their input, and not the long term plan that won the success.
• The Law of candor - When you admit to a negative, the prospective client may turn it into a positive. Admitting that your product is not the all-singing, all-dancing gadget that will transform your customers lives is a refreshing change in a world where advertising is a constant fog.
• The Law of the opposite - If you're aiming for second place, your strategy is determined by the leader. Coke has traditionally occupied a position as a cola for older people. Pepsi successfully positioned itself in contrast to this position, as the choice "for a new generation".

Where "positioning" really shines is towards the end of the book, where the authors cover example cases where they have been hired to reposition products. It's an interesting exercise to see where their inspiration comes from, and useful mental practice to attempt to market these products before they explain their own results . Also, there are tips on repositioning your own career or your business, selling the idea that positioning is flexible for any "product".

With that said, I would recommend "The 22 immutable laws of marketing" over "positioning" if you only had enough money in your pocket for one book. The point format of the former book is succinct and memorable, and the examples covered in both books are almost identical. If you were feeling sneaky, you might read the last two chapters online or in the bookshop.

Addendum: If marketing your business is of particular interest to you, I would also recommend JD Moore's "Marketing Comet" weblog.

Addendum #2: Eric Sink has done an in-depth geeks guide to the 22 immutable laws of marketing.