Pain the Ultimate Motivator

Gil Zilberfeld asks Why Did Agile Originate In Software?
Answer: the pain!
The software development business has been suffering for quite some time. The Standish group has been reporting (int heir Chaos report) that about 2/3 of all software projects does not meet initial expectations (either the completely fail or overrun budget/time or both). And for the past decade or so those numbers have not changed drastically.
And frankly every person involved in the software industry is familiar with this pain. Developing software is a hard business.
And where is a pain there is a reason to change. That is the nature of evolution. Successful species do not change. If the methods and techniques that predated agile were good enough there was no reason for Agile to be invented (or is it discovered).

The First question

One of the first question we start with at a new organization is trying to understand the current issues. And we specifically ask the people involved what exactly are they trying to solve. We ask not because we cant tell. We ask to make sure that they are feeling the pain. In order for us to actually continue we need them to truly feel it.
“I just want to improve” is not good enough. In order for agile to take hold and really succeed. There must be a a big enough pain. Otherwise the people involved most likely will not have the necessary motivation to stick with an approach that in many cases seems weird and counter intuitive. In order to change we must feel a pain.

How come we’re lucky to be the first citizens in agile-land?

Since Pain is common place in our industry we had enough people motivated to try new things. Eventually, I think, that what made agile evolve. Not so lucky are we?

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Random Thoughts,Self Improvment

Starting TDD – One Day Experiment

A repeating question I encounter a lot is how to start with practicing TDD. in fact a while back I wrote a series of post on how one can start this in various contexts
(part 1, part 2, part 3, part 4, part 5, part 6, conclusions)
some people claim that TDD is a group activity, therefore it’s a waste of effort to practice alone. I believe that TDD is a personal skill, and while its better to have the whole team doing it, it can be practiced alone. Nothing should prevent you from trying to improve the quality of your code. (and in most cases the added value will negate any delays you might experience initially).
in this post I’m offering another way to start. in fact I think that a controlled experiment might be a better way to describe this. but anyway

Practicing TDD for 1 Day

To start you should dedicate a full day for this. while I'm sure this exercise can divided into several sections, I think that to truly benefit from this (and avoid the cost of context switching) it should be done in a single day.
By the end of the day I expect you to achieve the following:

1. have a good understanding of what TDD is and what are the rules to follow
2. write some basic unit tests on a simple problem
3. write a test case for your own system
4. have a basic understanding of the tools involved in the process.

I also expect that you wont achieve the following:

1. fully appreciate the costs and benefits of doing TDD
2. understand how to apply TDD in all situation
3. Be able to write tests to all parts of your system
4. have a deep understanding of Isolation techniques

(or put simply at the end of the day you will know some of the basics, but that’s about it)

Setup

in order to complete the day you will need to download and install some tools. specifically you will need a Testing Framework and a mocking framework.

Testing framework

any framework will do, really its not that important at this stage.

• .NET use MsTest or NUnit
• Java – JUnit
• c++ – GoogleTest

Mocking framework

pick one of the power tools available:

• .NET use Typemock Isolator or JustMock
• Java – PowerMock (you’ll need either EasyMock or Mockito in addition)
• c++ – Isolator++

(some of the tools are commercial so you will need to use their trial edition which is good for a few weeks)

Learning phase

The first step is to get a basic understanding of the principles involved. for this I would recommend the following session by Uncle Bob
Attempting as it might be don’t skip this part. It takes about an hour, but the important basics are in this. In order to succeed one must know what are the rules of the game and what are the expectations. doing TDD is not just about writing tests, its about how to write code differently. And the goal is to try this different way, not just write tests.

Do a Code Kata

pick a kata from the following page, any kata will do but I would recommend going with one of the katas in the Beginner++ section.
your goal in this step is to practice TDD on the kata.
that is apply the basic rules of TDD while trying to tackle a relatively simple problem.
I would expect you to be able to go through the kata (mostly) in under an hour

Learn Isolation Principles

