Monday, 19 December 2011

In Response to "The Engineering Route to Accounting"

A clever blogger I follow (John Cook) posted this:

Regarding "The Engineering Route to Accounting". The guts of the post is probably summarised by the sentence "Many people find themselves approving expense reports for people who do the work they enjoy doing, or used to enjoy doing. [i.e. engineering]".

I responded, and thought I may as well repost as I spent a fair bit of time composing it! As follows:

OK, I _somewhat_ agree that “by the time you have your degree, you have 5–10 years to go before, if you have any ambition, you end up a manager of some kind” – I would swap the word “any” for “a good amount of”, and I would add to the word “ambition” the words “competence”, “enthusiasm”, “empathy”, “confidence”, “integrity”, etc,. Not everyone is asked to lead, or manage.

I do not agree that “you don’t get to build anything, technicians do that … you only approve their expense reports …”. I think as a manager/leader, you are still building things, maybe just not in the same way an engineer would. Would Steve Jobs say he didn’t build the iPhone? Would Bill Gates say he didn’t build the Microsoft Corporation?


As an afterthought to this response I wrote:

... – my comment may come across as quite complacent.

So I should say that I agree leadership/management is not for everyone; it can be a burden, and it can be misused terribly.

I think your list of “What can you do if you want to avoid going into management/accounting?” is pretty spot-on John, nice one.

I hope if you stumble across this and have made the transition from engineering to management/leadership, that you find some of this useful.

Monday, 28 November 2011

Inappropriate Use of the WWW

Seen a couple of technical presentations/documents recently that contained a diagram, depicting the WWW like this:

Not specifically with SFTP, but other miscellaneous (non-HTTP) protocols.

I guess that this is an architectural misnomer. Technically, the WWW does not propagate anything but HTTP(S) (and whatever you choose to encapsulate within the HTTP protocol) - yes?

So if you were dealing with (for example) SOAP or RESTful web-services, putting "WWW" in the cloud thingy 'might' be appropriate, otherwise it's just the plain old internet.

Just putting it out there, mainly because I have not blogged anything for a little while...I bet the title of this post made you think it was about something much more interesting though, right?


Monday, 1 August 2011

Eclipse, Android Development Problem - "Error: Error generating final archive: Debug Certificate expired"

A really nasty problem, could have burnt through a fair bit of time.

Luckily I found this article after looking at the "Problems" tab in Eclipse and seeing my debug certificate had expired at the exact minute that I started getting the error message:

Resolution was reached as follows:

Renaming the debug.keystore file and running a "Clean". Eclipse put a new debug.keystore in place and away I went...however on the next build I get the following trace (my App is called SimpleList):

[2011-08-01 22:32:47 - SimpleList] ------------------------------
[2011-08-01 22:32:47 - SimpleList] Android Launch!
[2011-08-01 22:32:47 - SimpleList] adb is running normally.
[2011-08-01 22:32:47 - SimpleList] Performing com.infostructure.simplelist.SimpleListActivity activity launch
[2011-08-01 22:32:47 - SimpleList] Automatic Target Mode: using existing emulator 'emulator-5554' running compatible AVD 'Magic'
[2011-08-01 22:32:47 - SimpleList] Uploading SimpleList.apk onto device 'emulator-5554'
[2011-08-01 22:32:48 - SimpleList] Installing SimpleList.apk...
[2011-08-01 22:32:50 - SimpleList] Re-installation failed due to different application signatures.
[2011-08-01 22:32:50 - SimpleList] You must perform a full uninstall of the application. WARNING: This will remove the application data!
[2011-08-01 22:32:50 - SimpleList] Please execute 'adb uninstall com.infostructure.simplelist' in a shell.
[2011-08-01 22:32:50 - SimpleList] Launch canceled!

Bugger. Not to worry, found the directory with the adb application in it (<...>Eclipse\android-sdk-windows\platform-tools) and run the command as specified - "adb uninstall com.infostructure.simplelist" - command runs fine.

Next build works fine, and I'm back in business.

Wednesday, 27 July 2011

Software Development Stuff, July 2011

VS2010 Integrated SVN

I have recently discovered the AnkhSVN Visual Studio add-in for linking Visual Studio 2010 to your SVN repositories - it's fantastic:

Full Visual Studio 2010 integration - gives you those nice neat “checks” and other icons in the solution explorer, to indicate modifications, new items, etc. It's just like a bought one!

