by on

When beginning to work out for the first time, the first exercise I tried to do was to use the dumbbells to build up my arms. That is when the instructor caught hold of what I am doing and explained the difference between useful core strength and body building. I should first look to build my core strength before I could bulk up the muscles and flex it, also there is a risk of muscle detachment or broken bones if done wrong. My idea of building up muscles to flex was wrong and counter productive if taken the most obvious and easy route.

The scenario is also similar when I look at the choice of technologies when choosing to implement a new software project. The technology choices are often a trade off after considering so many concerns, some of the concerns may not even be technical in nature. If we chose a technology only because it is cutting edge or the latest one, then once the development hands over to maintenance; they may face lots of trouble because of the choice made.

The choice of technology should never be something that is analogous to flexing the muscles. It is always context specific, if the project’s main goal is to show case technical prowess and the software may be replaced within a short period of time with another one written from scratch; then there is no problem to use the latest and state of the art technologies so that we can flex our muscles.

There are too many questions to ask ourselves and consider the trade offs before we settle on technology decision. We have to consider maintenance team’s capability, fault tolerance, performance, life time of the software, scaling, frequency of maintenance and enhancement releases, which country and kind of internet connections will users use. There is no one size fits all or new kid in the block to address all the concerns at once, the choice is always a trade off.

Image courtesy of clker.com | Clipart

by on

Often I come across questions like

  • Will agile help me to reduce bugs?
  • Will agile help me to reduce costs?
  • If I use agile will I be able to improve predictability?
  • Is it agile to have unit tests?

The list is endless, these questions come from the teams which undergoes transformation from waterfall and they like to have a term for their new way of working. The very first project in my career, our team delivered to production every week. Everyone in the team were developers but wore different hats on different days. Each of us learnt to write unit tests, build and release to different environments, monitor production systems, automate functional tests in a team of 10. People coming in and out of the team was always breezy, there were no dependencies on one single person. I would say that was one of the ideal projects I have ever worked.

What process or methodology did we follow? “Do what makes sense!” Yes, that was the only thing which was told to me the first day I joined the team. No process, no compliance; only sensible things. Now if I replace “Agile” with “Common sense” will I get the answers to the questions?

  • Will agile common sense help me to reduce bugs?
  • Will agile common sense help me to reduce costs?
  • If I use agile common sense will I be able to improve predictability?
  • Is it agile common sense to have unit tests?

We got so much used to having process and methods as a safety net and rely on work instructions created out of those to execute day to day work. In my observation it is only some sensible practices which are fine tuned to the present scenario works. There is no substitute for common sense.

by on

In medical field there is a term called Sutton’s slip which is used when possibilities other than the obvious are not considered. Problems are everywhere and when we try to solve them we tend go for the obvious solution. When going through the 11 laws of fifth discipline by Peter Senge I inferred that there are more problems created through easy corrective actions one takes for the problem. If we focus on the obvious solutions then as per the ‘laws of fifth discipline’ things seem to get better and then becomes worse than it was ever before.

Problem

One example I could think of ‘where going for the obvious was a wrong choice’ was at my workplace. Our software development team’s velocity was in a constant decline. Velocity directly translated to the requirements getting implemented and clients always had a close watch on it. One of us in the team decided to include a metric ‘Cost per story point’ to help bring visibility into the cost associated with building a feature which in turn he believed will drive the team to be conscious of the output and take corrective actions  much early on to reduce the cost. What followed was the inflation in the estimates, the team was using fibonacci series as the estimation scale. We had 1,2,3,5 as possible sizes for our stories, what we did not notice was that there were no new 1 point stories added to the backlog. Slowly inflation ate up the 1 point story and the two point story became the beginning size. Though it eventually led to a lower cost per story point, the value delivered was much lesser.

When you’ve got a hammer in your hand, everything looks like a nail

Reference – Cognitive Biases, Law of the instrument

Image courtesy of Stuart Miles / FreeDigitalPhotos.net