In the last few years I see an overall increase in the busyness of people around in all professions. Everyone keeps telling about how busy they are; always behind tight deadlines and impossible to pursue goals yet they are able to somehow get things done. Managements usually set difficult to achieve deadlines, tightly control budgets, non negotiable scope of work and leave quality as the only leverage for the ground level people.

So people end up kludging together things to make ends meet. One of the dictionary meanings of ‘kludge’ is ‘a machine, system, or program that has been badly put together, especially a clumsy but temporarily effective solution to a particular fault or problem.’ I came across this term when reading this article. Kludge appears everywhere and it looks like a clever hack.

Sending that boolean variable named ‘donotTouchThisFlag’ through multiple layers of code and systems to bring up a new feature effectively cuts the time down by several hours that should have been spent in redesign. An engineer doing this for an aeroplane is beginning to get away from these blatant engineering blunders and instead gets praised for quick delivery of features and leave the headache to the technical support team to handle.

People have no other option than to succumb to this vicious cycle of too much pressure and low quality work. If they don’t fit in, they get kicked out. What is the leverage then? It is very hard to find leverage when people are bossing around in multiple layers, I kind of miss the unions of the yesteryears in many disciplines who demanded the right conditions, pay and working hours.

Good design and quality work can never come from pressure, if an output comes out of extremely forced timeline and budget then chances are high that failure follows suit. Sadly the manager gets rewarded for timely delivery and the engineer gets the stick for poor quality.

There was a time when learning css one of my friends told me a clever hack, use the ‘!important’ flag which will override all the other precedences. It was a boon for me when deadline was screaming down at me, for any css issue when I used the priority override and bam the bug was fixed. My joy was short lived, I was creating havoc in the css code and tough debug issues within a few days that I had to revert all the flags I had used and spend time fixing it properly. A big lesson learnt that stays with me, never abuse powerful tools.

I meet some managers who employ this trick in their day to day life. They take pride in answering questions like ‘When do you want this done?’ as ‘YESTERDAY’ and follow with a grin. The communication is limited to only deadlines and urgency, not the intent of what the task or the project is supposed to do. These people are high up in the power chain and use their coercive power to get things done.

What they don’t realise is the amount of things that pile up as priority items and how when everything is a priority, nothing is a priority. There is only so much that can be done with the amount of time and money in hand; with that judicial balance of outcome and effort gives a great returns compared to a series of high priority and urgent tasks that are done for the sake of being done.

I liked what I read at this link https://basecamp.com/books/calm

Great projects and products can get going with sane pace and working style. Don’t misuse the priority tag.

Too often I run into people who are way too concerned about velocity in software development and do a lot of math jugglery to make a plan look great to them and their bosses. The task breakdown in software development projects are empirical, it is not that scientific enough to drill it down to plain numbers and apply optimisation techniques on it or swap people like machines between tasks.

But many managers break down the tasks as if there is no communication or sync up required between people and if at all there is some communication, then people have to communicate over formal structures and contracts. If you trace these back to what it is, you get waterfall process with rigid contracts and control structures.

Teams are built with people; people get bored, fall sick, need vacations and skills vary between individuals. Planning needs to take into account task rotations, interactions between teams, contingencies, people skills, training & staffing issues, context and above all requirements that can change entirely or scope that increases a lot after deep understanding.

The result of managers treating work division in software like labour work results in unrealistic expectations which produces an output that is always on fire and setting self fulfilling prophecies that software teams don’t deliver hence need to be micromanaged.

Software development is a dynamic system with a ton of moving and evolving parts, in a dynamic system the whole is much more than the sum of the parts. A plant as a whole is much more than when seen as leaves, stems, branches, seeds, flowers, trunk and root.