Busy Times

As work gets busier and busier again this year, I’ve noticed the posting regularity to goes down. Which is not surprising.

Let’s hope this release goes well.

It wouldn’t be this funny…

… if i didn’t see it so often

Code Reviews

As your developers move to team lead and management positions, they spend less time per day inside of the code. Code reviews offer them a chance to maintain an eye on their code.

Code reviews are not the most efficient way to catch bugs. Unit tests, static code analysis tools, and using -Wall I have found to find problems than reading code.

Code reviews are not a way to enforce style and format. If this is important to you, just use a formatting program to change the code (Eg. cindent).

One of the values of code reviews is architecture enforcement. If you have a good team, this should not be an issue since they’ll comply to the design and architecture. Although, if your team doesn’t comply to the architecture, code reviews may catch these mistakes.

The value of code reviews is for your team leads to keep in touch with the code, any bugs they find along the way is just gravy.

Keeping it clean

The bug databases which are used as they should be, are very susceptible to having a back log of old issues (bug rot). These old issues will grow and grow as time marches on. Any reasonable person who examines of the size and requests in the database results in the conclusion that they can’t all be resolved.

During a triage we ask, “When should we fix this issue?” The response typically is either, “Now” or “Next Release”. Many people are afraid to ask this question, “Will we ever fix it?” There are some issues that we will actually fix in the future, but that list will always be smaller than what we won’t fix in the future. If we are never going to fix them, why do we keep them around in an open state?

There are several reason people choose to push a bug to the “Next Release” instead of choosing not to fix it. By telling a person we aren’t planning on fixing your issue, it leads to longer triage meetings since you will have to have a more vigorous discussion on a bug closure. It is much easier to placate with a, “We’ll fix it in the future, we’ve got a release to get out the door right now”.

I’m a person who enjoys stats and the bug database. When the bug database is properly used by the developers, it is a good way for me to get a feel as to the quality and progress of a release. The result of choosing to move your issues to the “Next Release” instead of considering closure will cost you in the long run in the following ways:

Groundhog day
We have to constantly discuss these same issues again and again is insane. When we are releasing M6, we are moving many issues to M7 since we know that we won’t have time to resolve them in M6. Once we start development of M7, we go over all the M7, moving many of them to M8. Repeat this process again and again. This results in us having to discuss these same issues again and again. Those issues that we continually bump will never get fixed. Close them as “WONTFIX”, man up and just do it.

Zarro boogs found
It clutters up the view for the developers. It is much easier for a bug to get forgotten when you have 200 assigned to you, instead of only 22. Seeing that my bug list empty, is just as satisfying as all of my unit tests as green.

Component Health
Measuring the health of your components is much more difficult. With all of these old issues cluttering the database, the view of the software components health can become skewed. I could see in the database that there are 420 bugs against “Component A” which could be in a much better state than “Component B” with only 80 bugs against it.

Projections
I use the database to do bug glide slope projections to help me determine if we are converging or diverging. Carrying a large amount of bugs make the projections more cluttered.

I will say that there has been a couple of times where I’ve broken the “WONTFIX” rule. There have been requests from the senior management team which are clearly impossible (usually defying the law of physics), and no amount of discussion can get them to drop it. These bugs get logged, and targetting approatiely. We typically visit these in the begining of the release cycle to ensure that they are given due consideration so that when we can provide an intelligent response.

First Post 2011

This is the first post in some time recently. I just completed a large project at work which was pretty crazy since December last year.

Posting regularity should hopefully return in the near future.

Decisions

“When you come to a fork in the road, take it.” — Yogi Berra

I have seen quite a bit of decision paralysis in many organizations. The quote above seemed to resonate with me.

Rarely in life do you ever have 100% of the data you need to make the informed decision. Sitting on your hands and waiting isn’t usually the best choice to make. Look at the situation, evaluate the potential future outcomes, and make the decision. Everyday without a decision reduces your time to act upon that decision.

Looking after the pennies costs dollars

Developers should have the best machines they need to get the job done. Unfortunately, the people looking after the pennies don’t see the dollars being wasted. This seems like quite basic logic, but I’ve had to have this discussion more often than I thought I would.

Lets go over the top arguments that I’ve faced off against while attempting to get our developers the machines they need to get the job done:

We only upgrade our machines every X years

