Friday Link Day

Oracle offers to buy BEA for $6.66 billion. Outside of the immediate 666 references to evil this does have several interesting implications to the software world. It has been no secret that Oracle has been trying to buy RedHat and JBoss and this puts yet another point of pressure in that series of events and the two worlds of Open Source software versus Corporate Sold software.

Airlines agree on check-in by cell phone. The headline alone on this one caught my attention. There are many implications to this possibility. I have long been jealous of the fact that non-US based cell technology is farther ahead and this is yet another item that will drive the laggard gap.

And last links but not least links, here are a few fun links that were shared with me from my JanaRSS feed. Google Smackdown, a query tool to see which phrase or words appears more across the web. Soople - an easy expert search, with a collection of tools in easy format also built on Google tech.

Yay Friday!

You wouldn't move without a destination for your stuff...

Consider this story. You gets a transfer to a new city. It's a great opportunity, great job, benefits and salary. The new company offers you a relocation package where they will help you with housing, selling your current home and everything. It all just falls into place, your home sells in short order and you are ready to go. You pack up all of your belongings to move out to your new city. Couches, Televisions, Cars, Toys etc. Everything is picked up by the movers put into the 18 wheeler with care and zooms off down the road. You get on a plane and head to your new city, ready to get on with your life. You land and are ready to head to your new home and realize you don't have one. You never set anything up. No new home purchased, no apartment, nothing. Oops. Your belongings have no where to go. You call your company and tell them they need to get you a house and... what do you know... they just laugh.

Ok... so this story is a little strange and something you are probably thinking "I wouldn't do that. What kind of idiot would pack everything, be ready to move and not have a destination?" Not many right...

Actually you would be surprised. While not a house and a couch we get requests all the time for a home for an application. An application that has to be delivered in just two weeks! This is when the inside voice starts to emphatically state "Failure to plan on your part does not constitute and emergency on mine." Of course that is the inside voice and not the outside voice.

What can you do about it? If something is being built, know where it is going to go. Don't just assume, know. Know what the requirements are up front, what the application will run in, on and through. It seems obvious that you would want a planned home for a product but when you get busy coding and building those types of things are easy to loose track of or to assume that "someone" is taking care of it.

Will there be a claxon when it's time to panic?

When asked what the gist of what we do in Engineering is I generally have to think about it because it differs given different situations. In some cases it's about technology and how it is applied. In some cases it is about ramp up plans and safe rates of growth. In some cases it is about algorithms built for scalability and consistency versus short term function. At the heart of all of these things though is Risk Management.

Risk Management is an art and not a science. If it was easy to tell everything that would go wrong then nothing ever would. So since we don't have perfect information there is a balance that needs to be achieved between safety and progress. We need to look at the risk, its potential cost (PLOP factor) and then weigh all of this with previous experience and make a call to be later judged as a good call or a bad call. Or... if everything does what it is supposed to then it's a decision that just fades into the background.

So when you encounter a risk what do you do with it. It actually boils down into some simple choices. A Cutter article a while ago defined out a basic framework that I wrote on a sticky and refer to now and then as a framework.

1. Accept it - It's a risk. It's understood. There is not much you can do about it so move on with life and be prepared if it happens.


2. Avoid it - Sometimes a risk when found can simply be avoided. The ones that I think of in this regard are running a volume test in an overlapping time window with a system change.


3. Transfer it - This is the get someone else to do it approach. To successfully use this approach the other party needs to be aware that they are getting the risk (no email volleys please). This makes sense when there is someone who is better qualified or has a business to handle the type of thing you are dealing with. It may cost money but mitigates the risk.


4. Reduce it - This approach is commonly used when it a risk we have to face and work through, but can't directly transfer it or otherwise avoid it. A good example of this is a ramp up plan that is overly optimistic or doesn't account for transition. We mitigate this risk by reducing it and slowing the ramp down in order to make the problems smaller.

While not my own list I have thought that this provided a nice structured way to think through risks and what you need to do. If nothing else it helps in the acknowledgement that there are risks, even if we do choose to not do anything we need that to be a conscious choice.