Monthly Archives: December 2008

Ding dong print is dead – almost.

I read this post over at Signal vs. Noise (the 37signals blog). Over Christmas my parents came down to stay with us. Despite it being a busy time my father still took the time to go and get the paper and read it.

This tells me that print isn’t quite dead, but it must be close. I certainly could have acquired most of the information my dad was reading online, and not all just from the online version of the paper. There are two important functions that a newspaper provides – news gathering, and news presentation.

On the news gathering front there are still reporters out there gathering stories and sending them to print, but they tend to be local issues. The big stories from overseas already come through specialised channels such as financial networks or AAP. Eventually the “local” stories will be gathered more democratically and content will be filtered based on our own local preferences (your location is just one aspect of your personality which is used for filtering).

That leaves presentation. Like it or lump it, some people still like sitting down and flipping through the pages of a paper. As time goes by these people will become less and less, but the question is – what do we do in the meantime? Will the news gathering function of news papers survive, and is there enough regular subscribers to news papers to fund production, distribution and what is left of old style news gathering.

Bill McCarthy: List transactions…

Bill McCarthy has a very cool use for extension methods where he manages adds/removes against IList(of T). Basically he builds a transaction log of all interactions against a list that can then be applied later. This is useful for avoiding exceptions whilst iterating over a list and modifying at the same time (most enumerators have a problem with this).

Neat – wish I had thought of it.

Documentation vs. Covering Thy Arse

There is a difference. This is a (short) post/rant that I’ve been wanting to write for a while. Something reminded me of it last week but the real driver for it was something I saw earlier this month that I was so disgusted at that I had to get up and leave the room.

In normal circumstances documentation and I get along. I consider myself a fairly decent communicator so if I can see a positive communication outcome from producing some kind of documentation I’ll usually be able to pull something together that gets the message across. Even documentation that is designed to help crystallize your own thinking (communicate to yourself) isn’t a problem.

However – where I draw the line is documentation whose sole job isn’t to communicate but rather to ensure that a decision can’t be pinned on you.

Effective organisations distribute decision making to the leaf nodes and healthy participants take that responsibility on and use their own judgement to figure out the scope of their decision making authority. Sometimes however you come across people who see their job as ferrying documents from their team to their managers so that their managers make all of the decisions. That may be appropriate in some instances but if all you are doing is that and deferring all your decision making responsibility what value are you really adding?

So – if you are working in an organisation and you find yourself writing documentation to cover your arse instead of communicating then take a long hard look at yourself. Business is about (calculated) risk. You need to manage the risk that you take on and you don’t just do that by abdicating all responsibility to the next level of the organisation.

Use documentation to communicate, not to cover your arse.

The only technology trend you need to be aware of.

This link was passed around at work today. It discusses one of the oft-touted aspects of cloud computing which is auto-scaling dynamically where the host platform is “aware” of the stress on the application and can dynamically allocate additional resources (often in the shape of more virtual machines) to handle the load.

As George Reese (the author of the article) quite rightly points out you can remove some of the need for this auto-scaling capability by doing decent capacity planning. A laudable goal and I agree whole heartedly.

Everyone’s dream is to wake up each morning and find their web-sites unavailable because their application crashed because the transaction logs on the database server ran out of disk space writing all those credit card authorisation numbers – but it is just that, a dream. When most sites get “slashdotted” its because someone has posted Photoshop pictures of Paris Hilton being spotted at an open source convention hanging out with Richard Stallman.

Features, Benefits and Trade-offs

What George Reese is pointing out is that for the majority of applications auto-scaling won’t be a lot of use to you. The reason for this is that unless the platform intrinsically knows how your application is stressing, adding a server might not lead to much more than you paying more for your hosting.

For most applications, auto-scaling is just another feature shown as a bullet point by the hosting provider.

On the other hand, there are classes of applications (like public video encoding sites) which could benefit from the additional processing capacity. These applications can really benefit from the combination of EC2 and S3 where a user uploads a video in its native format and it dispatches to the next available server to process the video. When a server is idle for more than a few minutes it simply shuts itself down (maintain a minimum pool unused resources in reserve ready to jump to action immediate).

