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.