Microsoft bid to buy Yahoo

It has been in the rumor mill for a while now that Microsoft was seeking to buy Yahoo. When there is sufficient smoke there seems to be fire and now the deal is officially proceeding. There are reasons for it and reasons against it. Apparently Live has not pulled in the traction that Microsoft wants and the desire for ad revenue and internet traffic control as a business model is

Google brings up some interesting points on the combination having more webmail and portal traffic than anyone else and Microsofts track record of following the path of Embrace, Extend, Exterminate when it comes to competition. But that input from a competitor is unlikely to bring about any sort of block of the deal. In fact some reports are even suggesting that the deal could be good for competition.

I am not 100% decided on the deal and it's positive or negative effects. Microsoft has a long record of proven execution and when they really set their eyes on something they can make it happen. There is a wide range of incredibly bright people there that when unified to a cause can deliver. The big change that I see though is in release management. Microsoft has a history of classical software development with releases taking years and subsequent patches taking months. In the internet world, and Google is a great example of this, change is constant, the ability to roll out new versions and try new approaches every week is key to success. This will be a big change from the default Microsoft dev approach. Will this Agile development change cross over into Microsoft's standard products? Another one of those much discussed items, SAAS Software As A Service suddenly becomes a lot more of a potential reality. To me this is the real reason for the desired purchase. Ads and Eyeballs are great to monetize and transform what Microsoft has done for a long time.

No matter what finally happens, this aught to be fun to watch.

Do you sleep work?

Have you ever gone to bed wondering how you would solve a difficult problem and dreamt up the answer? Apparently you are not alone. A recent survey found that 51% of those surveyed dreamed about work and nearly 70% of those put those dreams into action.

I have always slept with a notebook and pen on my night stand so that I could write down what I thought up while not sleeping or dreamed about. It is interesting to me how many people apparently do the same.

This is of even more interest when you think about it in terms of the "work 40 hours" credo in Extreme Programming. (Really more of a manage your spikes in hours and avoid death marches but I digress). The core of the reason behind that is if you are well rested and fresh you do your best thinking and are best equipped to handle what gets thrown at you.

