Monday, September 26, 2011


Why developers don’t use a Version Control System (CVS, SVN, Git, Hg, ...)?


Tale #1: The stolen code
Jack woke up early that morning, he goes to the kitchen and found it in a total mess. All things on the floor; his clothes and documents too; by that moment he already understand what happens, his house was robbed!

Among others things, he quickly notice that his laptop was missing too. And here comes the real problem, on the HD he had the sources of various application he owned; applications already sold and with maintenance contracts. He did not made a backup somewhere else.

After that incident he de-compiled an old version of the application. He also needed to update / rewrite some modules because they were not working as the production version. Also the decompiler output some code as assembler code.

By the same week he start using a Version Control System, with a web provider.

  • Time working without version control system: ~3 years
  • Time working with version control system, after a big loss: almost immediately


Tale #2: Corporate resistance vs. personal acceptance
Peter had worked as developer for almost  8 years, he has never used a Version Control System. At his actual Job a project was conceive to adopt a version control system. All developers were trained, all software was installed and a new corporate policy was created to enforce its use.

A year and a half after project completion, Peter still did not use the Version Control System, he just made the code changes and upon requests he upload the final version of every requirement to a branch. He also find himself with a bunch of conflicts because he worked on a very old code base and never gets the new one.

Recently he started a personal project, some software product he believe will be very popular and generate some sales. He start working with the same methodology: manual backups, total application rewrite because of code lost, inability to revert to a stable version after a big re-factor, among other bad practices. By the second week of work he, voluntarily, starts using Git.
  • Time working without version control system, on formal jobs: ~8 years
  • Time working without version control system, on personal projects: 2 weeks


Tale #3: Software vendor resistance
Company A (the Client), hires Company B (Software Vendor); to implement a new system. The relation include a full development effort of the vendor; and a mentoring period to local (at A), resources to gain experience on the new system and continue its maintenance labor. 

After months of work, on his facilities, the vendor finished the work and the user acceptance tests (UATs) began. At this point the problems start to arise. Every time a bug or problem was reported and the vendor starts working on it; another functionality gets damaged. When the root problem was tracked a guilty was identified: the vendor was not using any versioning tool; so they just get the last “stable” sources from disk and start changing it. After they finished their work they fix the reported bug; but introduce a new problem on another functionality. This can be addressed with  a good set of automated tests, but you still will have the problem of code lost over time: they can’t just rollback to a known stable version.


The Moral 
A bad behavior without consequences, is repeated.

The problem with our first case, is that he never felt the necessity to use a tool to control software versions until he suffer a source lost because of a house rob. His bad practice never gets punished.

Our second case, has the same root problem. On his past jobs he was never forced to use a versioning tool. So he just does not care about it. But, wait on his actual job exists a policy to use a tool. So why he does not use it? because the policy does not include any admonition to be applied when people do not follow the rules.

The third and last case is more of the same. The client company does not include on the service contract a section of regulations or procedures to be followed by the contractor. If the contractual obligation had existed along with a set of repercussions for the software vendor, the later will not be incurring on the flaws described.

For latecomers into the versioning tools usage
If forever reason you are new to versioning tools, here you have a short list of tools including the most popular, they all are free:


Wednesday, September 21, 2011

Agile Maturity Model [Level] Survey

Please take a moment to fill this short survey, when done you can share it with other people using or planning to use Agile methodologies.
Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.

Sunday, September 18, 2011

Time Management for the Agile Practitioner

I-Agile Time Management Implicit and Explicit Requirements
Agile methodologies require for the team members to be highly organized and conscious respecting  their time management habits. It will be impossible to estimate things like velocity, story points and other metrics used on projections and estimations, if the team is not working at a regular peace.

Agile explicit time management requirements
Under this category we can put all formal ceremonies for the specific methodology used. Taking Scrum as example you have: the [Daily] Stand Up Meeting, Sprint Planning, Sprint Review (Retrospective), Scrum of Scrums among others. These formal activities require certain level of commitment from team members: punctuality and respect for others time. Although they are not easy to avoid or forget because of group's pressure; it can happens to you if you have one or more of this problems: laziness or poor organized/erratic in terms of your work rhythm.

Agile implicit time management requirements
There is always time, a big par of it, for you to work alone: coding, documenting, doing research and other activities that not require team or group work.

