Thursday, November 30, 2006

Crawl before you walk

Change comes through having great people doing extraordinary projects. You crawl before you walk. I see people jumping into solution forgetting the fact that they can’t even crawl. I hear: “version 2.0 will fix all of these….” Before jumping around and advertising a new solution ask yourself these questions:

What are you working on right now to make you learn how to crawl first? Does it matter? Is it creating a change momentum? Do you care?

Thursday, November 23, 2006

Why Robots Are the Best Employees



This graph wonderfuly done by Kathy Sierra shows why many bosses like "Yes man" employees. Using the brain is all secondary!

Timing is everything

Paying the Technical debt is very important aspect of dealing with legacy code. However, timing of it is even more important. The team estimated 2 weeks for something that normally takes 1 day to do. The re-engineering effort is considered as part of business feature making the estimates longer. I am thinking that overhaul of system effort should be separated from implementing the business valued features. Who said business should wait 2 weeks for something that they can get now! Timing is an essential ingredient of success. If gods are telling you to do something – would you do it or …
Here is a questionnaire for leaders:
* Challenge: do you question what is and what you are told?
* Decisiveness: do you make up your mind in good time?
* Speed: do you take necessary action?
* Clarity: are you clear about what you are doing and why?
* Change: are you prepared to change anything and everything that needs changing?
* Basics: do you do well all the basic things that need to be done?
* Objectives: do you have written aims for this project, next year and five years’ time?

Tuesday, November 21, 2006

Queuing Theory

Queuing Theory

We spend a lot of time in queues. Life is a queue itself. You get stuck at traffic jams, for somebody to approve a request, lines at stores, waiting for your mother in law to call, or for rain to wash your car.

Queuing theory deals with making your wait as short as possible. One hotel used its front help desk to route people to specific elevator which takes them to their destination floor (reducing waste). “Take # 3 it takes to 10th floor faster…”

The main measurement of a queue is cycle time – that is, the average time it takes something to get from one end of a process to the other. Nine months for a baby to come into this world. Sometimes if they come 2 months earlier they can play for another soccer team.

Today we worked on queuing jobs that are behaving badly. The time spent waiting in the queue is wasted time. There are two ways to reduce cycle time (I hate to limit to two); one is to look at the way work arrives and the other is to look at the way work is processed. Doctor’s office use reservation system to assure that patients arrive at regular intervals.

One way to control the rate of work arrival is to make sure small arrival of requests, if the same work is released in small batches, the queue can be much smaller. However, the other way is to go after fixing the processor – which is faster service (it is not in our control).

Next time you are waiting at store pay attention which cashier service faster. The first criterion (managing arrival) is natural assuming you are picking the leveled and shorter line by default.

Top 10 symptom of sick projects

  • Over-preparation for the meetings. The more people prepare in advance, the more likely they will be boring.
  • PowerPoint overdose
  • Documentation overdose
  • Big bang delivery
  • Invisible clients. If you don’t see client’s visiting something is wrong
  • Framework overdose
  • Developers are awfully quite
  • Phony celebrations
  • Phony roles
  • Analysis overdose

Sunday, November 19, 2006

“Every project plan should try something new otherwise it is boring.”

NP and I started figuring out what the legacy code does. First we started writing learning tests. First we copied the legacy code and made sure it worked. Then we decided to try something new. We decided to delete the existing code until we get to the revealing part. That worked great, it felt good deleting that code and quickly we discover what was needed to make our learning test pass.

Michelangelo was telling the literal truth when he explained that his principle accomplishment was removing unnecessary stone to get to the piece of beauty. We found the same pattern works to get into the key point of a legacy code too.

Monday, November 13, 2006

“If you can’t test it, it is not working”

This week I heard/read many misused words (untested) from many people. Words like “Transition plan” or “Best practices”. “We should be done by tomorrow”. “Should” sends a false sense of security. A better translation of it is “we are having a lot of trouble”. Best Practices means: I don’t know what they are. “It is Better” is too broad to mean anything. “Transition Plan” gets translated to: I don’t know how to handle this problem. The list goes on and on. It you can't test what you say why bother ... "Wasting people's time is the biggest sin."

Sunday, November 12, 2006

Week four-six (diff and merge)

The truck number on this project is 2. If two people get hit by a truck the project suffers irreparable harm. Every piece of work is also get assigned to these two people while there are more people in the team.

Collective ownership and shared code is a good next step for this team. No single person should claim ownership over any part of the system and anyone can make any necessary changes. The team goal should be to increase the truck number. The nice side effect would be the improved code quality. The good news is that the team members are all open minded and willing to work it out. The bad news is that pressure is already too high and technical debt is increasing.

Friday Nov 9th over having a wonderful food in an Indian restaurant – one of my friends said an interesting thing: “start deleting code…” - Looking back at 4th week, while doing a short iteration, that advice would have been the best strategy. It is obvious, the more software you have to maintain, the more it costs. The team is doing a lot of diff and merge of code. Customers are demanding and then something new comes. To deliver this version quickly, the team duplicates the code base, make the changes, and ship it. Sometimes the shipped s/w is not accepted and new things get added. Now, the line of code to maintain is doubled and code needs to be changed and merges in many different places. I’ve seen this cost cripple team’s ability and it is nearly impossible to merge a split code base without heroic and immediate action of 2 people. It feels good to write this: Don’t duplicate your code base. I have also mentioned short iteration and shortening the UAT cycle for fighting this syndrome. Please post a comment if you have a suggestion.

Thursday, November 09, 2006

A true story

Week One:

2006

I changed my department. I have a desk and a Laptop borrowed from my previous job. Time to get to work. I shared with the team how automated test (Nunit) works. I heard one person resisting the change. “Ya, Ok – this works if you have formulas but our thing is different ….”

Then I showed them the continuous build (Cruise control) - One developer got it working on his machine day after. There's hope.

Week Two and Three:

It seems that DRY “Don’t repeat yourself” principle is violated big time here. Smell like copy and paste everywhere. There are many screens doing the same thing and rules are scattered all over the code.

It doesn't take long to identify the communication problems. Business people are saying something today and want it tomorrow. However, they aren’t talking much with developers. I’ve picked up a lot of information about the project and people just by talking to them. Stand Up meeting sounds like a good start.

The good news is that my boss is very supportive. The dev managers saying "our business people never show up in the meetings." Well, I hope this time is different. I start building a good relationship with the users. My boss schedules a series of stand up meetings in the morning at his office. The good news is that business people are showing up and liking it. The room is covered with index cards. However the stand ups are taking more than 10 minutes. I reminded everyone to be aware of this overrunning meeting and started raising a red flag when people go beyond 1 minute talk. It isn’t perfect but at least business and developers are talking.

Week Four:

Comming soon....