The trouble with gig economy

I grew up in a social setting such that people once they earn a bad name, it was very difficult for them to recover and be back in full swing in the society. They have to rebuild their reputation either in a new place or the same place. Why did people try to associate themselves to a society?; because living together was easy and people helped each other a lot. If one falls sick, there were people who helped the family of the sick member to help them get back upto speed.

The labour market also did the same, governments across the globe came up with a lot of guidelines and laws to employ people such a way that there was social security in the form of sick time, paid leaves, bonuses, retirement funds, insurance and gratuities. We were able to advance as a society very well with these elaborate social structures, though someone can earn a lot of money doing small gigs many people avoided for the predictable life of an established company.

The lure of quick money is always there, especially when people are young the cash in hand always triumphs the long term survivability. People don’t see far ahead and not many are aware of saving for the rainy days when they are strong, healthy and ignorant. This makes a lot of people take up gigs to survive, a gig means – ‘a job, especially one that is temporary or that has an uncertain future’. Gigs offer a lot of money in hand for a given skill and experience to compensate for the uncertainty in the future.

The money component alone lures a lot of people into the gig economy where people with less or no skills can immediately get going and even get paid within a day of commencing work. The trouble with gig economy is

  1. There is no social net in it, sort of a medieval system where the strongest and fittest survive. If people fall sick or meet with an accident they lose all the savings, they earn no money during sick time and end up with a perpetual high cost debt.
  2. You can get away doing bad work or behaviour, and if things go bad you can leave a system and join something else fresh. If you did bad job in a food delivery system, you can leave and make money driving cars for sometime. Though the same is possible in full time employment, the scale at which this can happen is big in the gig economy and you can change identities easily or mask your past performance easily

It is hard to address point number 1, the gig economy is new and it is giving jobs to a lot of people and many of them get a lot of money which they think is disposable and end up spending it.

The second point is bad from a consumer point of view, if there is no repeat business from a customer there is no incentive to give good product or service. Uber does it through its rating system, but what if that person decides to create a new profile altogether after a messed up profile or switch gigs to something else.

In the short run it seems a lot of people will have new jobs and people in college can do part time work for delivery services, but in the long run it will tune people to settle for a life where they think that they can earn a lot than full time employment but companies will do all sorts of tactics like ‘bait and switch’ which has happened to cab drivers in India and keep them hooked on to the system even when it turns damaging for them.

There will be a point in time that governments have to intervene to make sure exploitation of its citizens don’t take place else our society will slowly regress into a medieval feudal system.

Jevons Paradox and Muntzing

Phone calls used to be so expensive while I was growing up and the cost increased exponentially as the distances increased. Often I had to plan what to talk to people when making a call to keep it short; as my entire pocket money for the month can be used up if I spoke to my parents for 30 minutes during peak hours. Communication was expensive so that people planned carefully on how to talk, when to talk and how much to talk. Some people even chose to be contactable only in person and mails by avoiding a telephone line to save big on telephone costs.

What happens when something that was expensive becomes cheap, do we spend that savings elsewhere? This is where Jevons Paradox occurs. When communication became cheaper we stared overdoing it. What used to be a routine 3 minute call to a friend once in a while is now well over 30 minutes. We started paying more by time spent rather than money spent. It is a systems problem, the inefficiency just moves to another place.

This is applicable for anything, food was expensive and refrigerating food was even more expensive so we had invented a lot of ways to carefully store, cook right amounts, recycle leftovers into new dishes and also find ways to preserve through fermentation, pickling etc. My grandmother almost never generated trash or food waste to be dumped, all the edible portions were eaten and organic waste like peels went to plants which again gave back food. We are talking about this cycle as a new way of simple life and as if no one did this before.

This is an important factor in web development in particular and software development overall. Developers are given a lot more freehand to use resources at will to deliver the experience for the user. This has resulted in loading a ~500 KB homepage of which most of the code that is downloaded and processed is not directly useful or seen by the user (A good portion would be to track what a user is doing!). In a constrained environment, elegant solutions appear; in an abundant environment everything is bloated and there is no judicious use. A single webpage can potentially crash a browser or slow down the entire system.

How can this be solved? In many other industries the problem of plenty is not there for users, there are always constraints to work with to get efficient and elegant solutions. We need something like ‘Muntzing‘ for software industry; instead of needlessly hammering through generic all in all bloated solutions we can cut out the fat and concentrate only on core work.

 

As a company we decided to write only….

You have a business which needs apps running on iOS and android; which one is easy, building native apps or hybrid ones?

If you are the one who right away answers either native or hybrid without asking what are the considerations for the apps then you are setup for failure or great hardship. There is no blanket right approach to build apps that look similar and works similarly across the ecosystems.

smartphones-2182838_640Building rich native apps require depth in understanding of the capabilities of the  platform and designing a common experience for the users even though the capabilities of the underlying system might be different. Two separate teams, two different development pace add to the complexity.

On the other hand, building hybrid apps require a great breadth in mobile development. This means the team should have developers who understand iOS and android systems, knowledge of javascript, some experience in trouble shooting applications in iOS and android (may even require java, kotlin or swift exposure for some native code). It is a tall ask, requires a fair deal of experience and knowledge for everyone in the team.

Choose wisely, a blanket approach of one over the other for everything we do is not right and often leads into difficulties. If you say ‘As a company we decided to only hybrid apps’ then you don’t either understand the complexities or have not given enough thought on how to implement.

 

Mastering XP

There are lots of certified masters and trainers programmes available for various Agile methodologies but it is extremely hard to find one for Extreme Programming (XP). You can get certified in any methodology in 3 days and claim to be a practitioner but claiming to be a good XP developer is extremely hard.