Credits to dilbert.com
So you are working alone, in front of your PC full of potentially distracting elements: YouTube, music, social networks, email (both personal and corporate), your work phone, your cellphone, among others; and still need to implement that interface, code a unit test, document some past work all before the next delivery. You start doing your job but find yourself switching between phone calls, incoming emails, twitts, mentions, photo tags, your favorite song and by the end of the day you feel like you waste the last 8 hours and produce almost nothing.

In any Agile environment you need to respect all team work and also be very efficient and conscious about your time working alone.


II-Traditional Time Management vs. Agile Needs
Here I present you some examples of behavior commonly founded on IT personnel respect time management.

Architects and the ivory tower
Architects use to go “up” to their ivory tower and go down after talking to God with a bunch of specs, designs and diagrams. They work completely alone, leaving room for all kind of distractions; and also given the sense that they are like a black box. A box you only can ask and sit down to wait for the results  knowing noting about the time required for their job to complete.

This practice carries out other problems. One is the lack of understanding about the process for the other members. Other is the lack of transparency one core requirement of Agile software development. also it encourages team division: "they" and "us". Also introduces a sense of elitism.


Developers withing flow state 
These guys also work as black boxes, but their mayor problem is that they think the only way to work is under the Flow State. So they need to have music, toys, tons of coffee, no interruptions, a game console and any other gadgets used to loose themselves into the flow.

The problem with this method is that is not accurate, repeatable or time framed. Also it does not allow for team work.

What is the Flow State?
Yeah, if you are asking what is the flow, allow me to briefly describe it and point you to a good reference.
“Flow is the mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.
...
One cannot force oneself to enter flow. It just happens. ..."  Flow (psychology) (Wikipedia)

Endless re-factoring
Credits to sourcemaking.com
Developers often put themselves into a rat wheel when trying to deliver “the perfect solution”. After they just code and do some minor tests over the functionality, start re factoring because they got a divine message with a much better implementation in it. But remember Agile is time boxing.

The root problem is that the clock is still ticking and eventually your leader is going to come by and ask you for the solution and, because of our friend Moore, in that particular moment you will be on the middle of a re-factoring with the code broken. And it gets even worse, because you were in “flow” doing your code-”test”-re-factor iterations you just forget to commit your changes.

The same could happen to architects, when they get stuck reviewing their blue prints and after the death line they end with a very complex and partially defined solution. An architecture that if just could be built, will support millions of transactions and concurrent users, when the real need is just for a few hundreds. Did you get it?


III-Time Management Techniques and Practices to Avoid Time Waste
Be willing to change your bad habits
Yes, I had placed this requirement at first because for the following tools to work you need to be disposed to take action. No manager, lead or boss will be chasing you if you do not use them. It is completely up to you. That said, lets begin...

The pomodoro technique 
  • Type: individual and group 
  • Description: this technique allows you to be highly focused on a given task for a long period without felling tiered. Also it will arm you with the weapons needed to confront all kind of task from big  to small ones using a systematic approach.
  • Benefits: overcomes procrastination, be aware of time used on every task, manage and avoid interruptions, give a sense of control over your daily work and time. Know your real performance: pomodoros per day, week, month, etc. Finally you will be able to identify the mayor disruption sources and take action, just be aware that the first guilty could be yourself.


Pair programming
  • Type: couples or very small groups.
  • Description: this practice consist on a pair, usually of developers, sitting together in front of a single computer to do their job in conjunction. To avoid boredom the couple must have two roles: a driver and an observer. The first is the one writing the code an the second is observing the big picture, making suggestions and corrections. Think of this as a real time spell checker, bug finder, compiler and judge all in a single bundle. It is vital that the members switch roles on  a regular basis to avoid both for getting exhausted.
  • Benefits: when doing pair programming the time needed to complete a task could be reduced to 50%, enforces the collective ownership of the code, bugs and defects rate decreases as result of the constant review. PP also increases knowledge transfer (to see your partner doing a shortcut you did not know about and will save your tons of typing in the future: priceless). Boots you when sick or tired because of the casual conversational style.
  • References: All I Really Need to Know about Pair Programming I Learned In Kindergarten (PDF), The Costs and Benefits of Pair Programming Programming (PDF), Pair programming (Wikipedia).


