by on

In the movie Soldier, the soldiers are humans selected at birth and conditioned to obey orders and win battles. The antagonist comes up with genetically engineered super soldiers who are better in every single metric like long runs, fast climbs, weight lifting and many more. As a final test the protagonist is put up for a fight against a genetically engineered soldier, loses the combat. He is thrown away into another planet  along with the trash and two others who died in the combat against the mutant soldiers. He ends up in a new planet and gets taken care by the people there. The antagonist tests the mutants’ battle skills at the new planet, which brings them to fight against the hero who kills them all in a real battle field scenario and takes over the ship.

Metrics of software development and developers if not used at the right level, will start giving us an illusion on control. They are more like a guideline which can hint at the presence of a problem rather than an assertion of well being. In agile projects velocity is one metric which is very visible to the client, what was once to help in planning becomes an important metric in presentations; so are cycle times, bugs per story, lines of code etc. The illusion created by strictly following all metrics taking actions based only on that will lead to two problems.

  • It will encourage work to be based on the metrics, like legally right but wrong in principle.
  • It will shift focus away from mainstream work resulting in loss/delay of work.
As far as I have observed, when metrics are limited as tools for diagnoses and planning they have helped a lot improve the progress by allowing the individuals to reflect and retrospect; take small corrective steps. When a single person takes a strong corrective actions on the course of the project based on the metrics then success was a stretch goal.

Image: Michelle Meiklejohn / FreeDigitalPhotos.net

by on
  • Work never stops coming to you everyday, forces visibility into everyday’s work.
  • Deployment to production is too easy and predictable, no chance of heroism.
  • No one person holds the information, every one knows every thing; no one is indispensable.
  • Complexities are sorted out earlier, it is difficult to get into a messy situation and raise like phoenix from the ashes.
  • Creates self managed teams, making the lead positions redundant unless hands on.
  • Makes you assess, try and embrace new technologies; prevents you from becoming an expert in Z platform.

by on

Many of the indian cities today were part of planned development and expansion several decades ago. Plenty of  self sufficient segments of land which could be administered very well by local civic body comprised of cities. These segments had a water tank/lake, playgrounds, schools, libraries/community centers, health care centers, bus depots and segregation of commercial and residential areas. Then there comes a boom in economy and the demand for revenue generating buildings rise. Land becomes a premium and suburbs begin to become part of an extension of the city.

What was once considered to be essential like schools, libraries and other backbones takes a backseat. The focus is on converting as much land as possible into dwelling units and business centers. The demand of of schools, health care centers, libraries, playgrounds are all proportional to the population. As the growth of the suburb is not organic, the essential backbones get built much farther away than in the desired localities. People spend a great deal of time together with their families during transit to work, school and clinics. Simple tasks which was once very easy to accomplish because someone lived in the city becomes a tough task which keeps them occupied for a good part of their productive weekday. Reduced physical connection, long commute times, erratic food habits, irregular sleep patterns comes as freebies because of an unplanned rapid development.

I have observed large software projects which start small with a plan in mind. Backbones like continuous integration, testing frameworks, common goals for the team gets set and progress starts. The ramp up of the team is done slowly and organically such a way that the new members gets a good idea about the goals of the team and the individuals. The code begins to grow and a conscious effort is needed to monitor to modularize or improve its design to increase efficiency. At some point if the business decides to increase the spending on IT to add more functionality in a short period of time, the immediate tangible number which comes to mind is the number of people and the amount of work done. It is even more easy to use those numbers and set up a metric in place to monitor progress, create plans based on extrapolations/number crunches and execute them as necessary.

Sadly the metrics driven development is like building skyscrapers by counting just the floors built without a second thought about the long term habitability of it. An illusion of progress is created as more functionality is added in a short time by the sudden increase in team size, which makes the other not so visible aspects of a software project like design, code quality, usability to become invisible. More effort gets centered on the deadline with added functionality and individuals become more focussed on the task at hand ignoring the other aspects. Gradually the mindset shifts from building a castle to laying the bricks in order.  It is necessary to acknowledge that an organic ramp up is necessary and limit the team size to a level where plain interactions and code base are enough for communication. If there is a need to increase the team size to get more work done, after a careful analysis work should be split, parallelized and a new team has to be forked off.

Image: Damian Brandon / FreeDigitalPhotos.net