It takes a few years of dedicated practice in XP to get some mastery in XP be recognised as one by peers. It does not come with just knowing how to write stories, estimate and sequence them. The most distinguished feature of XP is its emphasis on developers and technical aspects of software development.

Most of the people I encounter have modified waterfall into mini waterfalls following super rigid plans but tracking on a weekly basis in the name of agile development without giving much thought to the technical aspects. This will not help in realising many of the goals that we set out to achieve. Also to improve the speed, work is usually allotted in silos thereby increasing dependency on people and reducing collaboration.

Try answering Yes or No to the following questions

  • Do you do pair programming (May not be followed for simple straight forward tasks)?
  • Can any developer in the team call for a huddle when stuck or when there is a need for a design discussion?
  • Do you follow Test drive development (TDD)?
  • Is your team’s CI sacred, no one breaks the build or if broken it comes back green soon?
  • Do you do frequent commits/merges (short lived branches) to the master or do Trunk based development?
  • Can anyone in the team question the quality of code?
  • Does the team get together often to do mob code reviews or do some learning sessions on best practices?
  • Is it easy for you to roll off or onboard developers at least once a quarter?
  • Is there automation at all levels that people do not spend any time on recurring tasks?
  • Does your team seems to be productive enough if they work only for 5 days a week?
  • Is the team able to interact and negotiate on the stories with the Product owner during development?

The list above is not exhaustive but if there are questions that you have answered ‘No’ then you are not on the path to mastering XP.

Do you write tests first in TDD?

I am quite surprised how some technical terms easily lose their meaning over time. TDD (Test driven development) is one of them. I repeatedly meet people who do TDD at their work and when I say I also do TDD at work the next question most of the times I get asked is “Do you write tests first”? Stumped! TDD is always about write a test first and then write its code, test code is not a different citizen from production code while under development.

A few years ago if I had asked an interview candidate “Do you write your unit tests before writing your code if you are following TDD?” the chances are high that the candidate gets offended but now I am given a reply “I tried, but it is hard to do it; so we write tests after the coding is done to keep the coverage at 80”. So TDD has evolved to have a meaning of having 80%(or any other easy number) line coverage than a way of making sure to get a good low level design and have enough safety nets in place.

You are not following TDD if

  1. Not writing tests first
  2. Repeat point number 1

 

Working software vs points

I often come across people at management positions who clearly want to manage by tracking only numbers but fail to understand why were those metrics in place. We were part of a six team project, we were asked to go through our requirements and give an estimate including any proof of concepts and study that we had to do. The estimates were in points in fibonacci but were tightly mapped to number of days. When we questioned about why points to days the answer was to keep the yardstick of measurement same across all the teams in the org. It was setup for failure, but our team had to move on with the development so we went ahead agreeing to the terms.

After the first sprint our team had missed meeting the estimate while all the other teams had achieved it, we were met by one of the senior managers who gave a stern warning to the team that points are non negotiable and wants us not to fail again. When the time for demo came by, we were the only team that did a demo of the working software and product owners were able to immediately grasp what was going on and gave feedback on it. All the other teams had met their estimated points but they did things like ‘Study ABC tool’, ‘Setup CI machine’, ‘Setup Dev machine’ and so on.

Our team did all those and also demoed a working software, the other teams have bloated the estimate and bought time. This went on for some iterations, all the other teams were able to meet the estimates but other than our team all the other teams were not able to showcase their working software. The management did not care much about working software, their success was measured by meeting the points; it was the product owners who suffered the most as it took an extremely long time for them to get something working.

When you choose to measure something people will optimise for the metrics. Velocity and points are a way to help plan and size the software so that people can be allocated and releases can be planned, when it turned out to be a yardstick then there is only movement but no progress. People will eventually game the system and it becomes a toxic cycle.

Please prioritise working software over points

How to kill ideas

During our college days (2001) when Bluetooth was in its early stages the Bluetooth SIG (Special interest group) tied up with IEEE and announced a Bluetooth based theme for CSIDC (Computer science international design competition) with good perks like Bluetooth adapters, Windows XP and Visual studio licenses for participants and good prizes. One of our friends read about this and three of us put up a proposal with our ideas and we got through the initial round. We had a lot of ideas with us to implement a prototype, it is at this point a software company which was run by one of the alumni came over to help us in planning.

Our initial plan was to implement quickly and try it out on the users for feedback. hurry-up-2785528_640
This was for a generic identification device that can be configured to use for payments, tolls for cars, parking etc. The idea was that Bluetooth devices can hold a lot of data and gives the users the flexibility to create as many profiles as they want.

checklist-1643784_640One of the seniors in the company invited us to their place, in our first meeting itself we were stumped when we saw the mountain from which the waterfall process flowed. We were slapped with a software requirements specification document template which would have taken a few weeks to fill for the amount of ideas we had. It also had various parameters to rate the requirements like return on investment etc. I could never forget the feeling that we had on that day, we dropped our idea altogether and went on to find something which had requirements perfectly documented.

By the time we finished the first cut of the project and submitted we were only half emotiguy-1654859_640happy that we did finish something. We ended up converting EEG wirelessly and transmit through Bluetooth which was not a novel idea at all. The Waterfall process killed the idea, the fire and above all nothing useful came out of a defined process. Someone else who had submitted a similar generic id device entered the top 10 and ended up winning something. Some events leave a lasting impression on your life, this one was so strong that I had never accepted to work in waterfall development ever even though that was the only one very active around the time I graduated.

Any process followed for the sake of following it will surely kill a lot of things