Don't yell, "Ready, Fire, Aim!" or you miss every time. Stop and think first...
OK, I blatantly lied in the title. This post will contain absolutely no code. More important than the code that is used to create a product, is a clear and articulate vision of what the product or feature actually does. When I first started my career, most development was done via a process referred to as “waterfall”. In waterfall development, people could spend months or even a year to clearly define the exact behavior of what the product or feature should do. At the end of this definition process, a giant Business Requirements Document (BRD) would be produce that would contain literally hundreds of things like:
BRD-0-001 The solution shall have a mechanism whereby a user may enter a username and password and receive a token which shall be used to authenticate requests. The token shall remain valid for ten minutes from the last user request.
All of these requirements would then be packaged together into a document that would be roughly one hundred pages and everyone would say they reviewed it, except no one ever did. The reality is the typical BRD really should have been used to treat insomnia for patients who did not respond to strong drugs.
There were a few problems with this methodology. One, the process took a very long time. By the time the requirements were rigidly defined, the underlying reasons for the requirements very well might have changed. Secondly, the requirements were very technical in nature, but lost in the requirements were details about why a user would do something or what the actual interaction or experience was supposed to be like.
To counteract these problems and hopefully make better software, a group of really smart people got together and wrote the Agile Manifesto in February 2001. Now, when faced with a choice, if you were an executive at a software company, would you rather have your projects run agile or non-agile? Of course, everyone wants to be agile! There really is nothing wrong with agile, except most people have never read the Agile Manifesto, claim to be agile, and then cling dogmatically to certain aspects that really have nothing to do with making great software.
It reminds me a bit of a scene from one of my favorite movies, “The Life of Brian”. The protagonist somehow winds up preaching a basic message of kindness and compassion and his blind followers misinterpret, project, and misapply his every message as best captured by this two minute scene:
Neither the gourd nor the sandal have anything to do with Brian’s sermons, but his followers seem to lack that understanding. Likewise, no developer ever said, “That was a great use of time!” following a daily stand up, yet few companies would dare cancel the daily standup, lest someone accuse them of not being agile, because everyone wants to be agile. I, personally, have been involved in projects that had a daily standup that lasted a full hour and had fifty people tied up the entire time, because - you know, agile.
If anyone thinks I am overly cynical, I actually do think there are a lot of great tools in the agile toolkit and I would hate to see a complete return to waterfall. As I proceed to write and open source software here, I’m going to treat the project as if I were running my version of an agile development process. I will be throwing away the dogma and taking advantage of what I humbly consider to be the process’s strengths.
Within the Agile team are several roles including the Product Owner (or Product Manager), the Scrum Master (which is really the artist formerly known as the project manager), developers, and testers. Most problems start in the beginning, with the Product Owner. In theory, the Product Owner should have deep knowledge of the product and work to produce a roadmap. The team will then proceed to incrementally work towards implementing small bits of software on a regular basis that will help achieve this vision.
Small chunks of work are organized into sprints. Before a sprint starts, everyone gets together in the worst and most grueling process in the world, called sizing. Sizing is done in points, not hours, for reasons that escape me. Points, to be extra confusing, are usually assigned using a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) in order to slip the words Fibonacci sequence into a process that is way more art than science, thereby confusing executives into thinking that the people running the program are way smarter than they actually are, and to maintain an air of mystery and competence.
Theoretically, and this is strictly theoretical because I’ve never seen it done in practice, the Product Owner has a bunch of stories organized into a product backlog. Each story ought to represent a discrete interaction as told from the user’s experience. They usually follow the format:
As a…
I want to…
So that…
Upon reading the story, every team member should be able to know what the role of the user is, what it is they are trying to do, and why they are trying to do it. The story should contain verbiage that makes it verifiable. A story is considered verifiable if the developers and testers know intuitively what it is that needs to be done in order to complete the story.
Sometimes, stories are simply too big. That’s OK, but it makes it much harder to write discrete pieces of work off these stories. So, instead of assigning a huge story to a team, the huge story is referred to as an epic and then smaller stories are carved out of it until those stories become small enough, verifiable, and easily absorbed by the greater team. Epics are important to bundle together stories around a central feature or issue and help to keep things organized to make sure if stories are assigned to different team members, they collaborate and keep the design consistent.
Let’s begin, shall we? The product I am going to build here will be used by caregivers of Type I Diabetics. Type I Diabetes, as explained by my then seven year old Type I Diabetic, is a condition whereby, “If your blood sugar goes to high, you go in a coma. If your blood sugar goes to low, you go in a coma. There, you know everything about diabetes!”
Given that Type I Diabetes manifests itself usually in childhood, it used to be referred to as Juvenile Diabetes. While similar in treatment to Type II Diabetes, they are really different disorders. Type I is incurable and not related to diet or exercise. It is an autoimmune disorder where the body attacks its own pancreas, destroying the insulin producing beta cells, and no longer regulates the amount of glucose that is in the bloodstream at any given moment in time. If too much glucose is present in the bloodstream, it is referred to as a hyperglycemia. Slightly elevated levels will not do immediate damage, but over time can lead to gangrene, blindness, kidney failure, or a stroke. At extreme levels, it can induce a coma or even cause death.
The opposite end of the spectrum, when the blood sugar level is too low, is called hypoglycemia. If left untreated, this can immediately induce a coma or death. One hundred years ago, this disease was 100% fatal, with the average lifespan a mere year post diagnosis. Now, with the use of insulin therapy, diabetics can lead normal lives with the caveat that they must continually monitor and treat themselves.
Previously, the continual monitoring meant pricking the finger for a small amount of blood that can then be consumed by a glucometer which would quickly analyze and produce a number. Recently, huge breakthroughs have been made whereby a diabetic can wear a Continuous Glucose Monitor (CGM). With a CGM, a diabetic can check their number at any time without using a glucometer. Even better, other people can remotely see this number and take action based off the number. Remember, there are lots of parents who are doing their best to raise their children. With this disease, there is the added responsibility of managing the child’s glucose level so that they will live. Five year olds are simply incapable of this task. By putting a CGM on a child, it allows them to live a more normal life. Because my daughter has a CGM, I allow her to go to a friends house knowing that I can monitor her.
One of the common uses of a CGM is the alerting function. In order to not constantly pull out a phone or look on a watch to see the diabetic’s number, caregivers often only want to know when a certain event is taking place - if their diabetic’s number gets too high or too low. Right now, the dominant player in the CGM space is a company called Dexcom. The hardware is incredible, but the software… Well, the software sucks. That’s where my product comes into play.
Before Dexcom launched their Share product, a group of parents got together and built software that would pull information off of the Dexcom monitor, upload the data to a server, and allow parents to remotely monitor their children. With the hashtag #wearenotwaiting, this group dedicated countless hours to make a product that is freely available and improves the quality of life of diabetics and their caregivers. The original software used Android phones that were tethered to the Dexcom monitor via a USB cable. The phone ran custom software that would poll the monitor every five minutes and then transmit the data to a specified server.
Although the Nightscout foundation helped raise awareness of the Dexcom product and based their software on Dexcom hardware, the people at Dexcom were bizarrely not pleased:
In the video, the CEO of Dexcom calls this group of volunteers “rogues and cowboys”, accuses them of “hacking” the Dexcom port, calls the resulting software unvalidated and unverified, and insinuates that the entire program is putting patients lives at risk. Except he’s full of shit. As parents of diabetics, we have heard of the rare but real risk of the “dead in bed syndrome”. It would be absolutely impossible for most of us to sleep knowing that this is even a possibility. With the use of CGM technology, it is another tool for us to help care for our children. Whereas the CEO says that parents using Nightscout are putting their children at risk, I say that we might very well be saving their lives. Us caregivers absolutely need to be alarmed out of our sleep if a “hypo” (short for hypoglycemic incident) is happening. If we are alarmed, the treatment is simple. We give our children a glucose tab and some yogurt and then go back to bed. If not treated… Well, let’s not talk about that.
Dexcom is not the first company to be the target of a coordinated effort to change the way their product is used. In fact, most major innovations on the iPhone came from the jailbreak community. Apple, instead of insulting the community, learns from the community. Yes, they always patch the holes that are used to jailbreak the phones in the first place, but the jailbreak community lead to the App store, organization of folders on the UI, the notification system, and more. These features were tested by a dedicated few in the jailbreak community and Apple took the best and worked it into the core product (http://www.imore.com/team-pure-jailbreak-benefits).
Dexcom could learn a lot from this example. To date, Dexcom’s share product is limited to iOS devices, allows only five people to follow a diabetic, requires the downloading of a dedicated app, and relies solely on Apple’s push notifications for alerts.
The product developed over the coming weeks will leverage the code provided by the Share to Nightscout bridge found here:
Now on to the epic… As the caregiver of a diabetic, I want to have the ability to determine who will receive notifications of certain events. The notifications should be via standard text messages or phone calls so that I can quickly and easily set someone up on customized rules. For example, I may want to have a rule that applies Monday through Friday, excludes holidays, and only during the school year to send a text message to the school nurse if my child’s glucose gets too high or too low. The rule should contain information as to how often to repeat the action. During the day, I may want to receive a reminder text every fifteen minutes if the situation does not correct itself. In the evening, I may want to receive messages every five minutes in case I slept through the first event.
Rules should be highly customizable and very easy to add from either a PC or a mobile device. They may be temporary in nature, so that when a babysitter comes, she receives notifications of a low for the period she is watching the child, but will not see subsequent events after she is no longer the caregiver. The receiver of the event will not be required to install any software. The admin for the messaging service can add, delete, and modify rules whenever they see fit.
While these few paragraphs provide a reasonable enough explanation for what the service is and how it will be used, it would be near impossible to implement based off of this very high level description. The next step is to organize some stories that provide more details and establish themselves as verifiable and then, finally, start coding.
To accomplish the goal of the service, I will be breaking the requirements into three major components:
- A daemon that continually polls the Share service and passes along the latest data to the rules engine.
- A rules engine that determines which, if any, actions need to be applied
- A user interface to allow for additions, deletions, and changes to the rules
Typically, a series of spikes, or dedicated time to doing research and documenting the results would be done to assess which technologies or services should be used. For the sake of expediency and since it’s my product and my blog, I will be using the following:
- The daemon and rules engine will be written in NodeJS
- The service itself will be designed to be hosted on Digital Ocean, with the goal of running a server that is $5/ month
- The UI will utilize ReactJS and Bootstrap
- Messaging will be done via Twillio, a low cost service that allows standard text messages and phone calls to be sent via a ReST API
- Data will be stored on the server in MongoDB, an open source NOSQL database
Finally, one last caveat. In the real world, a Product Owner should ABSOLUTELY never start writing requirements until he or she has validated the requirements with actual customers or potential customers. Different tools exist to validate the requirements from reaching out to customers, surveys, focus groups, etc. I am breaking a fundamental rule here, one that I yell at Product Managers all the time for breaking - I am creating these requirements based on my opinion. However, since this is my time that is going into making the product, and I am going to be the one using this product, I feel OK with this decision. I hope that this product is used by other people and once released, I will consider feature requests as time permits. Up next is organizing stories into my first sprint and then some coding...
No comments:
Post a Comment