• Argument: Companies sometimes mandate that a computer can only be replaced every X years, and you’ve got another Y years to wait.

• Approach: If you have a good relationship with the IT department, a swapping approach is quite effective. If a new employee (not in development) is being hired, the new machine goes to the developer and the developers old machine goes to the new hire.
  Alternately: Try one piece at a time. Attempting to get a purchase order for an entire computer system is usually difficult and requires several signature. But I’ve found that when we purchase computer parts to keep our ancient machine running, these are tracked as expenses (not assets) and seems to attract much less attention. You can easily replace your hard disk, RAM, and sometimes even your motherboard.

We would need to upgrade the entire company

• Argument: Many IT departments have a mandate to have a single supported configuration for the entire company. No deviations, no exceptions. This results in a controller using the same speed of a machine as a developer. A controller doesn’t have to wait 15 minutes for a journal entry to be updated, while 15+ minutes for a compile on an old development is not uncommon.

• Approach: Tell IT the developer is an unsupported configuration and they will maintain their own system and never call IT for support. This usually only works when it is a new hire.

Too expensive

• Argument: The company doesn’t have 2000$ to upgrade a developer’s computer.

• Approach: This approach is a logical numbers based argument. For instance, lets assume: {Slow Machine Compilation = 10min, Fast Machine Compilation = 2min, Compiles a day = 10, Loaded Labor Rate = 50$/hour}. With these assumptions, a developer on a slow machine is wasting 1.33h / day that could be saved with a faster computer. The slow machine is costing $66/day. After about a month or two, the computer will have paid for itself.
  Note: This is not as effective as I thought it would be. I’ve found that people were more interested in following the rules than trying to save money.

Giving developers the development platforms and tools which make them work most effective will make them happier and more productive.

To-do Lists

Over the years I have experimented with many variations of to-do lists.  I’ve tried post-it sticky notes in my cube, various different GTD software, text files, and many more without success.

My greatest hope was when the GTD software was coming of age. The concept of the GTD software appeals to me, but I’ve never been able to easily tailor it to the level of detail which works best for me (and have never been able to keep up with it). I’ve found that GTD software wants me to change my way of working (and follow their philosophy) rather than allowing me to easily configure the software for the way that I work.

Each person is different and there is no one method which works best for everyone.  My method is a simple home grown method which is very light weight and fairly effective.

I have found Microsoft OneNote to be a very good electronic lab book (I often wonder why there is no Mac equivalent which is of equal quality, but I digress). I’ve explored other options, but none of them appears to be as fully functional or free form as OneNote. Inside of OneNote, I create a single page for each day’s To-do list.  Where OneNote is not an option, creating a single word file for each day has worked, but is a bit more difficult to search and I’ve had trouble inserting emails to respond to. My template contains the following sections:

To-do:
This is a prioritized list of things which I need to complete. If there is a deadline, a date is associated with it.

New Items:
During the day, many tasks will get added to your list. If it is not an urgent and important task that has to be done immediately, add it to the “New Items”.

Done:
All of the items which were completed that day are placed in Done list.

Dropped:
Any item which you have taken off of your To-do list (or New items list) is placed here along with a reason of why it was dropped.

The usage of this method if quite straight forward.

Each morning create a new To-do list (copy the To-do list items of yesterday and clearing the work completed). Go through of yesterdays item in the “New Items” list and place it (in order) in the To-do list, or place it in the dropped list. Once all of the new items have been accepted, re-prioritize the entire To-do list and drop any of the items which are no longer relevant (or will never get done). Don’t be afraid to drop tasks. If you don’t, this list will become unmanageable. But for good measure, it is best to place a reason why it was dropped so that when you look back, you can recall why you didn’t do it.

During the day, you will get inundated with new items. As the items come in that must be worked on, add them to “New Items”. Also, as emails come in that will require responses, copy them into the todo list then move them from your inbox (which helps manage your inbox size). As work is completed, move it to the “Done” section. It is important not to delete it. You will find having a list of what has been completed very useful when you are trying to remember what you spent your time on.

This method, although imperfect, has been very effective since it contains very low overhead and it has been the only method which I’ve managed to stick with. Below is a word template for the “To-do” list.

Layoffs

One of the many ways to lose good talent is to poorly execute layoffs. I’m not just talking about laying off the good people, but the manor in which you execute them that result in losing the good people.