For these applications auto-scaling is a benefit – and its all about knowing the difference between a feature and a benefit.

In reality you would probably be best served adding end-user features to your application or coming up with a standard server image which you can manually provision so you reach the middle ground between auto-scaling and “oh crap, my site is going to be offline for three days until I can get another server configured”.

I’ve always wanted to write a Fork bomb for EC2 though 🙂

Technology Trends

Stepping back for a moment, the whole discussion does make me smile just a little bit. The industry is undoubtedly on a bit of a “cloud”-kick at the moment. It is so typical of IT to have bandwagons that every jumps on, the natural clustering behaviour which draws us together behind visionaries and leaders is part of what makes us human.

I don’t have a problem with that, it is in fact a fairly natural reaction to a number of forces that have been in play for quite some time in IT and its fair the say that we are truly changing the way that we provision and pay for computing services (maybe IBM was right?). It is all a bit cyclic though and if I was to design technology trends as a sequential workflow it would look something like this:

  1. Someone invents a technology.
  2. Years pass because everyone is too busy looking at the hot new couple Paris and Richard.
  3. Someone uses technology (see step 1) to do something interesting.
  4. Cult is formed around this interesting use of existing technology (see SOA, REST, and now cloud-computing).
  5. Cult manages to convince industry journalists to write about it (it was easy because Paris and Richard weren’t interesting anymore).
  6. “Enterprises” adopt it but apply their own special spin which either misses the point or renders the approach useless.
  7. A bright spark observes that “some people don’t get it” and blogs about it, starting the wave of negativity.
  8. Early adopters jump off the wave and look to the next big thing hoping that no-one remembers they were a member of the technology cult.
  9. A few years pass.
  10. People still use the technology because it was useful “some of the time”, just not “all of the time”.
  11. Goto 1

Right now I think that cloud-computing is somewhere between 4-6, I’m hoping that this wave combined with a renewed since of fiscal responsibility wipes away some of the “old think” around IT services delivery before the cult is exposed.

Are you an in-betweener?

In my last post about communicating risk I introduced the term “in-betweener”. I’ll wait for the grammar nazi’s to correct how I’ve put that word together but the idea is that an in-betweener is someone who exists in an organisation between those or really benefit from some kind of activity and those who execute that activity.

Those who execute an activity are often rewarded on a time and materials basis because they provide professional services. Those who benefit from it usually derive benefit indirectly from the activity by gaining some kind of business advantage.

The question is – how do you tell if you are an in-betweener? Well – the first thing to note is that it isn’t only the top level executives in the organisation who benefit from successful activities – middle managers _can_ be rewarded by business activity – this is where those bonuses come in.

So are you an in-betweener? The easiest way to tell is look at your actual behaviours. Do you spend a lot of time producing documents that prove that “its not your fault” by deferring all the decision making to someone else. If so – you are an in-betweener. Some people are happy with this role and do it well, but its not for me.

If you want to get out of that in-betweener status then you need to change the risk reward ratio. Do this by talking to the invested decision makers who often hold the purse strings about being rewarded for successful project implementations and removing any incentives that you get automatically just for breathing in and out.

Even if you can’t negotiate a better deal, being an in-betweener to me seems like a pretty sad existence. Why not just take a few risks – crash and burn if they are realised but enjoy a boost in credibility if they come through – after all not all rewards need to be monetary.

Communicating Risk

The software development business is all about managing risk. If we look at Scrum for example, it promotes prioritising the product backlog in descending value order so that the highest value items (based on the stakeholders own estimation of value) are at the top, and the less valuable items are down the bottom. The theory is that the project might get cancelled anytime and you want to be able to get the value out of the last potentially shippable product increment.

The true estimate of value factors in a few different things including the timeframe in which a particular feature needs to be delivered in order for that value to be realised which is why software developers so often find themselves having the conversation with the client about how long something will take to develop – which brings us back to that old chestnut of estimating the effort around a particular development task.

