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.

I was very surprised to note that in paper based offices there was nothing like erase a mistake or throw out the original, it was always an append over the previous ones. Be it land records, mark sheets or accounts. The end state was always calculated and consolidated than written, erased and rewritten.

This is very different in the software world, it is always wipe out old values and put the latest unless there are transactions which have to be recorded each time they happened. In real world everything happens by events yet in software we were always saving end states until recent times where having a common shared state became a huge problem when the systems started scaling and no one can have a claim to be the source of truth.

The problem with saving the projections is that we have to constantly erase and rewrite the projected truth, it was inconvenient in paper based ones so people stuck to append only. Since software makes erasing and writing easy, projections were always created during events instead of storing the events.

Why this becomes a problem? The problem is when there are lots of actors and they have to share the truth between them. Not everyone is interested in the entire projection and transporting that data also becomes painful. The solution is to keep events/transactions as it is and let each of the actors compute their projections when they want.

This is how we work in the real world, the events keep happening whether we observe or not, we try to make sense of it only when we are interested in it to do something with the events; else it just gets journaled somewhere unless someone wants to go through them. I am glad that more and more technology solutions are taking a cue from the biological and social world which had taken 100s and 1000s of years to evolve, instead of discarding them as old way of doing things.