The next step is to get familiar with your mocking framework of choice. Most likely, the easiest way to do it would be to go the the relevant tool website and get through the “getting started” or the “Introduction” parts. The goal is to understand what are mocking framework, what they are used for, and specifically learn the API of the tools and be able to use it.
If you want to invest a little more time and learn some of the theory behind this, here’s a very nice session (hour and a half) by J.B. Rainsberger which I personally like very much.
you should end this part by doing the following:

1. Create a new project.
2. To this project add 2 classes one that you want to test (Class A) and one which is used by Class A (Class B)
3. Add a method that just throw an exception to class B and make Class A invoke that method somewhere.
4. Next write a unit test which test Class A, specifically the part should activate the code in A that invokes the prepared method on class B.
5. Use the mocking framework in order to make this unit test work/pass.

Yes this is a very simple exercise, but in order to finish it you will need to pass through all the basic steps for using the mocking framework tool.

Take a break for lunch

Tackling the real system

The last part of the day is dedicated to write some unit test on your real life system. What we want to achieve is to actually write some tests on the real system that you actually works on.
The first step is to pick a place in the system to start in. The trick here is to chose an good part that on one hand wouldn’t be the hardest most complex part, but on the other hand still would surface the real issue that will be encountered later on. The ideal place should be a place that is focused on logic. Try not to go for upper part containing any GUI sections, and also try to avoid the lowest parts dealing with the data base (if there is one). If possible try to pick a class that reside somewhere in the middle tiers. hopefully somewhere inside the business logic.
After you picked your part, locate the class you actually want to write test for. When you have it, the first step is to locate the dependencies of the class you will need to handle. Start by writing those down on a piece of paper, and then dedicate some time to figure out how they are going to be isolated. Usually what helps is answering the following questions:

1. How are the dependent instances (the one used by the class under test) get created
2. How are they get “connected” (injected)into the class under test
3. what is the expected behavior you need in your tests

answering these question will help you later on in setting up the fakes (mocks) in your test.

Write some tests

next just write a couple of things you would like to test. The key here to start simple. think of a specific behaviors you want to test. for each behavior, think what is the initial state the test should start at, what is the action you want to test, and what is the expected behavior (result) of that action (and how you clean up after the test). When you have all those just try to write the test.
And always remember to have patient.
The first test in a new system is always the hardest to write. Even an experienced TDD’er is likely to take a couple of hours to actually get some tests on a new system. For a beginner it might take longer.

Summarize the day

Last action of the day is to think and reflect on the experiment. if you followed the steps, then you should have some tests on your real system. Now it is time to reflect on those and see what else you can learn. Think on all the things you accomplished during the day. Chart down the things that you need to invest more time in. Recap the main difficulties you encountered, and most important decide upon a few key actions you would like to take in order to continue your learning.
And of course let me know how it went.


Update
It seems that the kata site went permanently down so here some links to some code katas sites:

1. http://codekata.pragprog.com/
2. http://www.codekatas.org/
3. http://katas.softwarecraftsmanship.org/
4. http://content.codersdojo.org/code-kata-catalogue/

Read more »

Posted in: Agile practices,Development Practices,Self Improvment,TDD,tips

Customer Support

A couple of days ago I had a good conversation with a friend of mine regarding customer support. Before going into the actual discussion, I want to say that I'm a very strong believer in actively engaging your customers/users on all level, specifically one of the competitive advantages any organization can develop is having great support. In fact there is no excuse for not having great support. You don't have to be a big company, you don't have to use any fancy management system, you don't need to hire special experts at doing so. All you need is the will to establish great support and the persistence to actually go and do that.

Establishing great support, from my experience, has one of the biggest ROI in the organization.

But back to the discussion, specifically what we talked about is how far will they go and expose their support database to their users. Currently, while they do have great support, from a user perspective, once a call has been acknowledged as a defect or a needed feature there is no visibility as to its progress.

In most cases, either you have stumbled on a critical thing, resulting in an almost instantaneous fix (sometime in a matter of hours), or you have stumbled on something less important which go into an arbitrary hidden to do list. as a user there is no middle ground. The things that go into that future to-do list are going into a big black hole and there is no telling how long it will take to actually get a fix.

