by on

The biggest killer of developer time is meetings, it is a double whammy when it is run by people who do not know how to run it or how to finish it. So often a meeting eats up as much as the 25% of day without adding benefit to any of the attendees.

Image courtesy: Unsplash

Developers cannot spend time in 30 minute slots like non developers. It takes some time to get into the groove and let the mind feel the code as if it is the extension of the natural language. 3 hours of unbroken developer time is the golden rule for me, it does not matter if I am coding, writing something or just starting out of the window thinking about something. The biggest killer of my productivity is when people pull me out of my zone for status checks during the middle of the coding session.

Also too often the planned meetings are more of information gathering sessions for the highest placed person in the corporate ladder. Any agenda or plans are thrown out of the window when the first question comes from a leader. These meetings scheduled for about 30 minutes will get converted to rants, status checks, random questions, fears and more that drags on and on to go well into 90+ minutes.

The best way to run meetings is to

  • Set agenda & time window (Make sure attendees are prepared, if it is a status check it is best done at the start or the end of the day)
  • A facilitator who can keep time and moderate conversations if that goes away from the agenda
  • A parking lot to make sure to capture random thoughts that can easily derail a meeting

Any one I have spoken to, agrees to the above points, but fails to keep the meeting in check because it is mostly run by non developers who don’t mind those additional 30 or 60 minutes getting wasted; or they just keep quiet and stay on so that the seniors are not offended.

If you are a manager and have a development team, please give unbroken chunks of time to developers and learn to run precise status checks and meetings without draining the energy that can otherwise be put into solving problems.

p.s: Design discussions and dev huddles do not follow in the above category but they also need to be facilitated well by the tech lead.

by on

I often encounter people who deal only with false promises and a lot of people fall for it and yet take it easy as if it is normal.

Consider the following scenario.

There are two tailors who have setup shops side by side, during the festive season you go to store ‘A’ and request to tailor your suit in a week which is made of very expensive cloth. The tailor informs that due to the workload you will not be able to get the suit in a week but in about 10 days which is cutting too close to the day of the festival. In the past this tailor has delivered with good quality on promised dates but this is too close for you to take a call.

So you visit store ‘B’ where they also have a similar workload and backlog but promise to deliver to you within 5 days. They cost a little bit less and you are happy with the deal. 5 days later you turn up to collect your suit and you are in for a shock that the cloth has not yet been put in the queue for cutting and stitching. After losing your cool and talking to various people who play bad and good cop finally you are promised to get the delivery in another 5 days. 

5 days later, you have to be ready for the event in the evening so you drop by the tailor to collect your suit. You notice that the tailor is still stitching in a hurried manner and makes you wait for a few hours before giving it to you. On getting the suit you notice that it has a lot of glitches like double seams, improper creasing, misaligned pocket flaps etc. Only a few of them gets somehow masked and you end up late for the event in a spoiled suit. 

After the event you take it to Store ‘A’ and they tell you that they can fix it but it will take 10 more days and cost the same as a new suit as there are extensive repairs to save the expensive cloth. You reluctantly agree and at the end of 10 days you are surprised with on time delivery and the quality of the suit. You leave the place with a regret that you did not place the order with Store ‘A’. 

The scenario is similar at all levels even where the deals run into millions. The lure of a sweet price is so much that no one takes a look at the feasibility. Only in some cases the person making the deal is the same person getting the bad quality; but most of the cases the person making the deal gets good benefits for the sweet deals and the brunt is borne by someone else often many steps down the ladder. This leaves no room for direct observation and hence the feedback loop is never closed; the sweet deals and bitter quality output keeps going on rounds. 

One of my friends tweeted this recently

The bitterness of poor quality lingers much longer after the sweetness of a cheap deal has disappeared. 

Image courtesy: rawpixel on Unsplash

by on

I went to a restaurant for a buffet which was a bit crowded. I thought the service at some of the live counters will be slow but was surprised that the people at the counters were able to serve large number of customers in a short span of time, especially the salad counters.

fruit-2305192_640

I was curious so visited one of the salad counters to see how was it possible for them to serve that many people at once. It was shocking to see that in the name of speed the person at the counter was cutting fruits in such a way that about half of them got thrown away along with the skin and the seeds. If this person had maximized the fruit content then it would have taken 4-5 times the amount of time taken now on fast cuts.

It is very clear that the restaurant can afford to waste as much of half of the food because they still gained from servicing a lot more people than operating efficiently. It was optimized for time not cost.

This is something people don’t understand while choosing tradeoffs, people often choose both cost and speed as key without giving a second thought that both cannot go hand in hand. If the same set of people had to do things much quicker and at a larger scale there has to be expenditures in tools, training and also some change in processes where there will be huge wastes before optimization kicks in. This is what happens in software development teams, often there is a tight budget and an impending doom if something does not happen; leading teams to easy burnouts.

I did not include the word quality here as it is non negotiable, you can do things quick and cheap but with a poor quality of work like serving the fruits with seeds still intact or skins not peeled well. That is not work done, there is no work without quality; eventually it drives away customers.

Next time when you have a debate about speed consider moving the cost sliders.