Oh, Say It Ain't So for My Cup of Joe ...

I came across this article in the Harvard Business Review:

Caffeine Cuts Men's Ability to Collaborate Under Stress

When it comes to collaboration on stressful tasks, caffeine impairs men's performance but boosts woman's, according to research led by Lindsay St. Claire of the University of Bristol in the UK. The researchers say their laboratory study raises the question of whether men "fight or flee" while women "tend and befriend" under stress, and whether caffeine somehow intensifies those behaviors. They also ask whether coffee at business meetings might have the effect of sabotaging collaboration. 80% of the world's population consumes caffeine daily.

Source: Interactive Effects of Caffeine Consumption and Stressful Circumstances on Components of Stress

What can I say, does this mean when times get tough, don't bring in any more coffee? I used to say that Coffee, Cigarettes, and TV were the three great evils in the world. Items which destoryed your mind without you being aware of it. Of course, TV is the worst. But, as I have gained more experience, that morning cup of coffee is just something that now I would be hard pressed to do without. However, I have become spoiled as my cousin runs a gourmet coffee shop and keeps sending me samples, what can be said, I'm in.

But, coffee is a business staple. Show me a business that does not supply free coffee? Not only that, when the stress is on and everyone starts camping out in a war room, show me one that doesn't always have a pot of coffee on the table?

So, take this to heart, and as hard as it may be, next time you have the all hands on deck type of event, tell the men to leave their coffee back in their office. This just could be the secret to a more productive and productive solution to the problem.

Who would have thought ???

Ken

Right on Track

I came across this article and just couldn't help bringing a smile to my face.

http://www.computerworld.com/s/article/print/352225/Should_you_get_an_MBA_?taxonomyName=Management+and+Careers&taxonomyId=14

Education has been a theme throughout many of the items I have discussed previously. So, just great to see ComputerWorld step up and bring it right to the forefront. I have a lot of history in IT related experience and always wanted to get my MBA. Once I moved from being a technologist and into Management, my work ever increasingly became less about technology and more about business. However, when one is working 50+ hours a week and traveling, getting one's MBA is not the easiest thing in the world to get.

So, once I had real time on my hands, this was the first thing I did and I say many times over, amazing what I accomplished by instinct and tuition without having this excellent background. To all who see this, all I can say is even if you are not able to find a way to get the MBA, if you are in Management and have evolved there from a technology background, take as many classes as you can. If you are at conference, don't be afraid to sit in on some business related sessions. The people in there don't bite.

If what you learn after you know it all that counts, imagine what learning what you don't know will do for you !!!

Technical Debt

This concept is one I have fought (I mean discussed fervently) with upper management throughout all my technical career. I was never ever to fully quantify it, but instead used my own little adage that went something like this:

I can give you:

• Great Functionality
• A great delivery date
• Exceptional quality

Of course, management would always say, yep, that's it, that's what I want. My comeback, Pick Two!

I never could be very scientific about it, I would tend to lean on some common sense, or the old, Whack a Mole mentality. If you cut the date, either you are going to shortcut the function or the quality. Lets make sure we all understand that it's the date that counts. You have to make the date and have to deliver all the functionality required. How many of you have been involved in this discussion? And of course, what ends up being hit, is the quality. This was especially an interesting parable as the latter part of my career I dealt with High Availability products, you couldn't have poor quality. We managed very well, don't get me wrong, we delivered extremely high quality products. But, this game was part of every release cycle.

As part of my ongoing research, I came across an article written by Ryan Shriver on Technical debt. You can find this article at http://www.gantthead.com/article.cfm?ID=258854

Wow, here it is all laid out. I felt a bit embarrassed to find this term was first identified in the early 90's. Goes to show another one of my favorite quotes, It's what you learn after you know it all that counts.

There are many discussions and definitions here, but as always, pictures talk the loudest:


Technical Debt Chart from Jim Highsmith

Now, looking at this article, many links and recommendations can be found to deal with attributes of troubled development organizations, such as:

• Poor Customer Responsiveness
  
• Long Delivery Times
• Late Deliveries
• Too Many Defects
• Rising Costs
• Poor Morale

Technical Debt is not the answer to all these issues. Process, measurements, and other factors do come into play. But, as I have stated earlier, measurement is the key to everything. If you can't measure it, you can't improve it.

Ken Zaiken

If you fail to plan, you have planned to fail ...

There exist much discussion as to who really initially penned this profound quote. Some attribute this to an ancient proverb, if so, shows we really shouldn't underestimate the insight of those who came many generations before us. Remember, those who do not study history are deemed to repeat it.

I have been doing more and more with project management and my professional opinion as to the key components of a successful project:

1. Requirements
2. Planning
3. Communication

At a recent seminar I attended, the topic focused on key questions to ask for projects, and one item hit me that I had not fully verbalized before, the aspect of visual requirements. If a project has a requirement for a report, and the stakeholder even has a writeup for the report and the data that drives it, many times that may be taken as great input and move the project forward from there. However, a report can take many forms, and trying to resolve that once you have a team and working on the planning stage can lead to a lot of confusion and schedule delay. While it might take longer to actually get into gear, having a draft form of the report, graphs, word templates, whatever, will save a lot of time further down the project path.

A second item I have encountered is with clients who have not had previous experience with a formal project process. This is especially true with setting up the parameters of a project, an initial charter document. The biggest surprise is when the client is asked to sign that document, not so much to pour cement, but as a communication medium to fully understand the aspects of the project. Even in this digital age, putting a printed document in front of someone and asking to agree in writing sends a powerful message.

