One small step for a man, one giant leap for mankind

5 בינואר 2011

תגיות: ,
תגובה אחת

Lately I had a lot of thoughts about how to introduce a change within an organization.

For a while now I am giving some talks about leading a software development team, focusing each time on a different facet, such as: Quality, Architecture, Recruitment Process and etc…

(I have combined some of those thoughts into a short lecture, which I entitled Fostering Software Craftsmanship (Building Successful Teams) and it is given as a part of the IL Tech Talks).

But here is a phenomena, I encounter each time.

Most of the audience understand the importance of the concepts, but really struggle with introducing them to their organization.


  • Writing Unit Tests will lengthen my development time!
  • How much time should I "reserve" for doing Refactoring?
  • How do I explain to my manager that Refactoring is important?
  • Code Reviews are difficult, because people have different tastes!
  • Code Reviews are taking too long! We will not be given the time to do it, ever!
  • Continuous Integration will take a few weeks to accomplish. I won't be given any time to do it in the near feature!
  • Those concepts are great, but the time to do them should be allocated by the management.

I am sure we all heard those sayings. Heck, we even have given those once! (No… Not really 🙂 )

Though I have a lot to say and comment about each and every one of the above statements – there are some broader aspects I must cover first.

We all hate changes, don't we? Doing Unit Tests, investing our time in Refactoring (or Builds) – those are just an extra activities that we have never done (or done correctly).

One should really invest his own time in order to polish those activities and doing so is just recognizing that we need to change. As humans, we find it extremely difficult to accept changes.

Jack Welch understood it perfectly, but nevertheless he succeeded to introduce a lot of changes to GE. Jack Welch found the change to be exciting, daring and imaginative.

GE success can be rooted to its ability to change and to change fast.

However, applying change in the simplest way doesn't work.

We cannot accept the change all at once. Evolution takes its time; Therefore, in order to accept the change we also should adapt one step after another.

(It's really like Refactoring Steps: One small change at a time, compile and test).

Sometimes it takes years to introduce all those concepts to your teams:

Start by a simple task, like code conventions or source control layout, then teach unit tests and invest in teaching code smells, continue by applying rigor Code Reviews and etc… and etc…

Doing everything in one big bang just doesn't work. I have seen several teams that got introduced to Scrum or TDD in a matter of weeks. Those are big changes to somebody who didn't evolve to the "right" point. Needless to say that the failures that those teams experienced were so discouraging that till now some of those Software Engineers hate TDD and claim that Unit Tests (even not TDD) are plain waste of their time.

You shouldn't be surprised that applying all the great concepts to your organization will take years.

One step after another; One small step for a Software Engineer, one giant leap for an Organization.

Close-up of Astronaut's Foot on Lunar Surface

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

תגובה אחת

  1. urig17 בינואר 2011 ב 23:49

    Thanks for this inspiring post Uri – I I fully agree with what you're saying here. The road by which these new practices will be introduced to teams is long and requires patience, agility and the strength to accept many setbacks in the process. It should be done one step at a time and if it seems to take too long and is sometimes fraught with frustrations, there's one technique that's helped me alleviate these – patting myself on the back :).

    The idea is this: the road is long and the tendency is too look ahead at the many miles yet to travel. There's so many things that can be done better, but so little time to do them. To balance this I just sat down one day and made a list of all the changes I've been able to introduce so far. Little by little these have accumulated into something significant. This allowed me to look back and focus on the achievements rather than on what's still missing. I patted myself on the back for what I've gotten done so far and that put the wind back in my sails.

    The evolution of this was to make a plan for the future for introducing many other changes to the team – one step at a time just like you said. It takes time, the plan changes and some changes will even fail, but the step by step approach will get you there slowly and surely.