by on

One of the common answers a developer gives when s/he notices a bug is that “it works in my machine”. This was so common and always boils down to the configuration difference between the testing environments and development environments. It is not so easy to keep the development and testing environments very similar but lots of those could be scripted and made automated such that it is an executable document. There are also lots of development hygiene practices that needs to be strictly adhered to avoid these kind of bugs.Confused

Where could things go wrong?

There are many things that could go wrong, here are some of them in no particular order.

  1. Poor version control – Either the code is not checked in(sometimes extra files locally modified for debugging) or the branching/merging is mismanaged.
  2. Incorrect dependencies and libraries – The dependencies/libraries are manually copied to the servers. Example – copying some jar files to tomcat, could easily go out of version between different machines.
  3. Testing only in debugging mode – When testing at the developer’s machine, developers have a tendency to run in debug, breakpoints in the code will give ample time for the application so that synchronous issues do not crop up during developer’s testing.
  4. Not testing at all – This sounds silly, but when the pressure is high chances are that the code is committed without tests and then bugs have to appear to give time to finish the coding.
  5. Incorrect environments and test data – Large projects have a tough time managing test data and environments, developers could be pointing to an outdated external environment or using only a narrow set of test data.

“Image courtesy of Grant Cochrane / FreeDigitalPhotos.net”.

by on

If you want to walk fast, walk alone; if you want to walk far, walk together

When I talk about pair programming, I am confronted with things like return on investment, efficiency etc. The arguments which come against are with very simple programs and simple domains where it does not matter you pair to program or test drive the code. Beyond the fibonacci and measurement problems there are complex domains which people get involved to solve problems and pair programming helps there.

A good analogy is racing. Racing falls into circuit racing and rallies, if we note that circuit racing like Formula-1 or driving around in circles like in NASCAR has only one driver. These ones are repetitive with relatively very few unknowns and parameters for the driver to take care. The moment you know about the car condition and the track conditions and few laps taken then the driver’s mind is on autopilot. Rally unlike circuit racing has lots of challenges, we just roughly know the route and it could be riddled with lots of surprises and obstacles. There is no way that a driver without a co-driver (navigator) could win the race.

Pair Programming

Programming at work is like rally driving, many of the examples which people take up for classroom sessions are similar to Formula-1 or NASCAR driving; which is the primary reason that most of them fail to see the potential benefits of pair programming. Depending on the nature of the task at hand we should be able to decide if we need work in pairs, group or alone to find a solution to the problem. Having a blanket rule to always program in pairs or avoid pair programming will force us to fit into one of the styles of work which may prove counter productive. Always failures are taken as strong examples than successes and if we fail in choosing the wrong approach, chances are high that the approach itself will be called a failure.

Image courtesy of patrisyu / FreeDigitalPhotos.net

by on

It is around 6:47 am, Novi’s wristband detects that he is about to wake up and it gently vibrates to indicate that it is time to wake up. It wakes him up at the right time and at a natural point in the sleep cycle that he is able to start his day immediately without the grogginess that usually follows an alarm call wake up. He collects data about his physical activity and finds that he has had enough of physical activities last week throughout to maintain a healthy lifestyle and he could afford to skip the exercise today. He switches on the TV just to find that the last month bill wasn’t paid, so he logs into his mobile app to pay the bill and the TV programmes come back to life. He also sets a recurring instruction to pay the bill automatically. A while later his phone alerts that his car pool mates have started and are about to reach his place in 30 minutes, he gets ready on time and reaches office. The office is equipped with a great canteen; it has multiple automated vending machines, automated trash collectors, state of the art coffee machines giving a perfect latte or cappuccino at a press of a button.

All this easy lifestyle stops at home and the cafeteria for Novi. Once he at his desk, the scene changes. There are around 20 developers in the team, they have been trying to integrate their code for the last one week and they had not been able to do so. Meanwhile the previous release had way too many bugs in production and it had to be rolled back which earned lots of bad reputation for the company. Every one in the team were angry, frustrated but still trying very hard to get through their day. People fell sick easily and there were not many people who could read another one’s code to fix bugs. The environments were not consistent in setup; it required long term context and undocumented knowledge to set an environment from ground up. People wished that the day at the office gets over soon so that they could go back home and rest.


CD

Why this difference in lifestyle between personal and work place. Is it possible to have a cool and easy lifestyle at work? Yes it is possible, with some effort; just like how you have to invest in some gadgets and software to make your personal lifestyle cool. That lifestyle which can make our life cool and easy at workplace is “Continuous delivery”. Continuous delivery is a lifestyle choice for software projects, it requires upfront investment in learning the methods, practicing with discipline and using the appropriate tools (software and hardware).

In one of the recent projects we completed, we were having lunch with the product owner. He said  “for around 10 years, a software release meant a tough long week at the office and now things have changed so much that I am able to have lunch peacefully while a release is going on”.