Data is no longer relational

Ok, so the headline may be a little of an over statement for effect. Perhaps I could have said that data that people are interested in is no longer relational but then it wouldn't have been nearly so pithy.

With much respect to Edgar Codd and his invention of the relational model for database storage I think it is time to move forward. Relational databases are great for things like financial models, personnel data and other Enterprise Systems as well as many other standard, repetitive data. It gave a solid reference point to learn data structures and modeling to several generations of budding Computer Scientists.

When I say it is time to move forward I am not saying we should immediately move all data systems to Object Oriented Databases or otherwise induce data chaos. What I do want to push is the idea of unstructured data. Computers are great with rules, with structure and with fundamentally binary relationships. Algorithms are starting to mature around unstructured data (for an example go search google.) but it is still not widespread or well understood.

New exciting algorithms such as Amazon's Dynamo (Werner Vogels is one of my favorite speakers and bloggers on distributed tech, if you are not familiar with him in this space you should be) database are showing in real world situations that distributed systems and distributed data are a reality.

In a lot of system designs because people are so familiar with relational data structures and systems we find Object Models that look like a relational database design. When asked why it looks like this the answers are fairly consistently things like "this is how the database stores it, for speed we need to do the same" or "it just made sense when we pulled the DBA in to help us with the model."

Objects are not relational! They are objects. Then when you get into full structures of objects or object trees there are relationships but it is not the same as a relational database. Especially as we start to build and mature distributed system algorithms it doesn't make sense to use a centralized data store. If the data can be broken up, distributed and stored with the algorithms that will use it performance will improve.

In fact I would argue that the elusive SLA of a system response can begin to be discussed if we can tie the data to the processing. Granted there are new complexities in this model for synchronization, segmentation and consistency but there are ways to solve them. Similarly consistent access to the same servers is also possible.

What other great examples of distributed computing and distributed data storage have you seen?

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.

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.

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.

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.

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?

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.

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.

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.

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?"