by on

sashimi-472778_640At a fine dining restaurant if I complained that I did not like the food; immediately the chef, waiter and the food taster run to the dining table to assure that I don’t feel disappointed and provide me an alternative as soon as possible. If you take a look behind the kitchen door then we will come to know that they take lots of precautions to make sure that this never happens at the dining table. Chefs have a tough time to keep taste and quality up to the mark irrespective of the availability of ingredients and limited time.

A typical restaurant is staffed with a chef, chef’s cooking assistants, butcher, waiters, managcook-196932_640er, janitors, food tasters and a lot of machines which speed up the process of cooking. Cook’s best use of time is spent cooking the food, but does it mean the cook should not get a feel whether the food is cooked and is it as per the customization the waiter described?

Let us a take a scenario where the manager is able to hire more food tasters and shifts the burden of the quality to the food taster. Cooks will be able to create lots of dishes as per the recipe given by the chef without giving a second thought about the balance of ingredients, texture and the level of cooking required. The dish will ready to present in a finished state when it reaches the food taster, if any fault is found then the dish had to done from the beginning which will increase the workload of the cook further and reduce the output considerably as the reworks are expensive, eventually will make the customer wait more or increase dining table incidents.

What looked like a clever idea on paper backfires as cooking for fine dining is not something that could be made into a template and responsibilities could be in silos; it is a complex system with a strong feedback loop at every stage. The scene at programming is similar at many cases, developers are encouraged to write only the code and leave the testing to the QA as the perception is that the best use of a developer’s time is to make her code. Seasoned programmers know better that unit tests are also code, if you are not testing then you do not know what you program.

Cynefin_as_of_1st_June_2014Programming is an emergent practice, which matches the complex domain in the Cynefin framework by Dave Snowden. Each project will be unique and a pattern will emerge over time which will be efficient for the team if there is a strong feedback loop. Trying to separate out of responsibilities like testing to just one small group will push the team into a cycle of code, test and fix with long feedback loops, eventually causing delays. Quality has to be assured at every stage of application development, responsiveness determines who is competitive in a complex environment.

Image courtesy: http://pixabay.com & http://www.wikiwand.com/en/Dave_Snowden

by on

Building software is always a task of trying to hit a moving target. The complexity keeps growing on every parameter if not managed well. Projects which build softwares that have to talk to each other are often built by different teams under different managements, leaving less scope to find schedule and contract to match for smooth integration. Many times I have observed that there is so much of dependency on each other that the projects look like they are progressing so well until they hit a dead lock on integration.

rocking-horseIn my view such projects are like rocking horses, for a child it gives an illusion that s/he is in control of the horse and its movements but there is no real progress, it is just moving not progressing. The illusion of movement in a project is formed when developers implement the requirements which is neither validated nor integrated but just added to growing source code, followed by an all out big bang effort to integrate and push it to production. The result of rework and last mile dash leaves the teams burnt out and demotivated that there is hardly enough energy to move on to the next work.

Research say that we have two kinds of thinking which I encountered in the book ‘The Pragmatic Programmer’, it says that people who work with the brain (knowledge workers) need to make use of both focussed and diffused modes of thinking which is mentioned as L-mode and R-mode in the book. Procrastination is the key to R-mode as it props up the answers we are looking for, at a moment when we are not thinking about it. It has worked for me very well as I have observed that I get great ideas in shower, while driving, while having coffee staring outside the office window.

Sadly management is trained to look at people furiously typing at their computers for long hours as work and any thinking time saharais deemed as a luxury. This problem gets compounded when management in the guise of agile leaving out all the people aspects behind; which help in looking back, taking stock of situation and plan well but use it solely for micromanagement. People if lost will usually walk in circles, it is a proven fact that people lost in a desert in the night time or an overcast condition without the direction markers will walk in circles, more about it in this link from Nat Geo.

Directionless movement is just a movement for the sake of movement like a rocking horse, there is no real progress.

by on

Building software is not an engineering problem, it is a communication problem between engineers and business. Agile Manifesto‘s first and foremost point is about the individuals and interactions. It is imperative that the feedback loop should be as short as possible to reduce the cost of late rework. Each team in an organization would be unique in terms of composition, their communication and means of interaction will be fine tuned for that particular group. The teams should be guided through non negotiable philosophies rather than intricate set of policies, restrictions and tools.

Cliche – ‘Any code can be understood by machines, code should be written such a way that it should be readable by humans’

MatrixCode is read many times more than it is written, so it is everyone’s desire to keep the code base very neat to adhere to good coding standards. One way of ensuring this is to do a code review. With Git the collaboration got easier that you ask anyone to clone your repo, do some work and contribute back through a pull request. Pull request is the only way of contributing code to a project which is otherwise a closed read only repository. The owner reviews the pull requests and decides what goes into his/her repo. The feedback cycle in this manner is too slow but works well for social coding.

Cliche – ‘If you have a hammer then all your problems look like nails’

It is becoming increasingly difficult to gather the right requirements, translate them quickly into working software and that too in an efficient hammer-147840_640manner. It is necessary for us to be able to roll up information from the environment and translate that into the software. To help the evolution we should be able to keep the feedback loop as small as possible so that it is very easy to add the right functionalities at a good pace. I happened to read a nice writeup on the importance of rolling up information from the environment. Many people fail to visualize what their intent is in selecting a tool in the first place, pull requests work very well in controlling what goes into someone’s personal project. It will also be successful in team setups, but it comes with a cost. The cost is the speed of evolution, as it will take longer and longer to sync the commits when the codebase grows.

Cliche – ‘Give a carpenter a latest power drill instead of a hammer, he will use it as a hammer’

penguin-158551_1280In the SOA context it is a double whammy where there are many micro repos and pull requests are used to control the quality of the code. Choice of tools and technologies are always like rock, paper & scissors; what works in one context will not work in the other. Choose the right one considering the intent and moving targets in all dimensions in the system, change the approach if it does not fit in or the situation has changed.