I don’t think productivity is directly influenced by time alone. There are other important factors which make it or break it.

• There are days when I can get a lot done in lot less time and other days life moves slower than a snail.
• There are days when I can stay very focused and productive for up to 15-16 hrs and there are days when couple of hours of work seems like torture.
• There are certain type of tasks that I can get very productive very quickly and certain type of tasks which takes times to get into the flow.
• If I have a vested interest (financial, reputation, learning, etc.), I train myself to stay focused and productive longer (can back-fire as well.)
• There are phases of one’s life when one can clock in more hours and there are phases where one cannot; other things are higher priority. If forced (soft or hard), it usually leads to wrong behavior.
• I’ve seen many people who are very deadline driven (including myself.) I get a lot done when I’m working against hard deadlines. Yes, quality certainly takes a hit, but in many cases delivering slightly lower quality stuff is more important than not delivering at all or delivering later.

If we look at these various aspects, we get close to a start-up environment. And under these conditions, we do see teams being quite productive and delivering interesting products.

Applying this in a different context/environment usually back-fires.

What do you think?

This blog post was trigger by Tim Berry's blog post on Productivity Paradox: Maybe Less is More.

Branching is a powerful tool in managing development and releases using a version control system. A branch produces a split in the code stream.

One recurring debate over the years is what goes on the trunk (main baseline) and what goes on the branch. How do you decide what work will happen on the trunk, and what will happen on the branch?

Here is my rule:

Branch rarely and branch as late as possible. .i.e. Branch only when its absolutely necessary.

You should branch whenever you cannot pursue and record two development efforts in one branch. The purpose of branching is to isolate development effort. Using a branch is always more involved than using the trunk, so the trunk should be used in majority of the cases, while the branch should be used in rare cases.

According to Ned, historically there were two branch types which solved most development problems:

• Fixes Branch: while feature work continues on the trunk, a fixes branch is created to hold the fixes to the latest shipped version of the software. This allows you to fix problems without having to wait for the latest crop of features to be finished and stabilized.
• Feature Branch: if a particular feature is disruptive enough or speculative enough that you don’t want the entire development team to have to suffer through its early stages, you can create a branch on which to do the work.

Continuous Delivery (and deployment) goes one step further and solves hard development problems and in the process avoiding the need for branching.

What are the problems with branching?

• Effort, Time and Cognitive overhead taken to merge code can be actually significant. The later we merge the worse it gets.
• Potential amount of rework and bugs introduced during the merging process is high
• Cannot dynamically create a CI build for each branch, hence lack of feedback
• Instead of making small, safe and testable changes to the code base, it encourages developers to make big bang, unsafe changes

P.S: I this blog, I’m mostly focusing on Client-Server (centralized) version control system. Distributed VCS (DVCS) have a very different working model.

How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.

What is Red Time?

• During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
• While Programming, time taken to get the logic right for a sub-set of the problem.
• While Deploying, downtime experienced by users
• While Integrating, time spent fixing broken builds
• While Planning and Designing, time spent before the user can use the first mini-version of the product
• And so on…

Basically time spent outside the safe, manageable state.

Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.

For example, there are many:

• Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
• Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
• Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
• Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
• And so on…

I highly recommend watching Joshua Kerievsky’s video on Limited Red Society to gain his insights.

Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.

At Industrial Logic we have a new product called Sessions which helps you visualize your programming session. It highlights your red time.

On many applications I’ve worked on, Authentication is a big pain.

• Usually its an usability hazard. (No one likes to authenticate themselves over and over again)
• Since its a cross-cutting concern and every application has some special logic for authentication, we spend way too much time hand crafting the best strategy to implement and test it to make sure our application is secure.
• When you have multiple applications and you want to implement single-sign-on, the pain just exponentially amplifies.
• On high scalability apps, Authentication (session validation) can be expensive from performance point of view

In the search of simplicity, I’m wondering if there are alternative techniques to implement authentication on certain types of applications.

One thought comes to my mind, which I’m curious to try. I’ll start with a very specific example and then expand it to other applications.

While building web applications in the category of social networking or eLearning or some other category, where retrieving data from the app is not very critical from a security point of view:

Even if you have a stale session cookie, GET request works fine without requesting you to authenticate. Only when you POST, authentication kicks in.

This approach will certainly not work for a banking application, where reads also have to be very secure. But for many application reads don’t need to be very secure. Also most applications have relative very small number of POST requests, which means very few times the user would be nudged to authenticate themselves. Most RESTful frameworks can have this built in.

Can this approach be used for rich-client apps instead of just web-apps? I think so.

What am I missing?

A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.

How do you know you are ready to start iterating? In some cases, very little is needed before the first iteration. In other cases, rushing to iterate (because you were told to) can lead to weeks of time wasted overly focused on delivering a poorly understood product.

In this presentation by David Hussman titled Getting Ready to Produce at Agile Mumbai 2010 Conference, David provides concrete tools for discovering your product context and assessing whether you are ready to start building and / or iterating. Participants learned tools for defining how much process you need and tools for truly understanding what you are building and why, as well as who will use it, why they will (or will not) use it and why.

At the Agile Bengaluru 2010 conference, Sai Venkatakrishnan and Harikrishnan express their concern on the monotony that has crept into the way we develop application and how it affects us being Agile.

We follow agile, but are the systems we are building Agile?

A case study presented by Siddharta Govindaraj at the Agile Bengaluru 2010 Conference describing a period of 6 years in two startup companies that he was involved with.

The first part covers the period from 2004 to 2006 when Sidd was working with a startup based out of Singapore. He explains how we moved from doing ad-hoc development to adopting Scrum. Adopting Scrum was a big improvement over our previous ad-hoc approach but Scrum also led them to make some classic mistakes (from a lean point of view).

The second part covers the period from 2007 to 2009 when Sidd started his own company in India. The company was started with Scrum right from the beginning. He explains how we evolved from vanilla Scrum to Lean and Kanban.

This morning I got hooked to a new band. I’ve heard the band before and I’ve had others praise the band. It was only this morning, when I stumbled upon a particular song by the band and started enjoying it. After that I went and explore the whole album and other albums. Its been 8 hours and I’ve been tripping on their music.

To think about it, software is kind of same. Usually its one sticky (killer) feature that gets people hooked to a new software. Once they experience that feature, without much push, they discover all kinds of interesting features and innovative ways to use them.

As someone building a new product how do you figure out what that feature would be?

I’m aware of 2 approaches that have worked in the past:

• Agile/Lean-start-up philosophy: Build sketches (quick and dirty versions) of a few features, put it in the hands of real users and see what might click.
• Open Source/Eat your own dog food philosophy: Build something that addresses your personal itch and see if others have the same itch.

What other approaches have you seen work?