Announcements
When the employees hear of the layoffs, they should either be receiving their papers or a message from management that they’ve been completed. Having rumors running around the company or the press isn’t healthy for anyone.

Minimize the Number of Rounds
It is best to perform the minimum number of rounds possible. Best case scenario is a single round. Having round after round wears everyone out. For example, Cisco did minimal rounds, while Nortel continued to do round after round. We can’t say that the number of rounds was the reason that Nortel died, but the numerous rounds of layoffs at Nortel didn’t help the situation.

It is important not to forget that each round of layoffs is another round of overtures from your competition to your best employees. A question for you is, how many times can your people resist the competing offers?

Survivor Compensation
This is a tough one. Many times when I’ve been involved in layoffs, they’ve followed with raises (or stock/options to a lesser extent) for some of the remaining people. On one hand, it is a way showing your remaining employees that you value them. But on the other hand, some employees would have preferred that more people be saved rather than increasing compensation.

This one really depends on the team and the circumstances.

Voluntary Layoffs
I recall reading some folklore sometime where when one company did layoffs they booked two meeting rooms. A mass email was sent out saying that the company was considering layoffs and would be providing two information sessions. The company intentionally schedule both sessions at the same time. Session A was geared towards people who wanted the layoff, while session B was targeted for those who wanted to keep their jobs. When the layoffs occurred, everyone in session A was kept, while B was let go. This would never happen in the real world, but illustrates the example that some of your highly employable employees may consider having your company pay them to move to the competition.

We can also find numerous Dilbert comics out there where it highlights that you are paying your best and brightest to leave the company.

All Clear

Many employees want to know when the layoffs have completed and they can have a feeling of security. After they have completed, if they are completed, it is wise to tell everyone that you don’t have any plans to do more layoffs. In reality, all employees should know that the present and future cash position of the company typically dictates the headcount (Eg. If the numbers for next quarter aren’t met, the layoffs could occur next round no matter what was said last quarter).

Ensure Ted gets Whacked
Every team has some under performers (If you don’t know who in your team it is, it could be you) who I call Ted. It is best to ensure that all the Teds are let go before any of the others. This may seem obvious, but in the real world, some Teds always seem to survive the first few rounds. If you have any influence in the layoffs, your job is to ensure that Ted gets it before anyone else. Improper selection will demoralize the remaining staff, and also make the person who appears to be responsible for candidate selection look like an idiot.

Try to resume business and operations back to normalcy soon afterwords. After the layoffs, re-assure people as much as possible while being fully truthful. You do not want to be back in this situation at the end of the next quarter having this same conversation.

Are we there yet

Asking developers on an hourly basis if they are done, will NOT make the fix come faster. Just because you are receiving pressure from above, doesn’t give you a license to kill productivity for all of those around you. Now is when you need to control the situation and get things done by helping your team. This is not the time to request for up to the minute status updates and TPS reports. Interrupting your developer’s concentration constantly doesn’t help them work. Try the following instead:

• Make sure the correct amount of people are dedicated to the problem. There are many times when less is more (I’m not just talking about the editor), where the right two people are infinitely more effective than the wrong 20 people.

• Distractions must be minimized to ensure their focus doesn’t drift from the current work to other priorities.

• Provide the stakeholders with accurate updates on progress. If there is any heat or anger related to the issue, take it for the team so that they can focus on fixing the issue.

• Ensure the developers understands the issue, context, and time lines.

• Remove roadblocks soon as quickly as you can (or ahead of time if possible).

• Get the developers what they need to get the job done right.

Clear the path in front of them and let them work, don’t hold them back.

Next Page »

• Categories

  • Big Company
  • Crazy
  • Development
  • End User
  • HR
  • Intro
  • Management
  • Process
  • Product Management
  • Project Management
  • Quality Assurance
  • Small Company
  • Templates

• Archives

  • February 2012
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • February 2011
  • January 2011
  • December 2010
  • September 2010
  • August 2010
  • June 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009

• Links

  • Documentation
  • Plugins
  • Suggest Ideas
  • Support Forum
  • Themes
  • WordPress Blog

• Meta

  • Log in
  • WordPress
  • XHTML

• Recent Posts

  • Busy Times
  • It wouldn’t be this funny…
  • Code Reviews
  • Keeping it clean
  • First Post 2011