Easy Estimates

The ease of producing an estimate depends on how much information you have at your disposal. When I decide to drive a car from Melbourne to Sydney I have some basis for estimating how long that is going to take. The distance from GPO to GPO is about 900km, so assuming that I am travelling at 100km an hour I should be able to do that in 9 hours.

In reality it will take more than 9 hours because I know that it takes nearly that long to drive from Melbourne to Canberra including some modest rest stops and dealing with traffic on the Melbourne end of the trip. So using a fairly reliable indicator of distance and some prior experience I would take about 12 hours because. My estimate is based on prior experience and some analysis of the gap between my prior experience and the current requirement. I know that I can fairly comfortably get from Canberra to Sydney in about four hours and there is gains to be had over my previous experience because I don’t need to drive into Canberra but instead stay on the Hume highway.

Difficult Estimates

It is the difficult estimates that introduce risk into a project. A difficult estimate is one where you have no basis for estimation, or your prior experience in a particular area is so light on that it may actually be misinforming your estimate.

The key to dealing with difficult estimates is spotting them in the first place and having the courage to communicate to stakeholders that you are having trouble coming up with a reliable number – after all, the reason they are asking you for a number is they couldn’t come up with one.

My advice is unless you can get comfortable with the estimate, don’t provide a low ball. Instead figure out how you could find out more. In software development this often means doing some prototyping work to explore the problem space. Prototype work in software development should be time-boxed to keep the pressure on. It isn’t a bad thing if you fail to produce a prototype within the time allocated – that fact alone tells you that there is indeed significant risk.

Who understands risk?

In my role as a consultant, one of the saddest things that I see is long chains of middle management between invested decision makers and the operational coalface of the business. What I mean by invested decision makers is those people who actually stand to loose or gain something in equal measure based on the success and failure of a project.

The reality is that most players in a business stand only to loose by the commencement of a software project because the total reward they get from success is a pat on the back, but if they fail they will likely get a sizable hit on their credibility. This in-balance drives their participation in software projects. The more removed these in-betweeners are from the actual rewards of the project – the more obvious this behaviour will become until you reach operational level of the business where day-to-day reality corrects this thinking pretty quickly.

Covering Thy Arse

I almost get physically ill when I see people blatantly arse covering. If you aren’t good enough to perform tricks without a safety net then you probably shouldn’t be performing them. Sadly, it all comes back to dealing with people who have a major imbalance between risk and reward.

As an example, in a typical external software development vendor relationship an in-betweener will most likely drive the vendor to produce a fixed price estimate. The reason for this is obvious – if it is a fixed price estimate then even if some of the project risks are realised at least their organisation won’t pay any extra money. They are simply trying to swing the risk : reward ratio closer to neutral.

Talking to the Invested Decision Makers

If you find yourself as a software vendor being pushed to provide a fixed price estimate for something that contains significant unknowns you need go back and understand what business you are in.

Software vendors aren’t in the business of accepting the risk of other companies. If you provide professional services the risk you carry is the hiring and retention of staff and their overall technical competence. If all of those things are good then you should be billing time and materials but all the time helping the customer understand the risks that are inherent in their business.

If you are hitting a wall of in-betweeners about the fixed price thing then your only option is to elevate the discussion to the invested decision makers. Sometimes an in-betweener will surrender their contact details willingly, other times they may protect them with the mistaken belief that elevating the conversation to that level will somehow make them irrelevant. You may need to have a very frank conversation about risk and reward with the in-betweener to get them to see that elevating the conversation is actually a good thing for them.

I’m not a sales person, but these are just observations that I’ve made after being around for a little while.

Wrap Up

I’ve gas-bagged for long enough now, but I want to come back to that key point around communicating risk. There are two aspects to it. First you need to understand the risks to produce estimates – are they easy estimates or difficult estimates? Make sure you understand the difference between unknowns and things that are likely to be impossible. Once you have an understanding talk to the invested decision makers about the nature of the risks in conjunction with the estimates that you already have.

Software development; it is all about communication people!