.png){kind=small}
Bugs. No, not the creepy crawlies that infest your crops. Software bugs; errors, flaws or faults in the design, development, or operation of computer software that cause it to produce an incorrect result or an unexpected behaviour. In crops, bugs can cause quality or performance issues, and it's the same in software. In addition, they can cause downtime and reduce the efficiency of your data collection or analysis.
In much the same way as growers, bugs are not the subject we choose when we’re catching up with our fellows down the pub. They are not our proudest moments, but like in growing a crop, they are a part of life. They happen to us all, in almost every facet of life, and to pretend they don’t happen in growing crops and software is burying our heads in the sand. What differentiates growers and software providers from their competitors is how they respond to them and the prevention measures they take for the future.
Speed of response
See blight starting in your potatoes and go on holiday? No. How quickly you respond to bugs in the field affects the success of any applied treatments. A quick response can nip it in the bud, a delayed response can lead to an outbreak or epidemic, which ultimately requires more inputs and resources to fix. Or you pay the penalty in yield or quality. In the same way, we want to fix bugs before they affect anyone else, although thankfully for software it is not likely that the bug will self propagate to become a larger problem!
Sometimes we have fixed 2 bugs whilst on the phone to customers in a ten minute phone call, other bugs can take longer to fix. For example, issues with uploading images that are to do with how the individual users' phone stores images, can be a nightmare for our engineering team to diagnose. We pride ourselves on our response times and aim to get you back up and running as soon as possible.
What you respond with
You wouldn't respond to an insect infestation with a fungicide. In the same way, our fix needs to change the relevant pieces of coding to dissolve the bug. We can only diagnose bugs by observing the symptoms (although we do have technology to help us do that). In the same way a hole in a leaf could be caused by a number of different bugs, there are normally several ways a bug in software could be caused. You inspect the leaf to find the culprit, we inspect the code to do the same. We can then decide what the fix should be: it could be correcting an error in the code, it could be redesigning a model to cope with new use cases, or it could be redesigning the look of a page to improve usability.
The other way we respond is to let you, the user, know as soon as we can that we are looking into the problem and we are doing everything we can to get it resolved (whilst also trying to maintain the delivery of new features).
Prevention
Think of this as your preventative sprays and cultural controls. Healthy crop rotations can prevent certain bugs establishing in your crops, in other cases a preventative spray can help prevent a disease taking hold. The infrastructure we use, and how we model data is carefully designed to cope with heavy usage and be reliable. We put a lot of thought into it. When bugs do occur, we sit down and talk about what we could have done and can do better. We have a range of processes, behaviours and tools that we can implement to prevent similar things happening in future, such as:
more automated testing
stricter manual testing processes
better system reporting
the use of different plugins/infrastructure or an improvement in coding practice.
Our workflow
Here at KisanHub, our focus is always on helping you do your job better and more efficiently. When bugs come in that prevent you from doing this, we take it very personally, which is why when bugs come in, we dedicate the resources necessary to fixing them. We test our own product internally, so we catch bugs too, but sometimes you, the user, are the first to notice them, in which case our Customer Success team are the first to receive your bug report. This is tested to see if we can confirm it as a bug (we call this reproducing a bug) or whether it is that the user is not using the system in the correct way (we call this user error)! Alternatively, it can be because the user does not have the correct permissions to do that task.
If it is a real bug, that issue will be brought through to the Product department and triaged, then prioritised against our other work. Bugs carry a high priority, but it can, for example, be difficult to justify immediately fixing a bug that is affecting one user in a small way before fixing a bug that is preventing many users logging in. This is where the product team has to apply their industry and tech knowledge to prioritise bugs against each other and new features.
It is also expensive for engineers to switch between tasks (imagine being really absorbed in reading a book and half way through someone makes you start reading a completely different book). Our engineers are normally busy building new features, so asking an engineer to stop what they are building and look into a bug (we call this a sprint interrupt) is reserved for the worst bugs. Fixing lower priority bugs is planned into our three-weekly work sprints, alongside other features.
At KisanHub, we have unrivalled knowledge in how agriculture, the agri-supply chain and software work together. This expertise helps us empathise with you the user and our response is appropriate to that. So when we are fixing bugs, please bear with us, we are doing our best to fix them and get the system running optimally for you!
About the Author
Has an agricultural background with a degree in Environmental Science. Prior to KisanHub, he was a crop research manager and agri-food consultant at ADAS. Jonny, Head of Product at KisanHub, leads on delivering the Product Roadmap and develops practical and cost-effective solutions for the industry.
Comentários