On the other hand when I asked why do they not publish the above mention to-do list, he told me that currently he fears that seeing the entire picture might scare off some potential and even existing users.

To that I said not likely!

Granted I'm sure that some will be scared if the list is big enough, However like I any kind of relationship being honest is probably the best long term strategy. Hiding the truth from your users has a big chance to backfire. As been demonstrated in several occasions (and being on that end as well I also can testify), you can't hide forever behind a hidden to-do list. At the end the users, will start noticing that some defects are going down that drain hole never to return. And if enough of them does so eventually you will have to deal with a damaged reputation and that's even less fun. Hearing once and again that "this will be fixed/added in a future version" without committing to a time frame, becomes annoying unless you actually see those in a reasonable time. And you never but never want to have annoyed users.

Personally I prefer to hear the truth, if you decided that the issue is not that important just let me know. If its that important to me maybe I'll be willing to pay for it. If not, just help me to work around this. I'm a grown up and I expected to be treated as a grown up.

of course we have also discussed some middle ground, one option was to allow all users to track only their open cases. Which probably wont change the fact that these things are not fixed, but will give a better indication to the actual status of things.

naturally in the long run the only true solution is just to make the product so good and the number of defects so low that this will become a non-issue. However that's probably a whole different story.

So share with me how are you handling your support at your work place? what more can be done in order to mitigate and find a good compromise?

Read more »

Posted in: Random Thoughts,Self Improvment

Integration Tests are not enough - Revisited

A while ago I wrote that Integration Tests are not enough (Part I). i Think that J. B. Rainsberger does the subject much more justice then in his latest session (Agile 2009) titled:

integration tests are a scam.

During his talk he also mentioned, as a side note, that what takes time and experience to master when doing TDD is the ability to "listen" to your tests and understand what they are telling you. I couldn't agree more, I wonder how we can help speed up this process.

Any thoughts?

Read more »

Posted in: Development Practices,Integration Tests,Self Improvment,TDD

The Fifth Value – Respect (cont.)

Some time ago I touched the subject of respect in the software development business. Yesterday I had the chance to talk with one of the persons working at  a client of mine. Beside of holding the respectful position of VP QA (the company is of medium size) the guy also allocate one day a week to maintain an IT business he once had which currently has a single client. After talking about how he ended up in this kind of arrangement, an obvious question for me was why does he keep on doing it. Isn't the fuss of handling a single customer to big to be worth the time?

The answer I got was:

Working for that client puts me in perspective. once a week i get the chance to function as a plain technician. This gives me the opportunity to get on my knees and work with the bits the bytes.

For me this is the essence of humility (which is a corner stone for respect), although the guy has attained the "big boss" status, he understand that there's more to it then just management, and in order for him to excel at his work he needs to get down as close as he can to the daily work the people working for him do.

I salute you!

On the other extreme,  a previous boss of mine once told me that he was advised (and agreed to) to treat every hour of his work as costing 2000$ (no, this was not the guy salary). The reasoning behind this that being so high on the food chain he should not waste his time.

For me this kind of attitude puts you on the opposite scale. Saying such a thing comes as close as you can (without actually saying it) to "I'm worth more then you are" or more simply "I'm better then you are". This is just being rude.

I wonder how would that guy take an advice that goes: "Unless you generate 2000$ profit for the company per hour, your not doing your job"

Read more »

Posted in: Agile Values,Random Thoughts,Self Improvment

Signs of a Death March

A "Death March" project is a project which is destined to fail. The term "death march" in this context was discussed at length in Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects.

