Getting to Yes

Getting to Yes is the classic guide to principled negotiation.

It has a very simple structure, and is built around the core thesis that there is a better way to approach negotiation than the simple positional style.

Positional bargaining is very easy to do, but often not effective. It may win the day in a single encounter, but is often a difficult experience, and considered harmful to building long-term relationships.

The authors outline this problem, covering the difficulties that can arise from both the hard and soft styles of positional bargaining. They put forwards the idea of principled negotiation being a better long-term solution to achieving the best outcomes.

After the introductory chapter, the main section of the book covers the four main pillars of the approach:

  1. Separate the people from the problem
  2. Focus on interests, not positions
  3. Invent options for mutual gain
  4. Insist on using objective criteria

It then moves on to cover some difficulties you may encounter in attempting to implement the method, before finally answering a series of more detailed questions.

The book is very good it’s very much worth the time to read. Some of the examples have started to show their age, but the ideas in the book are just as relevant and important as when they were first published, over 30 years ago.

 

Advertisements

Reinventing Organisations

Reinventing Organisations, by Frederick Laloux, is a “Guide to creating organisations inspired by the next stage of human consciousness”.

I picked up the Illustrated edition following a recommendation in a talk at Agile London. It’s a very quick and easy read, and fells like an excellent introduction to the ideas presented in the original book.

It begins by outlining various types of organisations, and the reasons that these different styles arose. Red are the first type encountered, impulsive and tribal, think the Mafia or street gangs. The innovations these organisations initiated were the division of labour, and a view of top down authority.

We then move to amber, conformist organisations such as the church or military, with replicable processes and stable organisational charts. Orange orgs are the familiar corporations of today, achievement focused, caring about innovation, accountability and the meritocracy. Then on to Green, a pluralistic view, with empowerment, values driven cultures and a focus on stakeholder value.

Laloux’s argument is that, whilst many organisations exist in broadly these four camps, with real organisations taking aspects of all four, there is a new, fifth style to consider.

Teal is the evolutionary approach. An organisation where an individual can grow and be their whole self, can find a true and valuable contribution based on a feeling of inner rightness, and can fundamentally make a difference.

By following the approaches and case studies outlined in the book, it is possible to create organisation with a true sense of purpose, really bringing transformation to the world.

It’s an interesting perspective, and it brings a great new set of terms and techniques to the discussion. As no current organisation is fully Red or Green, no one setup will ever be fully Teal. It’s an approach to follow, and there will be valuable opportunities for anyone brave enough to change their views to incorporate the fifth style.

The introduction book is extremely easy to read, and can be completed in one or two quick sittings. I’d recommend it to anyone interested in organisational change or growth, you’ll certainly have something new to think about once you’ve read the book.

 

 

Mobile Development

I’m developing a lot more for mobile devices these days, as I’m pretty sure almost everyone is.

Mobile reminds me a lot of the early days of the web. It’s become easy to be spoiled by the faster average connections and more powerful devices for the web. You don’t have that luxury with mobile.

Uncertain connections, data limits, browser incompatibilities and more all bring their own challenges. Familiar to you if you were working on websites ten years ago, but thanks faster connections, better standards support, and better development tools, we’ve been lucky enough to avoid the pain for a while.

Writing apps seems like the ideal way in to mobile development, giving a native experience on a device, but it is a losing proposition for most people, each platform supported is another fresh development effort, or a sea of not quite perfect versions generated from a tool.

HTML 5 and javascript mean that we can write our apps to target multiple devices very simply. Modernizr lets us use feature detection to customise the experience. The Chrome developer tools can show us how we are using memory and resources, giving us a good feeling for how our site will work.

These are tools that most web developers will be comfortable with, and they can be pushed to mobile sites with little hassle.

Remember how things were, and the compromises that we had to make, and you’ll be well on the way to successful mobile development. Work to minimise resource usage and system requirements, and you’ll provide a great experience for as many people as possible, which is your overall goal.

The Right Way

There is no right or wrong way to develop software. This is a controversial, but key concept to grasp.