This does not mandate that what was perceived in the beginning of the project is not modifiable. But it does set a baseline that the base set of schedules, estimates, and costs are set from. People will always ask for more with less, that is human nature, but, we all do need a form a governance to have mutual respect in getting the job done. After all, that is what we all are working together to achieve, correct?

So, think twice before jumping headfirst into a project, assigning resources, and incurring costs. There is a great Dilbert out there that has the punch line, you start coding, I'll go figure out what they want. That is a plan to fail, instead, take the time to plan to succeed !!!

If You Can't Measure It ...

Then you can't improve it. Simple, true, wonderfully profound in its own way, but mainly ignored within the Software Development Community. Software developers consider themselves artists, I understand this, that is my background. You can't measure art, you can critique it, and the market tends to decide what is worthwhile or not. In this day and age, the term is rather overused. At Subway, employees are Sandwich artists, and at the coffee shops, we have Barrista's. But, my degree was in Computer Science, and whether a programmer considers themselves and engineer or a scientist, both of those disciplines require intense scrutiny and measurement. Yet, we seem to have drifted away from that regarding the science of programming.

So, imagine we could come up with a standardize constant measurement lets say a Software Unit (swu). If we had a formalized concept on how to estimate projects in swu's, instead of klocs, person months, etc,. then there would be a way to empirically measure one project against another. Basic software metrics could then be produced that could be used internally and externally to measure how a shop was doing.

For example, productivity becomes: (total project time)/(total swu's). Quality becomes: (total defects)/(total swu's). If we have a quality estimate, then we can set a release standard stating what % of defects need to be removed prior to releasing to the field. Testing coverage could also be defined as: (total test cases)/(total swu's). Suddenly this all becomes very simple, if, we have a constant definitely as this concept of a Software Unit.

Now, this is just not me being the lone wolf in the woods howling at the moon. Carnegie Mellon has a whole department dedicated to Software Metrics, http://www.sei.cmu.edu/index.cfm.

Of course, what would any reference be without the Wiki reference:
http://en.wikipedia.org/wiki/Software_metric. In the Wiki case, I especially like the very end of the reference where once can see the links to Function Points, Case Points, and how to integrate these with newer Agile and Scrum development techniques.

From my experience, leaders will find resistance from programmers who never had their work measured before, but, the organization rewards for planning, estimating, process improvement, quality, and timely execution are tremendous and in the end, once the threshold has been crossed, all parties reap in the benefits.

Personally, I am a big fan of metrics and will always pursue them in every development shop I work with. There is always a way to turn the ship to make these work, despite what opposition one may find.

Making Someone's Day ...

Several weeks ago I made a decision to use LinkedIn (http://www.linkedin.com/in/kenzaiken) in conjunction with my web page and this blog as my main venue's out into the virtual and business world. As such, I have been spending time out there updating my profile and expanding my connections. Today was just one of those virtual moments that made someone's day, and gave me a smile as well.

Out on LinkedIn I noticed someone I had lost touch with connected to a connection and sent him an invite. Didn't take more than a few minutes and the acceptance came back. I downloaded his vcard (something I really like about LinkedIn) and was comparing his latest contact info with what I had before. I wasn't sure about the phone number and was digging around. Well, go figure, he was doing the same thing and the phone rang and there on caller ID was his number. Deja Vu all over again.

We had a great talk. Times are tough out there and I'm starting up a business, he is trying to find his way into something, but we had a great talk about successes we had together in the past. We both shared what was going on and current challenges. At the end of the call, he made the statement that he'd been a bit down, but reconnecting and having our discussion, it just made his day and put a big smile on his face. Even in the virtual world, put one on mine too and gave me a lift as well.

Seemed like the type of event that belonged in a blog and share that good things are happening even as many are re-finding themselves and are scattered a bit to the wind. Gets me all pumped up to make someone else's day.

Who knows, might even drive some business together ...

Ken

When People are Scared ....

Attributed to T. Boone Pickens,
"When people are greedy, be scared. When people are scared, be greedy."

Well, there's a lot of fear out there these days. It would be a great time to be greedy, if only one could figure out how to do that? We all need to have the optimism that the current recession will dissipate and a new business normality will emerge. With all the money the government is pouring into it, considering its our (and our kids) money, lets really hope so!

But, an item that few people are understanding is that we are in the midst of a paradigm changing event. The economic storm that is currently waging is one that is scouring the underlying landscape. Those who are hunkering down waiting it out presuming a previous business as usual business mode are in for a big and unpleasant surprise. Much like what happened at the beginning of the decade with the .com bust, things changed and all of us had to find a way to change with it. Those who were best prepared, were the ones that most benefited.

Greed does not have to be immediate. One can look at what is happening now as a great opportunity to be greedy in preparing for the new economic world. Now is the time for those with a strategic eye to be greedy, don't hide, but invest & prepare. If you start when the recovery begins, you are too late, the race has begun anew and you aren't even at the starting line.

Now is the time to seek out the visionaries, whether internal or external to your organization, and prepare. What must be understood is that preparation doesn't come without cost. To be greedy, requires some risk and requires putting together a strategic plan and actually executing on it now, not when the recovery begins. If you are up to speed when the recovery begins, that new wave will take you very far.

Ken