So next time you have a tricky problem to work out, think about it before bed, write it down as a checklist to complete (leave it on the paper so you can actually sleep) then dream up an answer. (Remember you are still limited by the fact that you won't sprout wings extra heads or anything along those lines so it is likely best to discard those dreams... in fact probably best not to talk about them either.)

A case for the Designated Scapegoat

Have you ever considered why it is that when we consider systems we assign it attributes such as he or she or "misbehaving" or otherwise letting us down? I have. Why you ask.... darned if I know, I have a lot of random things float through my head and some of them are actually are entertaining. Hopefully this is one of those.

It seems that we as humans have a fundamental psychological need to explain things. So in order to explain them we put attributes either internal or external to explain why things happen. Maybe it is because from the age of "really small" we ask why? (and those of us who have children know the number of times we answer that question becomes numbing.) In psychology this is referred to Attribution Theory.

External attribution is things like "the devil possessed the machine and crashed it" or the ever popular "the data center is on a burial ground of some kind and it causes the servers to crash". It may not be true, but it helps us to deal. Or certainly to laugh at our misfortune.

Internal attribution is, in essence, blaming yourself. The easy example is things like "I am a sinner, please forgive me." We see this a little less in technology though it does pop up as well with the occasional person who perpetually places blame on themselves.

This fundamental psychological need is why I am suggesting the role of Designated Scapegoat on all projects. If a designated scapegoat is assigned at the beginning of any project we can simply move on to the fixing of problems since don't have to waste time in meetings deciding who or what is at fault. All of the posturing, political planning, set up, stonewalling, denial etc can cease and we can simply move forward. All blame can preemptively be assigned to the Designated Scapegoat and productive work can begin immediately. My experience with this role suggests that your Designated Scapegoat should be someone who is generally a good natured, understanding and who everyone knows in their hearts is beyond reproach.

Imagine how instead of a two hour meeting where people discuss why it is not their problem you start the meeting off with "Gee Chris, that was a mess up, I can't believe that you crashed the servers across the globe all at the same time." Chris then responds "Yeah, you know in Project Manager school we learned that the best way to crash a system is to push the button really hard, right in the middle." Then blame and attribution discussions are done and conversation can move to actual observed behaviors and problem resolution. What a time saver!!

So as a productivity aid for your next project assign a Designated Scapegoat up front, save yourself from Attribution Theory and all those unnecessary meetings. Focus on fixing problems, root cause analysis and long term fixes. Jump right past the blame game with this easy step.

Nothing gets done till nothing gets done - Woehlke's Law

What a provocative thought... nothing gets done till nothing gets done. This law is really more of a postulate or a theory then an actual scientific law as I don't believe any mathematical proof has ever been done. That said, it is one that has a lot of circumstantial and experiential evidence piled up towards it being the truth.

We have all been on projects where we know going in that the right [Resources, Timeline, Staffing, Education, ...] is not in place for the project to be successful. But we march on and because we all want to do a great job we try our hardest and keep the worst from happening for a long time, sometimes succeeding despite the obstacles and sometimes not failing until very late. What Woehlke is stating in this is that in order to get management attention and get the resources that are truly needed to be successful a problem needs to be evident.

A few quick reads on Woehlke's law -

• The Nimble PM has a nice article on Woehlkes law starting with the quote "Project managers will not get the staff they need so long as they muddle through with overtime, ulcers, and super-human effort. Only when deadlines are missed will senior management approve the staff who, had they been available at the outset, would have prevented the missed deadlines"
• Cutter had an advisor article in 2005 where Donna Fitzgerald made some great points about how to avoid getting caught in the trap and how hard it is for most of us over achievers to really understand what this law means.

What do I think this law means? If you look at a project and know that it can't be successful you need to prove it. Not with whining and bellyaching. If you go to management with a story of how "this will be really hard" you will get a reaction of "well duh, that's why we have you, our gifted team on this project". Rather you need to have "Data in fact". Set up tests to show where performance is and what would be needed to mitigate it. Set up early aggressive iterations to show a realistic rate of development. It's all about risk mitigation... if you can show where the real true risk is then you will get help. If all you have is an intuitive "this is hard" you will be patted on the head and told to go try hard.

The PM who cried Urgency

Have you ever been working on a project that you have been told over and over is urgent the date that was initially given to the customer has to hold? The urgency from that initial swag date builds from a normal project to a high effort project, on to a difficult project and on to
a death march?

A critical learning that needs to be accepted is that the purpose of a schedule is planning, not goal setting. A common problem is the initial SWAG (or ROM) becomes the cast in stone plan when the only thing that everyone agreed to at the SWAG was that it was wrong.

A general rule of thumb that I have found to hold true when estimating a project with initial information is that it is good to a rough magnitude of +200% to -50%. (and how often it actually goes to -50% is... let's just say infrequent.) This really means that the estimate is really intended for planning purposes to allow budgets to be roughly planned and dates for initial thoughts to be formed for go/no go decisions.

The unfortunate reality though is that in many cases the initial SWAGs are taken as gold. Plans and dates are communicated around them and then, in order to make the dates that have been "communicated to the customer" the development team is forced to become a team of super-heroes running a death march to meet the date on something that may not have real value in the long term. One of the ironies that I recently read about is that in many cases the death march project is one that has little to no value to the business overall and it seems that the only way the project was worth doing was if it met the impossible schedule.

All of this doesn't change the fact that if a plan missed the date, it was a bad plan. In many cases we try to blame the performance of the team, environment, technical difficulties or other things but the fact remains the plan is what was incorrect. It doesn't really matter why the plan was incorrect, it was. This means that we need to run performance checks earlier in the cycle. A post-project review is always a good thing but what if we did what needs to be done
up front?

While reading through various articles for this topic I ran across one on the Best Practice for Voluntary Overtime. It shows the correlation between an increase in pressure and productivity and then the corresponding decline in actual productivity when pressure is increased too high.
People are more productive and more creative and quality is higher when regular schedules are kept, planned and executed.

Drag Racing vs Rally Racing

Some of you that know me outside of my Uptime Blog posts know that I am a fan of Rally Racing. In part it is because I drive a Subaru so I was drawn to watch. (Yes, a blue STi with the handle on the back so that God can reach down and shake me when he thinks I am doing something dumb is mine.) But also I like Rally racing because it takes a real world car (granted, they gut the interior and up the strength a bit on the components) and drive it like fiends through corners, over dirt roads, through snow and over jumps. It is a real test of driver abilities and a lot of fun to watch or even play on a game console.

So what does this have to do with technology? It has to do with optimization and how optimized you can make a system, either people or computing. If you take the example of a Rally car they need to have horsepower yes, but that is not enough. You need to have torque, suspension flexibility, handling adjustability the ability to turn and to stop is just as important as the ability to go. In one stage you may be racing on a mostly strait asphalt road, in the next over a switch-back 180 degree turn infested gravel road through a forest. The ability to handle that change is very important to build into the car. Conversely if you look at a drag race car the need for handling, turning, even suspension decrease. What you need is horsepower and pure strait line speed (and hopefully the ability to stop, though if you look at some of these cars a parachute is what is used). How boring.

I maintain that business is much more like a Rally race than a Drag race. You never know what curve a competitor is going to throw at you next. The ability to handle those curves, stop on a dime, turn in the other direction and then go full bore ahead again is critical to business survival.

Sometimes though we seem to optimize our ability to go fast and go strait. We focus only on the immediate goal in front of us. Cut out items that are not critical to our achieving that strait ahead goal. We optimize our "people load", "trim the fat", etc. to keep everyone as utilized as possible moving towards the strait line goal. Then a change comes up... and we discover we can't turn as fast as when we started and we are surprised to find we even have a problem changing our direction simply due to momentum.

This is why things like Non-Functional Requirements are critical to a project and a companies long term success. They maintain the ability to turn and stop and give the slack necessary to allow a shift one step to the right. If we are all pushing so hard to go forward in a strait line even adjusting slightly to the side is difficult. In planning this is Risk Management. It's accepting that planning "if all things go right" is not going to really get you there.

Getting the right strategy means you have to assume your competitors are damn good, or at the very least as good as you are, and that they are moving just as fast or faster. When it comes to peering into the future, you just can't be paranoid enough.

- Jack Welch