Data Access, Entity Framework 4.1, POCO

Have also recently discovered Entity Framework version 4.1 for awesome POCO (i.e. "code first") support - doesn't quite "just work" off the bat, but it's pretty damn close:

Couple of hints - initially, I kept on getting the following error message:

System.Data.SqlClient.SqlException: Invalid object name 'dbo.Users'.

...obviously I've got a table called [User]. There seems to be some issue (probably not an issue, but just my not reading enough about the framework) with pluralisation. Anyway, the solution is easy – decorate the EF POCO class with the TableAttribute:

 namespace Infostructure.SimpleList.DataModel.Models
[Table("User", Schema = "dbo")]
public class User
{ ...

JSON Serialisation with EF and AutoMapper

In the piece of work I'm doing a the moment (an MVC app that manages a bunch of “simple lists”) I want to be able to serialise to JSON where an incoming GET request is not ASP.NET authenticated and a UID and PW has come through on the query string.

Ran into trouble immediately with serialising my EF POCO objects to JSON, as they have circular references. So, I'm translating to ViewModels. Basically if I don't translate to my matching ViewModels, then I get ye olde "A circular reference was detected while serializing an object of type" exception.

Enter the fantastical AutoMapper library.

I use AutoMapper to handle the mapping from EF POCO objects to my ViewModels. The Mapper needs to be configured in the Global.asax ideally, or alternatively, just anywhere prior to where you intend to do the mapping. Like so:

 AutoMapper.Mapper.CreateMap<DataModel.Models.SimpleList, Models.SimpleListViewModel>();  

Here's some code from an Index method in one of my Controllers:

