Having forgotten my phone today and not having constant access to email made me remember an article I ran into and had to share. Several key things contribute to burn out but one of the major ones of today's business world is email. So here is a fun little exercise.

1. Think about the number of emails that you receive in a day...


2. Now think about your average response time to those emails...


3. Now think about how many of those emails are really critical, high value things that need immediate responses...

Scary isn't it? Recent findings even shown how the level of access provided by things like Blackberry's and other email devices actually make you dumber by as much as 10 IQ points with close to drug addiction levels.

To address this immediate brain drain one of the things suggested is to set aside specific times to answer emails. Don't let your email be a task list. There are emails that are urgent and there are ones that can wait. Prioritize.

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.

The PLOP Measurement

For some time I have somewhat tongue in cheek referred to the way that we prioritize work as the PLOP Measurement method. (Patent Pending). In the unending quest to educate and inform here is a quick definition of the PLOP Measurement Method and how you might apply it to your work.

Contrary to what you might initially think PLOP is not just how big of a splash will something make when it falls into the water. PLOP is much deeper than that. PLOP is short for Prioritization by Level Of Pain.

PLOP has gone by many names, methods and approaches for years. Risk Management, Concern Logging, Caveat List and many more have been used. What they all boil down to though is exposing and managing efforts with an acceptable level of risk.

With the PLOP method issues are judged and prioritized by their potential to cause pain. Pain can be felt in any of a number of ways:

