One line that I have heard quite frequently in ColoredCow is- In any project the actual development or coding part is only 20 percent.
I have also heard variations to this statement where the percentage has even gone down to one percent- Coding is just one percent.
Being a software developer you will realize this sooner or later that coding is not about writing few lines or statements in a computer to complete a task but it is about solving a problem and the sooner you realize, the better.
I had this realization couple of months after starting my professional journey but sharing this now, since I have seen and worked in a handful of projects and can tell with my own experience.
I will explain this with an example from a recent project that I worked on called Arogya World -mDiabetes program.
About the project
Arogya World wanted to run their Diabetes awareness program through Glific. It consists of a set of 58 messages about the various aspects of Diabetes, and 32 questions that checks the behaviours of the end-users. The messages will be sent over a period of 6 months.
It is to be run with a cohort of 1600 end users wherein 800 users(control group) will receive only the 58 messages in a fixed order while the other 800 users(experiment group) will receive questions and messages in an order decided by an AI engine. This program will run on WhatsApp and it will test how nudges can impact behaviors and help people in the prevention of Diabetes.
You can read more about the program here.
The four teams involved in the program were:
Looking at the problem statement it seemed quite simple. Send some users a few messages that joins the program on WhatsApp. Spoiler alert! It wasn’t simple.
Some key discussion points were:
We discussed and worked on all of the requirements which took us weeks and do you know how much we had to actually code for it? not even 20 percent.
I am not saying that the coding part was not crucial. The program could have never worked without that. But it was the least challenging part in the whole process once all the previous things were clear.
“Don’t code to finish a task. Code to solve a problem”
And the better clarity you have of the problem the better your code will be.