Get started! Write code.

In Indian software world from where I come, we mostly work as vendors to the clients. Challenges we have as talked with Siddesh, on how client’s expectation is very high, ambiguous requirements and sharp deadlines, it might sound all too familiar in any part of the world.

Since Indian software clients are growing and maturing, it will be very important to experiment and spike with different solutions to see what works mutually with the client and the software team working with them.

Here is my take on it. It is just an personal opinion and there will be many arguments against it. But here is my point of view. The first primary challenge is to get confirmation if the contract is with us or not. But as soon as you get in touch with any technical details, start creating a spike. A version of spike’s meaning can be found here. You may argue that how can we start writing code without complete analysis. I am talking here about non production code.

Listen to this discussion on a idea of Test Driven Development between Jim Coplien and Robert C Martin in YouTube. They talk about writing production code of a telecom application (app size 2 million lines of code). They need half an hour to start writing the code. I think we can definitely write up some code to get a better understanding about requirement and gain some confidence.

At organization level, we can have repositories of all such spikes so that in future we spend less time in creating those. Such situation could arise for example when we end up giving the project to other teams with in the organization or if the project goes on hold. We will always have working executable code as our knowledge base. Thus, we will have information on the uncertainty of the requirement + the existing knowledge of business as usual. It is easy in theory then actually doing it. But that’s the challenge.

Happy Experimenting!

Pair programming Dojo Experience

I and my friend did a Dojo last month you can find it here. Below are the experience we had.

Gautam’s learning:

  1. How much the experiences of the 2 developers worked in different environments differ from one another. His way of coding, ways of finding & implementing solutions etc.
  2. Working with Vikram also forced myself to think of different ways to prove my point and to keep patients when there is discussion on a particular topic (Specially when we discussed about the starting point of the tests execution.)
  3. As far as coding is concerned I learn few shortcuts from tools and learned a better technique of renaming variables and functions which I knew how to do it but never thought of implementing not sure why.
  4. Above all I did my first TDD during this Dojo so got to learn a lot about it. Also learned about how keep your excitement in control while implementing various functionalists while working with TDD.
  5. Overall it was a small session of about 2 hours but we learned a lot from each other and looking forward to continue this Dojo.

My learning:

  1. How a solution approach is different of a person for instance: Gautam was insisting to add few more test cases to make sure the code is working were as I wanted to follow the rules that was instructed.
  2. The names of methods came lot better with 2 pairs of eyes.
  3. When we pair up with new individual how we must slow our self and the fellow member while learning new skills. Patience is the key.
  4. Learned a handful of key shortcuts which was a normal habit for the fellow member
  5. Adapting to work with new laptop with some of the keys placed totally difference from mine.

Even though most of our experience are alike, but adding it explicitly made a lot more sense of understanding.

Happy Pairing!

Sprint your life too

When I posted Share Blog! one of my friend Hiral Mistry (now Hiral Shetge) gave me an idea to write on How can we use Agile Software Development techniques to achieve some of the life’s small and big goals and tasks? Her idea was How to break goals into milestone and achieving it? It may sound more like goal setting but let me give a shot.

Agile Software development manifesto has 12 principles. But I will focus on 5 techniques on planing and execution of projects and demonstrate a real world example which I did recently.

  1. Time boxing : It means allocating a fixed time period
  2. Iterations (Sprint) : Multiple sprints will becomes a milestone
  3. Daily Scrum: A daily team meeting or self meeting
  4. Velocity: The speed at which you are accomplishing your tasks.
  5. Retrospection: To look back and see what went right and how to improve.

The above explanation is relative to the blog content. Now to explain it with example I recently did a mini project.

I am planning to write 3 blogs per month for my past whole decade.

You can read the complete post Past Decade blogs.

  1. It contains the example of time boxing which was 6 hours.
  2. It contains the Iteration of 3 days which will end up with 1 year of blogs. So I need 10 such sprints to complete a decade.
  3. Daily scrum means to check your status daily or planing daily, your team is your parents, spouse, siblings, partners etc. For those who don’t want to share can plan alone by checking their status. (A study has shown people only spend 1 hour for life planing in an year but more than 3 hours of vacation planing.) 
  4. It also contains my predicated velocity of 12 blogs per day (or 6 hours).
  5. Retrospection: Now that I have complete my 1 day of activity let me have some thoughts in it. It should have been done after 3 days.


  1. The 1st day went as it was planned. 12 blogs in 6 hours.
  2. But I did not follow the exact plan. I first listed out title of all 12 blog post that I wanted to write. Which I did couple of days prior of my writing day.
  3. I also wrote my first blog at a commute between office and home. Since my thoughts where flowing.
  4. The quality of all the post are not so great yet the idea is getting communicated.
  5. I feel, I should always write it on my waiting times thus not dedicating the whole day and still maintaining a velocity of 1 blog per half hour.
  6. By applying this alternate way, I might need my dedicated time to format the blog content.

If we have multiple such planned goals, milestones etc it will give us the fire in the belly to be motivated. This is how I relate practice in Agile Development. I hope Hiral too was thinking like this, If not Hiral please email me, I would love to post your ideas here.

Happy Sprinting!