I had the "pleasure" of leading a death march project and for me it was one of the most depressing experiences I had so far. In my case the death march was caused by the wrong decision to commit to an impossible schedule to get a funding for the project. We all knew the schedule was unrealistic but we thought that its better to get the money now and worry later. It goes against the notion of "Fail Fast" but at that time I was unaware of this notion. (Actually I've learnt about the whole death march thing only after the project was terminated).

Being inside a death march is not fun. I think that doing a death march has a huge negative effect on the people involved that usually outlast the project itself (if the team is lucky enough to survive this project). The funny thing is that I've seen companies that intentionally put their team into a death march in order to drive the team to achieve more. The logic behind that is that if you set a high enough goal and do your best to get there you will achieve more if you just aim and reach a reasonable goal. I feel that this logic is flawed on so many level that I don't know where to start.

Signs of a death March

I think that one of the biggest issue with a death march is that in many cases the participants are not even aware of doing it. In many cases people ignore the warning signs, waiting too long to take action. In that sense admitting the problem is half the solution.

Here are some signs of a death march

"Schedule is tight but if everyone works harder and things will go smoothly we can make it" - This is the first sign of trouble. The longer until the due date the more likely you are doing a death march. How many times does things goes smoothly? Isn't the team working hard now? Where did all the margins disappeared?

"We charted out most of the big things but some things are still missing" - Another sign meaning there is still work which is yet to be scheduled in. It also indicate that someone is does not even have the time to fully understand what is really necessary to get the release on time. Where will the time be taken to actually do the work? this time the closer it is to the due date the

"We don't see people working until 22:00 in fact not even until 20:00" - The project due date is in 4-6 months. Do we really expect people will work 12:00 hours a day until then? and if they do will the be effective at that for such a long period of time? 12 hours per day is not Sustainable Pace, If that's what will save the project the project is doomed.

"We are trying to cut everything that is not a must for the release" - Put differently "Its most likely we wont finish all the necessary work, I don't even want to think on the thing that are not absolutely mandatory"

"I'm really sorry, but something important came up" - The manager gives an excuse on why he cant attend the meeting which has been scheduled and accepted by him. Is it that important that it cant wait a couple of hours? or do you just have too much work as it is? and usually a stressed manager will most likely means a very stressed team.

 

And last, in most cases - you can just see in the eyes of the people involved that they lost their belief.

So what other signs have you encountered?

Read more »

Posted in: ALM,Random Thoughts,Self Improvment

If its too hard - do it more often.

During a panel in the latest Scrum gathering, a question was raised regarding how deliver a potentially shippable product each sprint if it takes 3-5 days of stabilizing the product to get it to a release level.

Its a relatively common question which has various answer, however Scott Ambler has given it a gem of an answer(in my opinion at least). His answer went something in the spirit of:

if it takes you that long then you must do it more often, in fact keep on doing it until you learn how to reduce the time that needed for stability.

This somewhat relate to a previous post of mine,  Cost of Change – The Fear . Investing the effort to fix pains that we learnt to live with is always a low priority. In fact the bigger the pain is, its harder to fix so it slips down the list. After all, if it was easy, we would have done it already.

So Scott gave a good way out. Basically he advices to enhance the pain! If its a scratch cut it with a knife. if its a twisted leg, break it completely. Make it hurt so bad that ignoring it is no longer an option, and the only course of action will be to fix it. A drastic approach but one which works.

Read more »

Posted in: Agile practices.,Random Thoughts,Scrum,Self Improvment

Capability of a Developer

Sometimes in life you join a discussion expecting the least, but surprisingly enough profound wisdom can be found in the least expected places.

In a five minutes talk I heard a very wise man give a very good analysis of what is capability.

It translate to something like this:

Capability of a person is a combination of two elements

1. The "body", which dictates the true ability/talent of the person.
2. The "spirit", which dictates the will of the person.

Taken to our domain, a developer capability will be a combination of the his technical knowledge(talent) and his motivation (will). When I want to increase a developer capabilities, I can either try to help him increase his technical know how, or try to help him on his motivation side. For best effect I try them both.

Some coaches I have encountered are making the mistake to assume that will on its own is enough (did someone mentioned "The Secret"?). I'm sorry, but no matter how much I shall "will" it, I CANT write code with absolutely no bugs. Maybe its because they lack the capability to increase true ability in a person?

Read more »

Posted in: Coaches,Random Thoughts,Self Improvment