When a code rot can be the difference between life and death.

By

 In 2018, a 9-year-old girl who had type-1 diabetes her entire life was being misled by her trusty medical applications on her smartphone. If these misleadings were not investigated by her father, Jeremy Vaughn,  she could have faced critical and fatal medical consequences.  Her medical check-up app with a continuous glucose monitor (CGM) failed. “Features were disappearing, critical alerts weren’t working, and notifications just stopped,” he stated. As a result, his nine-year-old daughter, who relied and lived her whole life on the CGM alerts, had to live on instincts. 


These apps were downloaded by Jeremy in 2016 for his daughter but by 2018, despite regular updates, these apps were now outdated and almost non-functioning. Jeremy checked the reviews on these apps and several patients had complained about malfunctioning apps and how they directly affected their health in a critical way. All this was due to the rotting code in these applications. They were regularly updated but only in variations of minor patch upgrades or bug fixing. As the environment around a code changes, the code needs to be revisited regularly especially in medical and automation fields. A code rot in your Tesla might prove equally fatal as a code rot in a medical check up application. 



 With rotting code, the earlier the problem is dealt with, the easier it is to overcome. The longer you leave it, the harder it is to fix. Code rot frequently occurs when minor changes to the code are made without fully shifting the structure of the code around the change. It leaves a lot of unused or new code that requires dependencies that aren't modified. The only viable solution to the problem of code rot is to be aware of the problem, and to make regular small fixes to avoid it getting out of hand.

Comments

Post a Comment

Popular posts from this blog

Make way for GPLV3

By
  GPLv3 is the new GPLv2 A little more than a decade ago, when GPLv3 was first introduced, a debate sparked between the fans of GPLv2 and GPLv3. Linus Torvald, the inventor of Linux, sided with GPLv2 and wrote several emails and threads on why his choice is justified. Richard Stallman, the founder of the Free Software Foundation, chose GPLv3 as his license of choice between the two. The main reason why Torvald didn't approve of the new and improved version of the GPL license was the overreaching aspects it contained. GPLv2 allowed hardware manufacturers to embed a signature key in their chips which would be needed to run free software on a machine. This specific signature key however limited the flexibility of the developer community since they couldn't update or modify the code and run it on the same machine. This limitation set forth by hardware manufacturers was likened by Linus and his followers. GPLv3 tackled this constraint by including an anti-tivoization clause in the l...
Read more

Privacy and Personal Data

By
Image
  Data privacy or information privacy is a branch of data security concerned with the proper handling of data – consent, notice, and regulatory obligations. More specifically, practical data privacy concerns often revolve around how the data is being shared with third parties and the legality of its collection and storage. The world runs on transactions. Buying and selling. What's more important than introducing your product in a new market to try and gather customers? Introducing your product in a new market with guaranteed customers. And how are these customers guaranteed? Big Data.  When you shop at Amazon, do you ever see a "customers like you also bought ...."? The item being introduced to you have a higher chance of being sold than to a random customer. It's very simple in how it works, but extremely effective. Look at it this way: A company "X" does not have any information on its customers and their interests. In contrast, a company "Y" has...
Read more