     public ActionResult Index()
string userName = Request.QueryString["userName"];
string password = Request.QueryString["password"];
if (User.Identity.IsAuthenticated)
_simpleListRepository = new SimpleListRepository();
var simpleLists = _simpleListRepository.GetSimpleLists(User.Identity.Name);
return View("Index", simpleLists);
else if (userName != null && password != null)
_simpleListRepository = new SimpleListRepository();
var simpleLists = _simpleListRepository.GetSimpleLists(userName, password);
var simpleListsDto = AutoMapper.Mapper.Map<IEnumerable<DataModel.Models.SimpleList>, IEnumerable<Models.SimpleListViewModel>>(simpleLists);
return Json(simpleLists, JsonRequestBehavior.AllowGet);
return View("Index");

Here's the link to AutoMapper:

That's all for now.

The code samples I've provided, etc, are a bit rough-and-ready as usual. However, should you happen to have stumbled on this post, and end up following some of it's recommendations, then I hope you enjoy using these features/tools as much as I have!

======= EDIT - 2011-08-01 =======

Unfortuantely AutoMapper uses Reflection.Emit, which is not allowed in a Medium Trust environment (i.e. my shared hosting web host).

There is an alternative out there called ValueInjector, which is not quite as complete-a-tool as AutoMapper as far as I can tell and has a bit of a steeper learning curve. Apparently it can be used in a Medium Trust environment:

I've reverted to a custom mapping implementation for the time being, since what I'm doing right now is not DTO-intensive. AutoMapper is great though and ValueInjector looks interesting.

======= EDIT - 2011-08-01 =======

Tuesday, 12 July 2011

New Zealand Innovation

So, some irony - two articles forwarded to me yesterday, both regarding software innovation in NZ, both at opposite ends of the optimism scale:

(1): "Kiwi Software Skills 'Shallow'" (thanks Ann)

Dr McKendry is a New Zealander who has built a successful career overseas and has basically come home and done a talk dissing the nation that launched him. 

Original link:

(2): "Your Business: Timing Right for Software Success" (thanks Dad)

This is my uncle, talking about the successful SME that he has built over the past 15-to-20 years and his plans for it's future. 

Original link:

My $0.02...

Perhaps the overqualified expat CRM corporate executives of the world (seriously Dr McKendry, please don't tell me you think that Siebel is an innovate product?) should remember where they came from.

NZ'ers split the atom, climbed Mt Everest and invented the electric fence; what's wrong with producing actual solutions to actual business problems in between?

Go uncle Ed!

Go back to Silicon Valley Dr McKendry...

PS: I'm fairly confident that my response is exactly the sort that Dr McKendry was hoping to invoke with his talk!


EDIT - 20131204: 

Since I wrote this post - just about two years ago today - my thinking has changed (perhaps due to the business studies that I have taken over the past two years) and I do now sympathise with Dr McKendry's perspective more.

There is room for improvement in NZ business. The cost of complacency is high and growing.

Thursday, 19 May 2011

Book: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

The Mythical Man Month comes with a big reputation attached.

The books was originally written in 1975. The author (Frederick P. Brooks, Jr) is a prominent Computer Scientist and software engineer, who most notably managed the development of the IBM OS/360 operating system. To quote Wikipedia, “the book is widely regarded as a classic on the human elements of software engineering”.

Honestly this was, for me, a difficult one to read. It's a little bit like trying to read the Bible in some parts (which personally, I find tough going). But I would say it is well worth it. In reading this book, I can see that Brook's writing has had an influence on almost every other serious piece of literature on the management and practice of software engineering that I have ever encountered.

The book is entitled “Essays on Software Engineering” and that's what it serves up. The chapters of the book are arranged in some sort of order, but really they're fairly distinct. The first few chapters are introductory and the last few tie a conclusion together, however for the most part you could practically select a chapter such as “Hatching a Catastrophe” (deals with software project schedules and the black art of software estimation) and read it stand-alone comprehensibly.

So, all that's left really is to provide a couple of thoughts as to where the book shined, in my opinion. There were many more sections which I thought were enlightening, these are a random few which I noted:

Brooks is strong on specification and design up-front, in the same way that Joel Spolsky is. Chapter 6 “Passing The Word” goes into detail on specification.

On page 155, in the “Hatching a Catastrophe” chapter, Brooks says “A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too. Hustle provides the cushion, the reserve capacity, that enables a team to cope with routine mishaps, to anticipate and forfend minor calamities. The calculated response, the measured effort, are the wet blankets that dampen hustle”...I love it!

In Chapter 1, “The Tar Pit”, there is a section on “The Joys of the Craft” and then one on “The Woes of the Craft”. I find these sections to put into words, my feelings regarding software development. I won't type the sections out (cause they're long!), but if you get the chance, read them. Anyone who's ever known the elation of writing even the tiniest program and watched it bring a machine to life in some way will be able to relate to these passages. The only other way that I could express the feeling is to say that it's something like this (Tom Hanks “creates fire”, in Castaway):

Finally, I think the following excerpt from near the end of the book captures the essence..."[the book] is only incidentally about software but primarily about how people in teams make things".

So that's it. In summary, a difficult read, but well worth the effort in my opinion.

Title: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Author: Fredrick P. Brooks, Jr
Link: Amazon
Tags: Book, Fredrick P. Brooks, Project Management, Software Development, Software Engineering

Monday, 25 April 2011

Book: Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and [...]

This book is effectively a collection of Joel's blog postings and letters, assembled into a somewhat coherent sequence of five parts. The first two parts are the most useful - “Bits and Bytes: The Practice of Programming” and “Managing Developers”.

I found part two exceptionally enlightening – this is the first book/article that I've read which deals with the matter of managing software developers directly, from the point of view of a former/current programmer.

Part one (The Practice of Programming) contains a very useful series of four chapters entitled “Painless Functional Specifications” - again, fantastically simple ideas and solid reasoning as to why it's critical that (almost) any piece of software development should be preceded by the thought process and documentation phase that amounts to a functional specification. I would just about say that this series of articles (or something resembling it) is a must read for any developer. Too many developers (myself included at certain times in the past) in my opinion are all to willing to dive into coding ahead of putting the simplest of designs on paper – this process alone can reveal fundamental flaws in a plan. Joel goes so far as to recommend that developers take a simple course on practical writing, totally agree. Almost all of the other chapters in this section are brilliant and enlightening – certainly however “Painless Functional Specifications” stands out as gold IMO.

Parts three, four and five are not so well organised and start to devolve somewhat into (loose?) assemblies of blog postings; many of which are revealing and fascinating (especially IMO, where Joel makes comparisons to his experiences as a Program Manager at Microsoft). There's a few posting about .NET that are particularly intriguing.

Many of the articles in the book were written in the years ranging 1999-though-2004; a period of time that the .NET Framework was in it's beta manifestation or in v1.0 and v1.1. I find this section fascinating for two reasons. Firstly, Joel has recorded, like a time capsule, some of the ridiculous announcements and summaries of .NET that Microsoft first put out there. I remember at the time, as a student and emerging professional developer being simultaneously intrigued and baffled as to what the heck .NET actually was. Over a period of a couple of years the hype boiled down to an apps development framework that was more-or-less similar to Java. Some of the fantastically broad and meaningless spiels that Microsoft were using to describe .NET at the time made it seem of equivalent magnitude and significance to a manned mission to Mars or Skynet becoming self aware, without providing any detail whatsoever about what .NET actually was. I guess however a campaign that marketed .NET as “Microsoft's equivalent to Java” wouldn't go down to well with non-technical folk. Joel saw though the bollocks back then with crystal clarity. The other element of Joel's commentary of .NET that rang true was his questioning of the need to engage .NET seriously as a development platform, and the cost of rewriting existing code-bases to integrate with .NET. To do this is a costly venture that many businesses are still struggling with the practicality of today. I remember at the time, the organisation that I was working with was wary of .NET and the cost that it represented from a business perspective. Joel's writings from this era reflect the exact same sentiment. For myself, at this time I was a fledgling developer who has just realised what .NET was all about and was keen as to get stuck into it – this didn't help things, and eventually led to my departure from a good company (voluntarily!). I have gone on to become a strong and accomplished .NET developer, at the cost of an opportunity to be part of a great NZ success story. Them's the breaks I guess – I enjoy what I do regardless and am still on good terms with the company that provided me with my first break into the software development industry (they are my Aunty and Uncle – the company is Abtrac), and that's what counts I think. Besides, I have moved on to another NZ success story! In summary, Joel's critique on the turmoil that the introduction of the .NET Framework brought to the Microsoft software development community is in depth and, I think, heartfelt. I enjoyed it.

In summary, this is an extremely useful book that is written in a lively and humorous manner. Well worth a read for anyone who has anything to do with software development. And in my opinion, a must read for Microsoft software development leadership/management people.

Title: Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
Author: Joel Spolsky
Link: Amazon
Tags: .NET, Book, Joel, Management, Software Development

Friday, 22 April 2011

Reading Log and Career Path

I started another blog - "Bernard's Reading Log" recently. Then I realised that since I don't post a lot of stuff anyway, and also because much of what I'm reading that I want to post about is related to technology (some more, some less), I may as well have it all in the same place. Makes my posting stats look more impressive in any case... So I imported that blog to this blog. I've got a few more books queued up that I've read (or am reading) recently - hopefully will get them posted soon.

Regarding the other topic in this post's header; my reading history (which can be viewed by searching for the Tag "Book") gives away the story of what's happened with my career in the last year-or-so. In January 2010 our Development Team Leader left the company that I work with to go out on his own. A bold and respectable manoeuvre, which I believe is working out well for him. For me that meant that I was offered his job - which I accepted.

Since taking starting as a DTL, I have found that professionally, things have changed for me significantly.

Managing and leading a team (I more-or-less do both) is a totally different job than programming. I enjoy it, but it's difficult to say why. If you asked me why I enjoy programming, that's pretty easy to answer - I won't go into it, but I think that anyone who enjoys programming will give you roughly the same answer; best description I've read to-date is here[1]. The buzz of management and leadership is more challenging to define. I started trying to write up a description just now but got lost - I'll come back to this in a later post!

Anyway, as part of my transition to this new world, I thought it wise to seek professional help; I took a leadership skills course in mid 2010. It was led by an American lady (I'll remember her name and post it), she told lots of stories about her career, provided tons of valuable advise, etc; it was a generally worthwhile programme. The resounding message that I took away from it though was that although her overriding advise was to read more about leadership and management, regularly, more than 90% of people taking the programme wouldn't change their behaviour. I was determined not to be in that 90% and as such have kicked off a personal reading programme and am blogging my progress for my own reference, and for the benefit/amusement of anyone who may happen upon my blog.

Something else I've read recently, in the "painless functional specifications" section of Joel on Software (the book[2]), is that it's useful to have strong writing skills, in order to help with writing functional specifications and with day-to-day business in general. That makes sense to me. I guess Joel achieves this by writing tons of blog posts and the odd book. I doubt I'll write a book, but I can certainly put the odd blog post together.

So, in summary, my blog has changed tack, somewhat. Still technology oriented, but now leaning toward the leadership and management side of things. Most likely this just means it'll become more wordy. I'll start chucking a few more pictures in for good measure - they may be random (e.g. in this post they are of a trip I took to Hong Kong with my family in 2004). In any case, I hope it's a change for the better, and I hope if you happen upon my scrawlings here, you find them at least amusing!

[1] The Mythical Man-Month, Addison-Wesley, 1975, p.7-9.
[2] "Painless Functional Specifications":

Wednesday, 6 April 2011

Using XLinq & MVVM to Populate DDL for ASP.NET MVC

Making some adjustments to a website recently. It's not a heavily used beast, but my client required some dynamic functionality - pulling data from a semi-static data-source that he would be able to edit. Hooking up a SQL Server back-end would have been overkill, so I looked into XLinq as an alternative. I have tinkered with XLinq in the past but haven't ever found any particularly useful application for it. This time however it worked out beautifully.

Setup an MVVM for the page that I was working with and used a technique for loading the data that admittedly I need to credit to Sascha Barber. The technique is fantastic and works perfectly.

Here's my data, stored in a file name things.xml at

<?xml version="1.0" encoding="UTF-8" ?>
<name>-- STUFF --</name>
<name>THING ONE</name>
<name>THING TWO</name>

Here's the MVVM:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Collections;
using System.Xml.Linq;

namespace ThingSite.Controllers.ViewModels
public class ThingsViewModel
public SelectList Things { get; private set; }
public Thing CurrentThing { get; private set; }

// constructor
public ThingsViewModel()
Things = new SelectList(GetThings(), "Text", "Value");

private IEnumerable GetThings()
string fullXmlPath = "";

var xmlThingResults =
from thing in Common.StreamElements(fullXmlPath, "thing")
select new SelectListItem
Text = thing.Element("name").Value,
Value = thing.Element("name").Value,
Selected = false

var list = xmlThingResults.ToList();
return list;

Here's the Common.StreamElements() static method (thanks Sascha!):

public static IEnumerable StreamElements(string uri, string name)
using (XmlReader reader = XmlReader.Create(uri))
while (reader.Read())
if ((reader.NodeType == XmlNodeType.Element) && (reader.Name == name))
XElement element = (XElement)XElement.ReadFrom(reader);
yield return element;

Here's the code that returns the MVVM from the Controller:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using ThingSite.Controllers.ViewModels;

namespace ThingSite.Controllers
public class ThingBookingController : Controller
// GET: /ThingBooking/Create

public ActionResult Create()
return View(new ThingsViewModel());

And here's how it's used in the View to populate a DDL:

<%@ Page Title=""
Inherits="System.Web.Mvc.ViewPage<ThingSite.Controllers.ViewModels.ThingsViewModel>" %>

<% Html.EnableClientValidation(); %>

<td colspan="3">
Html.DropDownListFor(m => m.CurrentThing, Model.Things)
<span class="validation"><%= Html.ValidationMessageFor(m => m.CurrentThing) %></span>

So providing he more-or-less knows how to edit an XML file (he does!) my client is able to go into the XML file and adjust the list of things available for the DDL to be populated by. I reckon that's a pretty nifty technique, for lightweight use.

Thursday, 17 February 2011

Book: Agile Project Management with Scrum

This book provides an excellent coverage of how the Scrum software development methodology works. It introduces the key concepts then chapter by chapter reveals the intricacies involved in implementing the methodology by providing many, many, real world examples.

The author is one of the original signatories to the Agile Manifesto. He knows his stuff. Aside from the odd very dry joke, and perhaps the first chapter or two, the book does not deviate from the following pattern:

  • Chapter addresses one of the key features of the Scrum methodology (e.g. the purpose of the SrumMaster).
  • The chapter's introduction covers the overview of the concept and explains how the chapter will deal with it.
  • Two or three section (the "body") take us through some strategically selected real world examples, including an analysis of each.
  • A conclusion ties the chapter together, and ponders the various outcomes of the scenarios provided.

It's written in a predictable and confident manner. Exactly what you want in a book about project management and software development methodology.

Appendix A of the book along with the glossary is fantastic. It provides all the necessary information required for a quick start, and for reference material once Scrum is underway. Only thing left to do now is start using Scrum for real!

Title: Agile Project Management with Scrum
Author: Ken Schwaber
Link: Amazon
Tags: Project Management, Software Development Methodology

Wednesday, 9 February 2011

Book: The One Thing You Need to Know...About Great Managing, Great Leading, and Sustained Individual Success

As the title suggests, this book is partitioned into three sections - in the opinion of the author:

How to be a great manager
How to be a great leader
How to achieve sustained individual success

I found this book useful as it clearly defines what the core competencies of a "leader" and a "manager" are; which is something that I have not found elsewhere as yet. Have to admit that some of what I read was news to me - I've realised that my role involves both. To spell it out, effectively managing is looking after your individuals and your team; helping them find success in their work and supporting them. Leading is about providing a vision for your constituents (team) which they can aspire to; painting a picture of what things will be like when the goal is achieved and being clear about what it'll take to get there.

The author introduces the concept of a "controlling insight". This is a succinct description of the one thing that stands out clearly as being the key to success in any distinct pursuit (for example, being a great manager). Each section starts by developing a hypothesis, then revealing the controlling insight that the hypothesis supports. From there each section goes onto explain how to use the controlling insight to your advantage in order to achieve success in that area.

I found the section on sustained individual success most intriguing. The author encourages the reader to cleave away the parts of their existence that they find dull or annoying and reclaim that space for pursuits that inspire them. He offers some clever techniques to do this mostly without disruption. Many useful concepts and approaches are covered.

The content is persuasive and inspiring. My one comment would be that there are a statements made that indicate the author believes that the phenomenon of religion is currently in the process of being phased out and replaced by the world of business and technology - I'll simply say that I disagree. Overall a very good book.

Title: The One Thing You Need to Know...About Great Managing, Great Leading, and Sustained Individual Success
Author: Marcus Buckingham
Tags: Leadership, Management, Sustained Individual Success

Tuesday, 4 January 2011

Book: Getting to yes: negotiating agreement without giving in

This book presents a technique developed at the Harvard Negotiation Project, in alignment with the Harvard Law School. The technique is called "principled negotiation". The technique can be broken down into four key tenets, as follows:

  • Separate the people from the problem
  • Focus on interests not positions
  • Invent options for mutual gain
  • Insist on using objective criteria

The book itself is divided into five sections. The first section dismantles and analyzes the traditional style of negotiation whereby each party takes a position and makes a stand on that basis; the negotiation goes back and forth until the positions are shifted enough so as they are closely matched. The author spends this first section setting the scene by saying that this style of negotiation is potentially dangerous - "don't bargain over positions".

The next section of the book deals with the method of principled negotiation in detail, and the four tenants, as listed above. This section goes into each tenant in depth, looking at the reasoning for this approach at a psychological level.

The third section addresses what to do in the situation where negotiations are complex or difficult. Introduces the concepts of BATNA (best alternative to negotiated agreement) and "Negotiation Jiujitsu" - using the energy of the other sides attack to develop constructive negotiation. It also looks at what to do if the other side is using "dirty tricks" (for example - extreme commitment, deliberate deception, etc). This section also covers an approach called the "one-text procedure", whereby a third party is enabled to step in and broker an agreement. Worth noting that this technique is more-or-less the same as the requirements gathering process that a seasoned engineering consultant would go through with a client in order to develop a proposed solution that fits a specific business problem. The situation where negotiation procedure itself is negotiated is examined - doing this is encouraged, if for example, the other side is using tricky tactics. This is probably the most useful section of the book as it's more-or-less about putting the theory into practice.

The fourth section is the conclusion - it's only a few pages long. Covers the fact that most of what is presented is understood by many people already, that the content of the book is only useful if put into practice and that negotiation isn't about "winning" but about mutual agreement.

The final section deals with "ten questions people ask about 'getting to yes'". This section is itself broken into four sections; questions about fairness and "principled" negotiation, questions about dealing with people, practical questions, questions about power.

Useful quotes:

"If you want someone to understand your reasoning, give your interests and reasoning first and your conclusions and proposals later".

"Where disagreement persists, seek second order agreements - agreement on where you disagree".

"It will be easier to reform the negotiation process than it will be to reform those with whom you are dealing. Don't be diverted from the negotiation by the urge to teach them a lesson".

"A clever strategy cannot make up for lack of preparation. If you formulate a step-by-step strategy that is sure to knock their socks off, you will run into trouble when they come to the negotiation wearing sandals".

Title: Getting to yes: negotiating agreement without giving in
Author: Roger Fisher, William Ury and (for second edition) Bruce Patton
Tags: Business, Negotiation, Analysis

Migrating (and Open-Sourcing) an Historical Codebase: SVN-to-Git

I have a SVN repo on my local machine that I have been shoving stuff into since before I knew how to use revision control systems properly (...