Coding dojo
Note: If you already know this technique please let me explain why I mixed it up with time management practices, where is not formally one. If you did not know it, just ignore the previous note.
  • Type: group 
  • Description: let me start with some examples to illustrate this tool.
    • Chess masters: The average master (rated 2257) had 7.0 years of serious practice.  The average expert (2174) had 1.03 years of serious practice.  It took an average of 11,000 hours to reach 2200. 
    • Sport master, musicians and other artists: these guys require, on average, ten year of serious practice to master their domain.

      Where can you dig more about it?
      Here are some very useful references about the deliberative practice and the impact of it on mastering a field:
      - Ericsson, K. A., Krampe, R. Th., & Tesch-Roemer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100, 363-406. Summary by: David Zach Hambrick, 1998, gt8781a@prism.gatech.edu

      - What it takes to be great (CNNMoney).

      - Dr. K. Anders Ericsson (Wikipedia)

    So the key idea on Dr. Ericsson's work, and other researches, is deliberate practice, not just playing around or doing repetitive tasks. Deliberate practice, means practice a lot of time (of course); but also (and this is the important thing), to set goals, reach them, review your performance (retrospective), adjust your technique and after reaching your goals move the bar up with new ones.

    A good note here is this: practice (yes again); but in the sense that when you are practicing you are not doing the real thing. But remember is not playing, your are serious about it, the difference is that you are not doing the final job; just polishing out your tools.

    Let me use well know case of Tiger Woods, and to quote the CNN Money article,
    Tiger Woods is a textbook example of what the research shows. Because his father introduced him to golf at an extremely early age - 18 months - and encouraged him to practice intensively, Woods had racked up at least 15 years of practice by the time he became the youngest-ever winner of the U.S. Amateur Championship, at age 18. Also in line with the findings, he has never stopped trying to improve, devoting many hours a day to conditioning and practice, even remaking his swing twice because that's what it took to get even better.

    OK, now you could be arguing that your are “practicing” 8 hours a day at your workplace. But in other words, your are practicing by messing up with the real thing. Spending customers money and doing it bad with the real product!

    Will you let your children go out on a bike with no previous practice and supervision?
    Will you get into a commercial flight knowing that all crew members are interns?
    Will you feel comfortable with armed police officers around without target practice?

    So why we, IT people, want to manage that million dollar project without previous practice experience in team work?

    Getting back to the coding dojo, you probably already know what it is about. 
    “A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in DeliberatePractice in order to improve their skills.” (codingdojo.org). 
    In essence is a practice meeting to get proficient on any other agile technique. Doing it wrong but in a controlled environment. Is a mix of concepts borrowed from martial arts practice room (dojo) and the Dr. Ericsson's work (deliberate practice). I will not dig into the details of Coding Dojos, rather point you the core concept: practice all your tools (Katas) with certain regularity and discipline (deliberate practice).

  • Benefits: they are implicit on the illustrations and description but to repeat the mayor one: practice, fail and learn A LOT, in a controlled environment. Going back to our main subject, a coding dojo will help you manage better your time by letting you practice your skills knowing your limitations and reducing anxiety caused by lack of knowledge or practice.

  • References: codigdojo.org, How do you put on a coding dojo event? (Youtube), Coding Dojo (WPI, Computer Science department), The Cognitive Psychology of Chess (www.chess.com).

Time box yourself and always do a retrospective
  • Type: individual
  • Description: this is a core Agile concept. If you really want to deliver some value to your customers always remember: a part of the solution is better than nothing, and better yet if is the most important one.  So whenever you start feeling out of time bring up your red flag, negotiate the scope but never the due date. No matter what customer argue at the end they will be happier with a partial solution than with nothing.

    And, what about retrospective?
    Retrospective is the way for you to improve your excellence revealing obstacles, disruptions, flaws on estimation and other problems; causing you to fall short. No matter what happens, always ask yourself: Why was that way? It could have been better? How? ...
  • Benefits: keep people focused on what's most important. Don't lose time to perfectionism (endless re-factoring),  overcome complex tasks. 

IV-Conclusions

Agile methodologies expect team's members to be very proficient with their time management skills but traditional software development practices, corporate culture and bad personal habits (like procrastination and perfectionism) are directly opposed to that goal.

We need to be aware of that and use all techniques possible to increase our skill on time administration until they become natural, effectively changing our culture.

Subscribe to our mailing list

* indicates required
Email Format