What matters is that everyone working on developing a single piece of software agrees to use the same methods. They must pull together rather than pulling apart.

No methodology or practice works the best across all products, teams or systems. You need to find what works for you and yours, and then push to maintain that successful process over time.

Many people have written and talked about what worked for them, whether it is Scrum, XP or waterfall for delivering projects, or smaller and more syntactic decisions such as OO programming, functional programming, or even a particular coding style.

Don’t fall into a trap of a one true way. What is true for one person in one situation may not hold true for your team in your situation.

Once you find a method you can make use of, then you must by all means strive to implement the best practices and recommendations of others. There is little point in choosing to do something badly when you can choose to do it well.

Find something that fits, do it as best you possibly can, and good quality software will follow without fail.

Disposing Resources

When you are working with managed resources in C#. you can usually let the Garbage Collector deal with tidying up after you. Memory allocation problems that are familiar in the past with languages such as C are dealt with for you.

The Garbage Collector is not magic. First off you don’t usually control when garbage collection occurs. The Framework will initiate collection whenever it thinks it’s necessary. Sometimes you’ll go a long time between collections, but as resources begin to become scarce, it will happen more often.

You can call a forced collection, but it’s rare that this is  a good idea. The Garbage Collector itself will manage when collections need to occur. Forcing multiple early collections is almost always worse than letting the collection happen automatically.

The Garbage Collector cannot deal with unmanaged resources. The most common of these that you will encounter are related to database connections, and file access.

You should do two things when dealing with unmanaged resources. First off, wrap them in using statements. This ensures that the dispose method is called once you are finished with the resource.

The second thing to do is to make sure that your classes implement the IDisposable interface. This means that when the Dispose() method is called you have a chance to clean up your unmanaged resources, to prevent any memory leaks and ensure that the Garbage Collector can do it’s job.

There are a lot of further complexities to the Garbage Collection and memory management, most of the time you won’t have to worry too much about them, but it’s good to know the basics for the times you do.

Connections Per Hostname

There are lots of ways to improve the performance of your website, some are easier than others to implement, and some will have a greater or lesser effect.

One potentially easy win is to limit the requests made from a single hostname. Most modern browsers will create up to six requests to a single host. If you are serving all of your resources from the same domain, e.g. http://www.mydomain.com then the browser will request the first six, wait for them to load, then start requesting the next six.

If you split your resources across multiple domains then this queuing will not occur. As a simple improvement, load your static content from content.mydomain.com (or similar). This means that your dynamic pages will load, and start pulling your static content very quickly, rather than waiting for all the requests to the dynamic pages to complete.

This splitting out also leads to other possible benefits. You can put your static resources onto a CDN, so the performance of your content.mydomain.com will be drastically better than if served from your own servers. It also allows for further tweaks, this domain can be configured to be cookieless (you’d use mydomaincontent.com in this case). That would save sending cookies for static requests, which you should never need.

This is a quick improvement that should be simple to setup. The major effort is in configuring the domains correctly, and planning your system to allow for these split domains. Once you’ve done that, you’ll increase performance for everyone using your site, without having to improve the code that drives the system.

 

 

Breaking Changes

Making a breaking change is just about the most destructive thing you can do in a software system. Doing something that means everything that went before is outdated means you are going to severely limit your options for the future.

A breaking change is one where the system has changed in such a way to mean you cannot go back to the old version.

If you can’t go back to the old version, then you need to be certain that your new version will work. That may sound pretty simple, but it’s always harder in practice.

You should design your system to reduce the number of breaking changes, and to allow for the simplest methods of coping with a breaking change.

When you have the choice of a little extra work to make a smooth transition, give enough weight to the prospect of your change failing to estimate correctly. Don’t just assume that everything will work and you can always roll forwards.

If you can isolate your breaking change to a single layer then you can split your deployment to several pools. You need a way to send users to the new or old code in a reliable way, otherwise this will not work.

If you design ahead of time to take account for the breaking changes, then when you finally need to make one it won’t be as painful as it may have been.