• business impact
• cost of outage
• size of effort
• number of systems touched
• likelihood of customer impact
• potential severity level
• inconvenience of time for roll out (tell me you don't look at something that needs to be released in the middle of the night as higher risk than something that can go in during the day)

Some might dismiss this as a subjective measure and make accusations of pessimism and paranoia. While the paranoia point might be correct, I find as a pessimist I am rarely disappointed. It's something that we do whether we acknowledge it or not. It may not be a hard number but that sinking feeling that you get in the pit of your stomach is usually a really good indicator of how bad the PLOP rating should be. The trick is listening to it and taking the right actions rather than slowing everything to a crawl.

Overtime is a productivity killer

This post may not be one of my most popular with PMs around the world but here it is anyway. Overtime, in the long run, does not help a project. When the numbers are run (and boy do productivity numbers get run...) it turns out that work that is done when mapped out with a scatter diagram across many different projects is essentially the same. [See Slack pg 64, it's cheap in paperback and well worth the read] The work that is done is the same per day... not per hour.

Intuitively this may initially seem strange if not outright wrong. How could a team that consistently works 50 or 60 hours a week end up with the same productivity as a team who works 40 hours each week? The answer lies in the long term effects of overtime, not the short term spike in productivity from a controlled burst. Controlled bursts really can be effective, as long as they are just that, controlled bursts.

Overtime itself is not an evil thing. Many are the stories in corporate lore of the team that pulled an all nighter or pushed through that special effort over the course of the last week to deliver everything on time. Good managers, [project managers, people managers, senior individual
contributors] know when to pull the trigger on overtime to push things over the goal line.

The problem comes because this can be addicting. Both to the manager and the individuals. People like being super stars, like the accolades and recognition of being really dedicated. Believing this to be a great success without evidence to the contrary managers become dependent upon the push to get everything done. Rather than pushing back on scope, push on the people. It is an easier road and you don't have to worry about an unhappy customer. At
least not right away...

With pressure comes a bit more focus. That's a good thing right? Sure, when that pressure leads to cutting out unnecessary steps and trimming requirements that are not needed. But when that pressure becomes an unending stress to deliver no matter what, it starts to become noise.
People stay, because they see others staying. People work, because others work. But the real urgency and productivity goes down. Knowing that they will be there working at night, things get put off, people talk in the hallway, time is spent surfing the web, etc. Why not, they will be there later anyway.

There are of course many other costs to too much overtime, but this is just a blog and not a book, so I will give it a rest now that I have you thinking.

The principles of Tao Teh Ching in Software Development

You may be asking if I drank a little too much Green Tea to be comparing Software development to the principles of Tao Teh Ching but please bear with me on this one. Honest, it makes sense. (At least I hope it will after I write it down and it's outside of the world inside my head) First, the basic principles. (there is a lot more in the book as its a compilation of a good deal of Chinese Philosophy)

That which remains, is easy to handle.

That which is not yet developed is easy to manage.

That which is weak is easy to control.

That which is still small is easy to direct.

Deal with little troubles before they become big.

Attend to little problems before they get out of hand.

For the largest tree was once a sprout, the tallest tower started with the first brick, and the longest journey started with the first step.

Just as these wise words say, things are easier to handle early on. Once they get rolling or get bigger though many times there is too much momentum to control it. Just like a small snowball at the top of a mountain can become a massive avalanche so too can a small problem ignored early in development become a costly, potentially project killing problem later in the development cycle.

Releaseing early and often during software development makes sense. By focusing our teams on the first things that really matter we can focus our efforts on the things that make a difference. By focusing on the things that we expect to be hard we can ensure we have enough time to manage the risk associated with them. Identifying things early allows us to adapt our plans and make the best set of decisions.

My trip to the post office

I have been asked before where my inspiration for blog posts comes from. Sometimes its from things I read, other times it's from events that I am a part of. As a little window into why I blog what I blog I thought I would share one of my "triggers". A recent trip to the post office caused the trigger for my recent post on Process Engineering. Now... on to my rant.

First, a bit of passport news. The US Government recently decided that no matter where you go you need a passport to travel and come back. Not really that big of a deal other than that it hadn't been a requirement for Mexico or Canada, popular destinations for many people. This (of course to those who actually think) caused a spike in demand for Passports. (I found it hilarious that the website for passports had initially stated that due to unanticipated demand for passports there was a delay in processing. Now corrected to simply state processing times have increased due to high volumes. If you change the law to state everyone needs one... demand will increase. duh.)

I recently went to the post office to get passports for my family and renew mine since it expired this year. For my own there is a nice improved process where you can mail your existing passport, a form and the money required and they will ship it back to you. No lines, no muss, no fuss. (Although the page states you must apply in person or by mail, if you go in they will tell you to mail the form... what a great way to waste an hour in line.) You can also fill out the forms ahead of time to simply hand them in and make it fast.

However... if you do not have a passport here is the current process.

1. Go to the post office. There are a limited number of post offices that do this so check first. (This was the least stressful step in the process)
   [10 minutes - Post Office is close, easy drive]


2. Stand in the Passport line. It is important to note that you will need a photo of your head. These can be purchased for cheap at Costco etc or $15 at the post office. (How convenient. Of course photo or not you all stand in the same line.)
   [60 minutes - 3 people ahead of my family. 5-7 photos taken, Forms filled out for each person, 1 line, 1 person doing everything]


3. Talk to the Passport person. One passport handled at a time, stapled Birth Certificate (actual certificate) to form along with check for Passport.
   [10 Minutes - 5 minutes per person w/ 2 kids]


4. Hold up right hand and swear that the form is truthful. (Humans are apparently unable to lie with their right hand up. Practice in the mirror)
   [2 Minutes - 1 minute per person w/ 2 kids]


5. Receive ticket to pay post office for service
   [1 minute - Only one ticket for the group, process has been "optimized"]


6. Stand in Post Office line to pay Passport ticket. This is the same line as people buying stamps, weighing packages and otherwise wishing they were elsewhere. (Most of the articles have long since archived out but if you remember back to early this year some 3700 post offices improved their turn around times on lines by removing the clocks from the walls. Really.)
   [2 hours - really it was just 45 minutes but I have a caveat. Based on the rate of line movement for the people who were in the "passport room" ahead of us in the passport line, they waited 2 hours to pay. However, it was nearly closing time and 3 extra people miraculously appeared and chewed through the line so they could go home on time.]


7. Return proof of payment to the Passport Office. Receipt for payment needed to be shown before the paperwork would be put in the "to be sent" pile. Now, at this point most people are fed up enough that they just walk in the door and show the Passport person the stub and don't wait in the line so I guess you could say this was "efficient".
   [5 minutes - Had to wait to get attention for the drop as the Passport person was taking photos]

All totaled this accounts for (10+60+10+2+1+45) 128 minutes of my actual time. Just over 2 hours. Considering that we had everything filled out, ready to hand in and walk away without additional photo time and we had an accellerated exit because the "pay line" wanted to go home this is truly disturbing. The people who were in the Passport office when we got there were there for at least 4 hours. If this was a private entity they would be pushed out of business.

Opportunities for improvement abound.

• Have two lines - One for photos and one for completed forms with pictures. This would have cut out at least 60 minutes.
• Have a machine take the photos with the cost of credit card freeing the person to just deal with forms. If people can't get it right they can do it again.
• Transmit automated digitals taken since the Passport office is printing them anyway just attach that.
• Give People the forms to fill out and they don't get in the line until they are done. This keeps people will filled out forms from waiting for people to remember where their mothers were born.
• Insist on pre-filled forms. They are available on the internet. A terminal could be set up for filling out and printing.
• Pay in one place. Let the Passport office collect all of the fees. This would cut out at least half of the time for most requestors.

If these suggestions were put in place my 2 hour passport ordeal would have been a 5 to 10 minute paperwork drop. I would have nice things to say about the easy nature of the excessive instead of wanting to post about Process Engineering and needs for improvements.

RANT DONE.

Know where you are so you can go where you want

Aside from the desire to make a pithy title I did want to blog a bit on Process Engineering. A quick Google define: provides

Process engineering is about applying engineering approaches, techniques, and
tools to the construction of Process Models. [Rolland1998]
en.wikipedia.org/wiki/Process_Engineering

Aside from sounding very technical and confusing this definition really does capture the gist of what Process Engineering is about. Looking at how you do things and applying techniques to improve it. This could be any process really, from how you save a few moments by putting your toothbrush in a cup on the right side of the sink to how data is pre-processed for correctness before loading into the system slowing down initial loads but saving time on back-outs.

Why is Process Engineering important? I am glad you asked. It is important because without having an understanding of what we currently do we cant' figure out why we do it and thereafter improve it. For example, I was involved in a process improvement initiative once where we boiled a process that originally contained 30 steps to one that had 5. How? We figure out that each step (there were really only 5 major actions in the process) was supported by it's own set of steps that validated the information received from the previous step. Each team would send a spreadsheet to the next team, that team would run it's own validation, purging and cleaning and boil it to a new spreadsheet because they didn't trust the data then send the new spreadsheet to the next team... etc. By inserting a system where users could check in the spreadsheet to be pulled apart into a database with referential checks all of the separate validation could be done automatically and viola life was good.

What should we do with this? Similar to many of my posts my statement here is that we should question things. Don't be afraid to do something different than it always has been done. But don't just change for the sake of change. Understand what is currently being done and why. Use this data to attack inefficiencies and fix them. Sometimes it requires code or a system but other times even a people process change will improve things. First and foremost though, understand where you are so you can define where you want to go.

More disruptive tech.. here Wii go

I had another experience with Disruptive Technology this weekend that I thought I would share. First a quick intro story, my wife decided that I spend too much time writing blogs and doing other work at night so she gave me a Nintendo DS to play Pokemon with my son. (We were playing the card version but that is all old school and passe now.) The people at Nintendo are GENIUSES... if you purchase the new Pokemon game for DS you have two options, Diamond or Pearl. The variant between the two is the likelihood that you will run into any particular type of Pokemon. So in order to get the best mix of Pokemon you need to trade with someone else... this is where I come in. I get one type, my son gets the other... GENIUS... now we buy two games.

It get's better though, and this is where the disruptive tech comes in. If you have a Wii (and if you live under a rock and have not heard of this you need to get out more or read) then the new version of Pokemon Battle Revolution for the Wii also allows you to trade back and forth your Pokemon with the Wii version. What a Wii bit of fun. (sorry, I had to, they will kick me out of the blogger's union if I don't hit my pun quota)

This brings me to my point (already). The interface for the Wii is entirely different than the existing interfaces for video games. This has, of course, hit the press and blog pages long ago but I thought it made a great point. The Wii does not support true HD, it's tiny and has no huge sizzle effect like the XBox 360... it's even cheaper and simpler than the other boxes and yet, it is rocking the video game world. Because it changed the interface rules. The Nintendo folk's thought differently and instead of focusing on ubber graphics and interaction view(the standard thought pattern of the day in games) they changed the interaction method. With your Wii wireless controller (it's all Wii small... there I think that's quota) you control standing in the middle of your living room. It's easy enough my 4 year old can play bowling and baseball, fun to watch in and of itself.

What can we learn from this? Don't be afraid to go another direction. Wii is having amazing success and corresponding sales (if you doubt this go try to find one in a store). This causes me to think about basic interfaces and the way our users interact with systems. Not just web versus green screen but form versus map and open search versus controlled UI. This is the gist of Web 2.0 and why the interfaces work. Kids who are growing up now don't think in forms, why would they? Their interfaces are things like iPhones and Wii.

Disruptive Technologies that make you go hmmmm

Two separate events in the past few days have made me consider disruptive technology and it's impacts. While fun for those standing on the sidelines it has to also be a terrifying event for those who are in the middle of what is being disrupted.

• Disruptive Tech 1: The iPhone
• Disruptive Tech 2: Google Apps

Disruptive Tech 1: The iPhone. Yes, the often referred to Apple foray into the cell phone business (in some cases referred to as the "Jesus Phone" it's PR is so big) is a great example of a disruptive technology. It is already wrecking havoc with phone manufacturers and not because it is the worlds best phone, but it is slightly off from today's phones. The NY Times put out a great article late Tuesday night as the phone was hitting the general population with the compelling headline "The iPhone matches most of it's hype". Gizmodo posted a good summary of "Finally Confirmed: What the iPhone doesn't have" [Songs as Ringtones • Games • Any flash support • Instant Messaging • Picture messages (MMS) • Video recording • Voice recognition or voice dialing • Wireless Bluetooth Stereo Streaming (A2DP) • One-size-fits-all headset jack (May have to buy an adapter for certain headphones) • 3G (EV-DO/HSDPA) • GPS • A real keyboard • Removable battery • Expandable Storage • Direct iTunes Music Store Access (Over Wi-Fi or EDGE)]

That's quite a list for something that is still going to change the phone world. It has a controlled UI and OS. You can't load things on it and Jobs has made no bones about confirming that will remain the case. But it has a paradigm changing interface, consolidates devices for those with iPods and Phones and PDAs, even smart phones. As eloquently stated by David Pogue in the times article "It’s substance; it’s style. It does things no phone has ever done before; it lacks features found even on the most basic phones."

Personally I am going to hold off getting one. I recently purchased an 8525 (YAY I get to skip my Blackberry across a lake) and I have been quite happy with it. (heck I have already customized the snot out of it and have my Yodeling cow ringer going) But the geek in me covets parts of the iPhone and I may end up with one when I next need a phone... when it uses the faster Edge network and apps to get to business email are actually available. In any case, the reactions from the "old school" cell phone makers is going to be a blast to watch.

Disruptive Tech 2: Google Applications. I have to admit that when Google first rolled these out I thought to myself "ok... that's nice... why do people even try to beat Microsoft in this space?" Well a quiet little post on the Google blog made a light bulb go off for me. Google isn't trying to hit Microsoft at the desktop (well not right away) they are hitting them squarely in the admin.In the blog post Google indicates how they are going to give free access to advanced features of the full Google office to schools. The standard package for individuals is free already but a Premier Edition, targeted at companies is also available for $50/user. Now the Education Edition also includes the ability to integrate with existing facilities, conference and resource scheduling and other premium services.

Educators want to educate. They don't want to run systems for email etc etc. Now, they can get email, integrated chat and other niceties for free. This is where giving it away starts to make sense. It's not just about giving it away to the individual consumer in hopes of pushing ads. It's about pushing it into corporations... wow, now that has to be a scary thought. As with the iPhone, it may not truly change the world, but the potential is there and it will be fun to watch. (By the way, although corporate email isn't available via the iPhone... if you use gmail you are good to go... hmmmm)

Every integration point created WILL fail and Scalability

I have two things for today's post.

1. I received a note this AM from my "FYI- Jana RSS feed" (A good friend that works with me that sends me email) that I had to pass on to everyone. Read the article because the quote below is SOOOOOOO true.

“One of my recurring themes in "Release It"
is that every call to another system, without exception, will someday try to
kill your application. It usually comes from behavior outside the specification.
When that happens, you must be able to peel back the layers of abstraction, tear
apart the constructed fictions of "concurrent users", "sessions", and even
"connections", and get at what's really happening…”

Agile, Architecture and
the 5am Production Problem - by Michael
Nygard

2. This weekend I attended the Seattle Conference on Scalability. It was sponsored by Google and it was GREAT. Over the next few weeks I will digest what I heard and saw and report it back via blog. At the moment though I have to admit my dueling day jobs are getting the better of me so I haven't had time to couch my ideas into pithy post prose. I promise it is coming though. I will however let you know that Google recorded the presentations and they should be available by the end of the week on YouTube.

Enterprise Architecture is not technology selection

Now that I have extolled the virtue of standards like muscle building and listed our current set I wanted to post a bit on why I believe having a consistent Enterprise Architecture is important.

First and foremost on the list of why an Enterprise Architecture is important is that for a company to be successful it needs must build IT Solutions, not IT Capabilities. What is the difference you ask... (or even if you didn't I am going to tell you anyway) Capabilities can survive in non-integrated verticals but Solutions require integration. An End to End view of paths and functions is required to get a solution. An IT Capability is something like storing a customer information record in a database. A Solution provides the customer with value because it can use that information and to customize a trip.

One of the fundamental rules of development is breaking things up into smaller, solvable pieces. At the individual system level this makes perfect sense. However, when you start to look at things at the enterprise level, things implemented in pieces build piecemeal solutions. Then, these piecemeal solutions need to be integrated. This is what I have referred to in previous conversations as the fiefdom effect. Essentially, this is where individual systems or areas have their own fiefdoms and protect their system boundaries and "control their own destiny". While this may be fine a micro level, the independent pieces work fine after all, at the macro level this increases the integration burden and decrease overall company agility.

This is where we get to what Enterprise Architecture is all about... Enterprise Architecture's (and Engineering, YAY Engineering!!) job is to take a long term view so that teams can build capabilities not just fulfill the short term order of the day. If we have a solid base upon which to build (and this is an art in itself, not building the Taj Mahal or better yet the Winchester House when an outhouse will do the job) we enable everyone to move much faster and make integration between components that much simpler.

Yet another argument for a seamless SOA infrastructure. Or at least that's what the vendors are touting as the latest Technology Software solution for this problem... but we will save that post for another day.

Monkeys down a fire pole

How many monkeys can slide down a fire pole in 5 minutes?

Ok, so this question doesn't seem to have a lot to do with technology or engineering when you fist consider it. But give me a little bit of patience and let's see where we go.

I have recently begun to undertake a personal quest for education and education provision to others about threading and how to do it well and efficiently. With the introduction of multi-core processors and processor companies no longer creating faster and faster single core CPUs with clocking, over-clocking and over-over-clocking, it has become more important to actually understand threads.

Even as recently as when Java first came out the only places that you really ran into threads in open systems was in Solaris (or other Unix) systems with big multi-CPU backplanes. These were usually reserved for big 'ol database boxes though so you could optimize your system to really what amounted to one big fire pole. If we imagine each processor as a fire pole and each unit of work to run as a monkey, we can start to use my fun little analogy.

Everything you did was about queuing up the monkeys efficiently then sending them down the pole as quickly as possible for each individual Monkey thereby maximizing your monkey throughput. Great schemes for keeping the Monkeys in the right order, keeping the pole clean during non-monkey sliding moments (Garbage collection in Java-land) and other similar optimizations were the wave of the day.

Now the fire poll manufacturers (Intel and AMD) discovered that they just couldn't build a faster fire pole without violating the laws of physics (and it's not that they wouldn't break those laws, more that they couldn't figure out how) and therefore decided the best way to move forward was to build a multi-fire pole firehouse in the same amount of space. It was a great innovation... but the monkeys were still optimized for a single fire pole. So in many cases (not all, but many) the fire pole (CPU) utilizations actually was very low even though other areas were slammed. Monkey lines (memory) and even Monkey storage (I/O) became bottlenecks with a low 25% pole usage.

The time has come to build education on efficient fire pole usage. We need more effective ways to slide those little monkeys down. There are some basic practices that seem to make sense. Sun recently explained how they are building better threading into Java and things are rolling out from there. That's a great start... but that is just a start. To really use the power we are now putting into machines we need to figure out better ways to feed the cores.

Help me save the monkeys... do you have any good tips, observations, sites or do you have any bad monkey practices that you have seen that should be avoided? This practice is, of course, not limited to Java but C, C++, Ruby and others. I would like to pull these together to be shared with everyone. If you have a good monkey tail please drop a comment. I would love to hear from you.

WARNING... FOR YOUR SAFETY...

Most home invasions come in through Windows...

Saw this come accross the wire on the Ubuntu site and laughed out loud after watching it. I thought it ranked up there with the Ruby Commercials. Of course it's a little simplistic since we all know there are vulnerabilities in Linux as well as Windows. Though the frequent target is certainly Windows due to the ABM (Anything But Microsoft) cooalition's distaste for the "evil empire".

Build your Corporate Muscle Memory

I have posted before about the need for standards to allow us to focus on differentiating functionality and I have been thinking about this again since I have been working on a project in which standards are a big part.

Have you ever considered how as you learn something it become easier with practice, eventually become second nature? Watch a small child learn to walk and it is something that they have to really focus on at first. Then as we get older it is something that we simply take for granted. Does this make us expert walkers? Or do we just establish walking as a "dial tone" activity that we no longer need to think about?

Think about a chef. When they are first learning to do things they need to focus on every cut of a vegetable. But as they become an expert they no longer even measure a teaspoonful of salt. (BAM! Just watch an episode of Emeril Live and see how closely he holds to a written down recipe for an example.) A chef can do things without any concentration at all that many of us would require many times the time to do.

A runner or athlete is another good example. Runners develop muscles that work in very distinct ways. Their develop something called muscle memory that causes the muscles to introduce an actual change to how the muscles work. This change increases the level of accuracy and flexibility for running by optimizing the muscles for the repeated action. There is a trade off however, the muscles become very good at a certain set of items and less flexible for others. Because a runner is training to be a runner, not a gymnast this is a fine trade off.

Standards are similar in that we want to establish a Corporate Muscle Memory. It will require focus and concentration at first to do the new standard processes. It will also reduce flexibility to a certain extent in that there will be specific micro-processes that could become harder but the specialties become faster. But with the goal being to move as quickly as possible with agility towards the companies direct goals this is a trade off worth making.

Focusing our efforts on learning and optimizing according to standards allows is to build our Corporate Muscle Memory. We can then go faster and focus on differentiating functionality rather than dial tone. Just as with human ability companies ability needs to evolve over time and standards are no different. When the time comes to change a standard there will be a period of concentration required for us to develop that new Muscle Memory and for it to become second nature. But as we do whole new levels of speed and capability are possible.

Developers are Artists

In a meeting a little while ago I heard a comment, at the time said in a little bit of a flip way, that developers are artists. While not necessarily meant in a way that would suggest that Developers are right brain oriented, creative, canvas painting snobs the statement did get me thinking.

We were discussing standards. A topic that can be scary for people who want to forge their own way... artistically creating the next generation of award winning software... etc. (blah blah blah)

So off my brain went on a metaphor dive and it actually started to make sense to me. While artists want to be able to choose their own tools to ensure they get the right tools for the job there is a lot to be said for simplicity. Having the right brush size is critical... but it's still a brush. Certainly, there is a difference between the 10 for a dollar brush and the $20 brush but if you compare a $19 and a $22... is that really something an artist wants to waste their time doing? I mean really... there are people who are paid to do that... shouldn't the artist be creating... painting... utilizing their skills to make a difference.

Our approach to standards needs to be the same way. We will have people who specialize in brushes. Or in this case Database Platforms, Application Server platforms, Middleware solutions etc. We have a set of brushes sized appropriately for the job. Or in this case standard containers such as J2SE and J2EE containers both basic and fully enterprise capable... Tomcat, JBoss, JBoss with Clustering, etc. We want our artists to focus on painting the canvas with differentiating impactful imagery. Or in this case business logic that implements the vision the company has for functionality.

I realize some of you may be wondering just how deep my analogy rabbit hole is going to go but I will make a few more points and abuse it just a little more and then let you get on with your life. Just like brushes need to be replaced and a new canvas is occasionally needed so to do application and development standards need to be refreshed. Standards are just a representation of the best knowledge at a point in time. They are meant to be challenged, updated, and tuned. Without that effort and focus they become dated and slow things down rather than speed them up.

So as we set and roll out new standards as part of our efforts to accelerate development and increase stability and quality keep that in mind. Let's make it so that our artists can paint... but let's also challenge the status quo.

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.

Step 1... round up the lawyers

We have all heard the jokes and everyone has read the phrase before. The first step to improvement is round up the lawyers and send them to the bottom of the ocean.

If you have had your head under a rock or otherwise not seen any tech news lately you may have missed some of the latest fun with lawyers and the grand FUD they can churn up.

First Microsoft came out with a statements about how Open Source has violated 235 of their patents. Of course no details were provided on the patents themselves just a bit of churn and great press. Using their recent deal with Novell for patent sharing (Read my post on how when you wrestle a pig you both get dirty but the pig likes it for more info) as an example of "good" behavior they encouraged others to strike similar deals. Part of the real fun in all of this is how at the same time Microsoft was (out of another side of it's mouth some might say) calling for Patent reform due to suits from others against their own patent infringements.

Then the Linux foundation crafted a rebuttal. As would be expected they called out Microsoft on what the patents were. They clearly called out the FUD aspect and took a more offensive approach and begun to fund patent claims among other actions. Spinning from IBM, Sun and even Nokia releasing patents for Open Source use this approach seems to be gaining momentum.

Now the new GPLv3 is even including language that would cause Microsoft to loose rights to sue if the new Linux license terms in GPLv3 go forward. Further complicating this is how the deal with Novell may actually be what causes Microsoft to loose enforceability on the patents. Now even Novell is exploring patent reform. Even going so far as to fund "Patent Busting" activities.

Wow... I guess if you are a lawyer this would be fun or at least profitable. But as a techy I have to just sit back, pop some popcorn and watch the show.

Observations from my Romp with Ruby

My experience with Ruby on Rails was a positive one, or to quote the Rails site, it was "Web development that doesn't hurt". I am still by NO stretch a ruby or rails expert but I did learn a lot and I was impressed with the abilities in such a relatively young language. I still believe that no language will ever solve all of the worlds programming ills. But they will continue to get to higher and higher levels of abstraction and developer productivity.

Ruby is essentially an object oriented scripting language. Rails is a separate library set that is focused on productivity enhancements and tools to really accellerate web development. Rails uses the Model View Controller pattern for development and a strong implementation of the Domain pattern for data persistence. You could very easily build a fairly complex app all without any knowledge of the database. (Now there are obviously other concerns with that but we won't dig into that in this post.)

CSS and stylesheets can be automatically generated along with full basic UIs with a tool called scaffolding.. (It's not that pretty but gives something upon which to build and actually works great for validating that you have the right model). For many of the common advanced UI actions there are simple sets of commands as well with built in Javascript AJAX - scriptaculous commands for visual effects, drag and drop, dynamic lists and more. Everyone knows you have to have AJAX to be cool now adays.

If you want to poke at Ruby and learn a bit check out RadRails for development (it lacks intillisense type function at the moment which made me sad but everything else you could want works right out of the box) and InstantRails for a working environment. It's a great combo to get you going in just a few short downloads.

Every language will have some weak spots and Ruby is no exception. But it does work hard to answer many of the common problems in today's frameworks. My favorite (have to give a plug for the Engineering side of things) is things like fixtures and test automation built-ins to encourage test driven development. My biggest question is still, how does it scale with very high volumes?

Solaris vs. Linux

As mentioned in my post Sun gets a new spark I recently had the opportunity to visit with some of the folks from SUN and get some visibility into the efforts they have under way. One of the things that this visit caused me to ponder was Solaris 10. When Sun open sourced Solaris I wrote it off as the death throws of a previously strong giant and it made me sad. I originally cut my Unix teeth on Solaris and did a lot of work with it as the stable foundation on which to build open systems. However, as Linux came into its own I have also been one of those folks who has systematically been replacing Solaris in the data center with Linux. For the most part going with the masses to Red Hat but with occasional forays into others as well.

Some developers that I know have stuck with Solaris for their development environments even through the Linux craze due to tools that they liked. Originally I had gone the other way, moving development environments to Linux and deployment environments to Solaris. Solaris in prod for stability and Linux for tools and speed in development.

With the new innovation going into Solaris, things like ZFS, zones and Grid it gives pause. The difficulty now is that everyone and their kid sister has run Linux, known Linux etc. There is a wealth of Linux talent out there and the Solaris admins are much harder to find. Of course Red Hat has been getting more proud of their products and pricing their support accordingly which also adds to the mix. With all of the recent silliness from Microsoft on their FUD around Open Source and indemnity clauses things get even more interesting. (I personally am of the belief that if they thought they could win they would already be in court... but I am sure the FUD is the real goal)

So given your choice... which would you pick?

Pay attention!

A while ago I read a post by Seth Godin on how to be a great audience. I thought it was a great post and provided some very good tips on what to do and how to listen and be (as the post says) a great audience. The context was a presentation to a group of eighth graders and how he could see who would be the good audience and who would not. The students who leaned forward, engaged and asked questions and drew out a better presentation.

Over the following months I have seen this over and over again in meetings. It's amazing the number of people who don't pay attention in a meeting. They drift off to their blackberry (assuming that the network is still working) while someone else is making a point. People bring laptops to meetings and proceed to answer email, read news (and if it's not an RSS feed of my blog that's just rude) or otherwise ignore why they are there in the first place.

Now I will admit that many meetings that get called seem to be meetings for the sake of meetings rather than meetings with a mission. This can be addressed separately. Be direct in meetings and don't be shy about making sure that there is a focused purpose and when that purpose has been achieved... don't feel that the meeting needs to go on just because it has been scheduled for an hour and fifteen minutes of discussion handled it. Give people the gift of time.

So, in your next meeting, make an effort to pay attention. Listen, lean in, ask questions, be a good audience and for goodness sakes PAY ATTENTION!!

Rails Envy: Hi, I'm Ruby on Rails...

Rails Envy: Hi, I'm Ruby on Rails...

Click here to view on YouTube

I laughed until I stopped.

Friday Link Day - Microsoft to buy Yahoo!?

News has started to come out that Microsoft is looking to resume talks to buy Yahoo! I think someone has Google envy.

Along the lines of the silicon related post from earlier this week... IBM announced that they have devised a way to create vacuum spaces in chips that will allow them to use less power and run faster. The chips even "assemble themselves" to a certain degree.

Getting tired of the laws of physics holding them back with silicon Intel is working on Laser chips now. NEC is saying that laser chips could power petaflop-class chips. Optical chips may still be a few years away but the idea sure is fun.

SUN gets a new spark

I recently had the opportunity to go out to California and visit SUN. It was just a short period of time but it was an information packed couple days. We discussed topics ranging from Sun GridEngine to strategic direction, from Developer Tools to hardware threading.

I was particularly happy to see that SUN appears to have obtained a dose of humility. Where their previous corporate strategy seemed for a while to be "ABM" (Anything But Microsoft) they are now focusing on understanding their spot in commodity markets and differentiating based on service. The previous approach and Scott McNeely's top 10 lists was certainly entertaining it didn't do much to further the companies goals.

SUN has now taken a page out of the RedHat handbook on making money with Open Source and are trying to make money with service differentiation. I had written off the initiative to Open Source Solaris as the dieing throws of a declining giant. But listening to the vision that they have and what innovation Sun is now building into Solaris 10 with things such as ZFS and Virtualization such as Zones.

Their approaches with Silicon and drive to innovate there was also interesting. They now sell Sun boxes with AMD and Intel processors. Talk about Cats and Dogs living together. We even discussed a current effort sun is working on with Microsoft for a large system provider where they are serving real time video off of Sun hardware running Windows. ... Let that sink in for a minute...

Another interesting point that was brought up was how Moore's Law and fitting more onto the same bit of silicon applies to RISC chips as well as CISC chips. Since RISC is smaller (Reduced Instruction Set) they can then fit more processors on the wafer. So they are legitimately talking 32 and 64 core processors. Talk about the need to thread your application. Initiatives such as Niagara and Victoria Falls also provide low energy approaches.

Just read some of the press of the days for a glimpse of some of what they have been up to.

Friday Link Day 2007-04-27

My favorite link of the week is the discovery of a new "potentially inhabitable" planet. It is believed to have water! If you start now by the time that your children's, children's... heck a lot of them are born, its just shy of 21 light years away, you can have an address that ends in Planet 581c!

Software Engineers can go to space too. I wonder if they ran any parts of flight control and operations on the Excel or Word... and if he knew they were if he still would have gone.

Do you hate putting your phone or iPod on the ground. Then you need the Electronics Hammock... yes, it's really a product.

If you hate your BlackBerry (like me) but enjoy the abuse and want to put the interface on a Windows Mobile 6.0 phone BlackBerry would like to help you out. They are apparently releasing BlackBerry functionality on Windows Mobile with ATT first and moving from there.

How do you get work life balance?

I was reading through some blog posts and stumbled onto a presentation I wanted to share. Stuart Levine, author of "Cut to the Chase," provides a downloadable PDF manifesto entitled Reclaim Your Life: A Two-Week Challenge to Help You Regain Time It has 11 great tips on how to get to the point, and get the time you need to really make a difference. He starts with a quick review of work life balance and how it's easy to say and not so easy to do. Check it out... make the time.

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.

Friday Link Day - 2007-04-20

Does Apple + Google = Love? It is a high interest geek story and makes for attractive rumors. The enemies err... competitors for both are often the same. My personal thoughts are that there will be much collaboration but no marriage. The Forbes article brought to you in pictures certainly is a fun read no matter what the eventual outcome.

Speaking of a marriage... Like the MAC? Or at least the UI? Check out this Blog post with a style sheet that allows you to put a MAC interface on Google Reader. (If you are looking for an RSS Reader I recommend the Google Reader BTW.)

Then to keep the Google theme for the day Google shows us the first tenet of innovation in action. The best way to have a good idea is to have lots of ideas. Apparently Froogle didn't fall in the good category so Froogle is dead... long live Google Product Search.

A quick snip on testing

I have recently had two different offline topics end up with the same point so I figured I would pass it on here as well. Testing and why it is important to test to failure and not just test. To stick to the intuitive reason, it is because then you know when your system will break and what will happen when it does. It is naive to believe that your system will be 100% problem free, it is a far more realistic expectation to accept that you just don't know when.

One of the fundamental race conditions of the universe is that as soon as you build a better, more idiot-proof system, the world will build a better idiot. Similarly in a system which is successful and experiencing growth, you will eventually hit a point that exposes problems that didn't show themselves under lesser pressure or lesser load. In aircraft they X-Ray and image things like propellers not because they want to ensure that it is perfect, but so that they know what quality it is. Under the right conditions a very tiny bubble can cause a propeller to literally fly apart. Better to know these things up front.

My Jana RSS feed recently (inside joke) recently came across with these two links, one for example, one for humor that are relevant to this topic. Check out this Ultimate Failure test... and fly with a little better feeling in your heart because you know that they care enough to do this. Then check out Monkey Testing at it's best. (I am trying very hard to resist the 1000 monkeys and Shakespeare sonnet reference... darn... I failed.)

In conclusion remember, it's ALWAYS better that you know where things will blow up than for someone else to tell you.

Go get an MBA?

I recently read a fabulous post by Seth Godin on NOBS, the end of the MBA. In between bouts of laughter I thought immediately of post material and here we find ourselves.

Not that there is no value in an MBA. Certainly there is and depending upon the program, classes and approach to teaching lots of value can be garnered. But it is not the be all and end all that it is often made out to be. For many people a real world education and a desire to learn are what is needed to be successful. Through books, such as those written by Seth Godin are great sources of knowledge, the catch is that you need to make the time and spend the effort to learn from them.

Another important point is to consider what your focus is. MBAs focus on business administration and financials in most cases. If your passion and skills are around technology and development then it may not be the best suited thing for you to change that focus. Focus on what you do well, not what you think others want and you will go further and faster.

Stephen Covey often uses the term circle of influence to describe what you control and what you do not. If you focus on what you influencce you can expand that influence, knowledge and experience. When you focus on things outside of your circle of influence or beyond your control you only end up getting frustrated and end up with less time and less energy to focus on the things that can help you and expand your circle of influence.

You have a limited amount of time and a limited amount of energy and spirit... use them for something that gives you more, not less.

Innovation in automobiles

Looking at the automotive industry, it seems as though innovation, real innovation hasn't happened in a long time. Sure there has been incremental improvements and there has been many great additions that have made our lives easier or better. (Try and tell a Mom who drives her kids for any distance that you are taking the DVD player out of her vehicle and you are going to face some serious wrath.) But next generation types of things seem to be a long time in coming.

I encountered an interesting one while channel surfing for cool HD content and it got me thinking about what stories are out there so here is my quick list.

• We have all heard the stories of the self driving cars using approaches like that from GM is neat idea but one that people who love to turn the twisties view with some amount of horror.
• Alternative fuels show promise and may help with future energy problems.
• Keyless cars and other innovations that are cool... but differentiating?
• Reinventing the wheel? Michelin is trying with the new tweel.
• Even cars that can go 235 miles per gallon of gas!

The thing that gone me thinking about the whole topic though was the idea of thin cars. Two people cars that lean to corner faster. One example is the Carver. Another example is the Naro. The thought of twisting and turning but taking up less space and energy could be fun. Of course in my case, my immediate reaction was "will the power to turn the tires be enough?"

I have posted before about how globalization and other changes to the world business environment have driven a need to develop and use our whole minds. This in turn is also driving what I believe is a need to address school systems to adjust to these needs. I recently read an interesting article from the Wall Street Journal on how Pain Free Trade Spurs Second Thoughts. The article is an interesting piece on how Alan Blinder, economist, Princeton teacher and one time advisor to the Federal Reserve has changed his mind about the impact of globalization and offshoring to American jobs.

It is easy to jump to the protectionist approach (especially for politicians) but really this just delays an inevitability. What, in my opinion, is the more correct response is to adjust our understanding and focus on what will be staying put. High touch areas and things that instantaneous technical bandwidth won't address will always be in demand. As a recent quote from Texas State Representative Rob Eissler, on the importance of arts education states "Left brain is logic, right brain is creativity. We don't want our kids to compete internationally with half of their brains tied behind their backs." (Original post from Dan Pink's blog. Dan is the author of the fabulous book A Whole New Mind that deals with many of these topics.)

It works on my machine...

It's been a while since I have done a Friday Link Day so I wanted to throw together a quick one and pop a few of my favorites out for this week.

It works on my machine. What technologist has ever existed who has not used these words? Well now you can stamp that application with all of the recognition that a single threaded one time test deserves. By following the criteria outlined in this Blog post you can use the logo below and show the quality of your app.

Next, in the news of the truly cynical at heart, check out this article on Job Cuts for Fun and Profit. Short Circuiting Circuit City decided that 3,400 of it's workers were making just over 50 cents more an hour than their own determined average acceptable salary for a sales associate... so they are laying them off to hire cheaper people. So the next time you are looking for help and wondering why you can't find anyone who knows as much as your 7 year old you can remember how saving 50 cents an hour in employee costs got you an extra 25 cents off a computer. The article, one pulled together as part of the Knowledge at Wharton effort from U Penn Wharton School of Management, actually makes many good points on a number of topics and is worth a read if you get a chance.

TPF as a SOA platform

Really... I am not kidding. For those of you who read my posts at all regularly you know that the majority of my time is spent in Open Systems. But in reality there is still a lot of data and processing that occurs on the mainframe. I caught the following press post on Information Week and simply had to read it.

IBM Opens Up System Z Mainframe To SOAs

Now, reading into the press release it's much more fluffy than the title sounds. But really, would we expect IBM marketing to not be able to do their jobs? (I think they were the original inventors of F.U.D., right?)

Still, it does make you think about what kind of data source a mainframe could be for any high volume system. The ability to handle large amounts of data and transactions in a stable manner is a consistent throttle that we encounter in the Open Systems world. Now the cost/benefit needs to also be compelling since there are many other ways to solve the problem then simply making the iron bigger.

I had an opportunity to talk to some IBMers lately and they are still big on big boxes, just now they want to slice those boxes into 100s of virtual servers and provision them dynamically. I found it ironic that when you consider the open source revolution pushing hard away from big iron, we are now pushing closer to it. The IBM Z series and the IBM P series even sit in the same "refrigerator boxes" now. (For those who are not Z or P savvy Z=Mainframe, P = Open Systems) So you could walk out on a raised floor and not even know if it's an open system or a mainframe system... now it's just a system.

But then, isn't that how a service consuming customer views it?

When you wrestle a pig you both get dirty but the pig likes it

The next in the significant Open Source events category is one that occurred with Microsoft and Novell. (Yes, that Microsoft). This deal has to do with Linux as well, but in this case its SUSE that is under discussion. Read the announcement or watch the video footage if you want more detail.

The pundits on this one are even more passionate. (As if we would expect anything else with that Microsoft being involved) Linux Journal likens the deal to Racketeering from Microsoft with FUD sowing from Novell/SUSE. Bernard Golden claims the deal just proves that Open Source is important to your future.

According to the Public Relations statements by both companies the deal is all about Virtualization, Web Services Management and Document Format Compatibility. It is also a five year patent protection agreement where Microsoft agrees not to sue users of SUSE if there is any patent infringement in the SUSE system.

My thoughts around this go immediately to other companies that have made a deal with the devil... err... I mean entered into cooperation agreements with Microsoft. (And no I am not an ABM Coalition card holder. I actually have a fascination and respect for Microsoft, .NET in particular and even SQL Server... I just think that from a business perspective you have to realize what you are dealing with) Take for example Sybase.... Somewhere around Sybase version 4.9.2 Sybase and Oracle were the big mean Relational databases competing tooth and nail with one another. Sybase was, at the time, viewed as slightly more technically advanced while Oracle had better marketing. Sybase then entered into a cooperation agreement with Microsoft to build a version of their database product specially tuned for the Microsoft Environment. A great move, they would get information from Microsoft on the particulars of the platform, build a super tuned engine and everyone would benefit... right? They were very successful, the product created is the forefather of the now nearly everywhere Microsoft SQL Server. As far as what Sybase got out of the deal... they got some short term revenue in the first few years of the agreement before it ended and Microsoft took things over. (Honest, they are still in business now) Other deals that can be pointed to include Borland... Symantec... Corel... need I say more?

Not that this will end up being an end of the world. Just like Microsoft owns the productivity suite on Apple they will likely get the information they need to build and own the productivity suite market on Linux. If .NET components run and integrate well with other platforms but work best on Windows platforms... hasn't Microsoft always been very good at Embrace, Extend, Exterminate?

Another one that will be fun to watch.

Now that I have posted about Google and praised them in several regards I will point
out how silly that is. The Halo Effect is the general belief that because a company is successful it is successful because it is brilliant, innovative, has a great culture, [insert appropriate praise here]. Conversely when that same company stumbles it is because they have "fallen away
from that brilliant, innovative, great culture, [insert appropriate praise here] that made them great. Therefore management books, methods, papers, research, Blogs (heh) are written on this company and how you can be successful like them by following "these 12 easy steps".

The reality of the situation though is rarely that either one of those items is absolutely true. Good companies can have problems, and bad companies can have success. A recent article in the McKinsey Quarterly even suggests that "Suggesting that companies can follow a blueprint to achieve lasting success may be appealing, but it’s not supported by the evidence." and "The delusion of lasting success is a serious matter because it casts building an enduringly high-performing company as an achievable objective. Yet companies that outperform the market for long periods of time are not just rare but statistical anomalies whose apparent greatness is observable only in retrospect."

Wow.

This effect is referred to in psychology as the Halo Effect. Just we tend to be nearly binary in how we view others attributing positive traits to those we like and negative traits to those that we don't. Rarely viewing the people with a mix of positive and negative. The book The Halo Effect: ... and the Eight Other Business Delusions That Deceive Managers covers this topic in some detail and relates it to businesses

So what does that mean? It means that success is hard... go figure. It means that you need to constantly adjust your strategy and approach to be relevant to the times and business environment in which you find yourself. The approach that got you where you are today simply won't continue to work. It means that if you stand still, you die. From a corporate perspective and a management and directional challenge perspective this is a whopper of a concept.

A great quote on this topic from US Treasury Secretary and Goldman Sachs executive Robert
E. Rubin “Once you’ve internalized the concept that you can’t prove anything in absolute terms, life becomes all the more about odds, chances, and trade-offs. In a world without provable
truths, the only way to refine the probabilities that remain is through greater knowledge and understanding.”

That's almost grounds for a philosophy debate. Up there with "Only the insane have the strength to determine that which is sane."

What if Google...

How many conversations start off with the phrase "What if Google...". When businesses try to do something different, especially something innovative or disruptive one of the quick lead in questions to that conversation starts with "What if Google were trying to do this?" or "What would we do if Google entered this market?".

It seems that Google is the fairly universally viewed as the thought leader of the current business age. There are even books available such as The Search: How Google and Its Rivals Rewrote the Rules of Business and Transformed Our Culture and others. Google approaches
things differently. They give their engineers one day a week to "do whatever"... just suggesting that as a possiblity in many companies will at a minimum get you a look like you have three heads.

One of the questions that DeMarco asks in Slack is "Is Google in a Hurry?" Certainly, from an outside point of view they don't appear like they are. If they were how could they spare time to let their developers chase ideas for a full 20% of their time? Google rolls out releases on a regular basis sure, but accross a very large product line and they are small. When they do roll out new products or significant releases they roll out a beta first, let people volunteer to move, thus getting a willing guinee pig audience who will tolerate some experimentation. Once the beta is solid they start to migrate people. (With the recent Blog reader full interface change they even let people flip back to the old interface for a period of time as long as they gave feedback on why.)

All of that doesn't amount to being in a rushed state, running at 120%. But, if you ask anyone about productivity they will certainly be mentioned and there is absolutely no question they are successful.

This trend has been seen in other companies as well. Apple for some time has been viewed as a company that runs at full throttle and approaches things differently. Amazon for a long time held the distinction of being the "What if Amazon entered this market?"

Not dead yet...

Rumors of my death have been greatly exaggerated. Ok. So maybe there weren't really rumors of death. I did hear from enough of my regular readers though that I wanted to pop a quick post out to declare that I am still alive just HORRIBLY busy at the moment. I normally write my blogs at night and post when I get a chance but of late I have been working regular work during that time. Rude isn't it?

Rather than simply declare that I am alive (and whine that I am busy) I will share a bit of scalability learning as well. I was recently sent a link to a wonderful article on the stability journey of MySpace.com (if you don't know what MySpace is you probabl live under an internet rock) in Baseline Magazine. It's a fairly quick read and it discusses many of the standard things you learn with scale. (Partitioning, Virtualization, Simplicity, Segmentation etc.)

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.

My Recent Reading List

Over Christmas as well as the last little while I have read several books that will undoubtedly have an impact on my blogs over the next little while. So in the spirit of sharing (and encouragement of cheating) here is a quick list. If you are interested in reading them and taking
guesses on which posts entered the list of "I should post on that" feel free to send me email and I will confirm or deny. Of course I try to attribute anything that is direct quotes or go with a theme for a week so you will likely see these mentioned again.

Siddhartha - This is a book by Hermann Hesse about the journey of a man through his life. It is one filled with many levels of meaning and one of those books that you read and learn more about yourself than you expected.

Slack - Getting Past Burnout, Busywork, and the Myth of Total Efficiency this book by Tom
Demarco focuses on many of the challenges that face companies and leaders in the post-downsize, post-bubble work world. This book is a very easy read, fit for a two-three hour flight depending upon your reading rate. It tries to not just preach but also provide real world tools to fix concerns.

The 8th Habit - I have mentioned this book before and in fairness I have to say that
I am taking a while to go through it but it is not the fault of the book. The style is easy to read and the content is great. I have just had a lot going on and have taken breaks to read other books, read blogs, and play Fantasy Hockey. Being the latest in the series from Stephen
F. Covey and the gang at Franklin Covey crew you know that it is good stuff. This book
comes from the experience that the team there has had in teaching the The 7 Habits
to companies and individuals across the globe.

Along with these I have been reading lots of Blogs.