Let's Start Coding

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:

https://github.com/bewest/share2nightscout-bridge

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...

Throwing the Slant

On an unusually warm day for New Jersey in February of 2014, a rare matchup occurred in the Super Bowl featuring the number one seed from each of the two NFL Conferences. Further, the contest pitted the number one offense, the Denver Broncos - led by five time NFL MVP Peyton Manning, against the number one defense - the Seattle Seahawks, known to fans as “The Legion of Boom” for their hard hitting ways. In the two week period prior to the championship game; oddsmakers, sportswriters, and general pontificators were all over the board in trying to predict the eventual outcome.

Since real money was on the line, bet by real people, the “spread” that gamblers are given offer a relatively simple proxy to the expected quality of the game. The line eventually settled with the Denver Broncos being considered a one point favorite. In other words, the entire gambling community expected this to be a very close game. Except it wasn’t. It wasn’t at all. The Seahawks were the victors in a 43-8 blowout that absolutely no one predicted.

The following year, the Seahawks were under pressure to be the first team to repeat as Super Bowl champions in over a decade. There were highs and lows to the year, at one point, it looked like they would barely make the playoffs. After a midseason slump, the Hawks returned to their winning ways. Following an incredible, improbable, and borderline miraculous come from behind victory against an NFC rival, the Green Bay Packers, the Seahawks found themselves back in the Super Bowl. This time their opponent was the New England Patriots.

Again, the oddsmakers, sportswriters, and prognosticators were befuddled trying to figure out who would eventually win the game. The line again settled at one point, but this time, the Seahawks were the slight favorite.

Super Bowl 49 was everything that Super Bowl 48 was not. This was a hard fought, back and forth game that went down to the last minute. Even after leading his team from a ten point deficit to a three point lead, ageing superstar Tom Brady could not have been confident leaving the field with just over two minutes left to play. Brady, who had found so much success so early in his career - winning three Super Bowls, had seen the last two Super Bowls slip away from him. He had played admirably, but winning the game was now out of his hands and it was up to the New England defense to preserve the lead.

The Seahawks rose to the challenge, putting up big play after big play. Tom Brady must have felt sick to his stomach, watching from the sidelines, as Russell Wilson completed an incredible 31 yard pass to Jermaine Kearse. At first and goal from the six, Marshawn Lynch banged out a powerful five yard run. It was now second and goal with 31 seconds remaining. The Seahawks had one timeout and needed to only gain a single yard to become the first back to back Super Bowl champions since the Patriots themselves had done it so many years ago.

With arguably one of the greatest running backs of the decade, Marshawn “Beast Mode” Lynch, in the Seahawks backfield; the common wisdom was that the Hawks would again attempt to rush the ball into the end zone. Bizarrely, coming out of a timeout with the game on the line, Quarterback Russell Wilson lined up in the shotgun formation, indicating a pass play was coming. The ball was snapped and Wilson threw it hard. I’m sure as the ball left his hand, he could taste the champagne that would soon be pouring as he hoisted the MVP trophy. In just his third year as a pro, Wilson would have already won two Super Bowl championships and would now be considered the best young quarterback in the league.

But… That’s now what happened. Instead, unheralded, undrafted rookie Cornerback Malcolm Butler jumped the route. Just as the ball was reaching the intended target, Ricardo Lockette’s hands; Butler snatched the ball away and got a yard or two before being tackled. Instead of scoring a touchdown, the Seahawks completely blew it and turned the ball over.

Immediately, there was outrage in the play calling. Every armchair quarterback and every wannabe offensive coordinator came to the same immediate conclusion, the ball should have gone to Lynch.

While I can sympathize with the outrage, the reality is this knee jerk reaction was an oversimplification of the problem. Lynch, known for his powerful, smashing, and relentless drives; almost certainly would have got the ball into the end zone given three chances to gain a measly yard. However, there are many more factors that need to be considered here.

First, what most non-fans do not appreciate about football is the importance of deception. The Patriots obviously knew the Seahawks had a great runner in Lynch. Their defensive scheme is obviously going to focus on stopping the run. Since they would be preoccupied with stopping the run, it might make sense to go for the pass. Secondly, and more importantly, there is the clock management aspect. At this point in the game, the Hawks were down to their last time out. On a running play, the clock continues to wind even after the play is over. However, after an incomplete pass, the clock stops. The Seahawks simply did not have enough time and timeouts to be able to run three consecutive running plays. They more or less had to throw a pass in there somewhere. Second down coming out of a timeout was as good a time as any to go for the pass.

Knowing that a pass had to be a part of the plan due to the time and timeout situation, the eventual play that was called was only slightly less horrible. Had the pass been successful, it would have been a high risk, high reward situation. There was a much better play that should have been called…

Wilson should have never been in the shotgun. Instead, he should have lined up under the center with Lynch to his right. This simple change would have forced the New England defense to focus on stopping Lynch. Granted, Lynch would have been a decoy, but the threat of his running prowess would have been simply too great to ignore. After the ball was hiked, Wilson should have faked to Lynch and Lynch should have proceeded to smash through the line sans the ball. Wilson, meanwhile, should have rolled to his left and looked for his Tight End, Luke Willson, in the corner. In this situation, Wilson (the quarterback, yes, it’s confusing when the player’s names are Wilson and Willson) - an improvisational master, would have had some choices. If Luke were open, he could have thrown it. If he were covered, Russell - an excellent runner in his own right, could have rushed for the yard himself. But… In the worst case scenario, if his intended target were covered and Russell was about to be sacked for a loss, Wilson could have easily hucked the ball well over his tight end’s head resulting in an incomplete pass, stopping the clock, and not losing any precious yardage. This play, probably has an equal or greater probability of succeeding, with much lower risk since it was unlikely to result in a turnover. It was low risk, high reward.

Sadly, the Seahawks threw the slant play and the Patriots snatched victory from the jaws of defeat. Although the aforementioned slant play was high risk, high reward; I like to refer to doing something that is high risk, low reward as “throwing the slant”.

Why on earth would someone ever seek to do something that is high risk, low reward? Great question! The short answer is, I honestly don’t know. Yet in software, I see it happen all the time. In fact, I created this two by two matrix in an attempt to get people to think a little bit about what it is they are asking for before they commit to it.

Part of the problem with software is that decisions are made by people who have no idea how software works. Another issue is that asking your average developer to explain why something is a bad idea results in a condescending, jargon filled lecture. There really is plenty of blame to go around. However, consider this… Software is kind of like a living, breathing organism. Small changes in one section of code can have drastic and unintended consequences. Code is usually so fragile that before anything is released, it is considered standard to do “regression testing”. Introducing bugs while trying to add a feature or fix another bug is so normal, that regression testing is simply a standard practice.

So when a product manager or executive decides to put a feature into a product that a customer never asked for, that is not backed by research, that will not be part of a marketing press release, is difficult to define, will not be touted by sales, and offers no value, while simultaneously directly messes with core functionality; that my friends, is what I like to refer to as “throwing the slant”. In the Super Bowl analogy, it would be like calling the “fumblerooski”, to end the game, except that has a small chance of actually working. No, it would be like calling the fumblerooski with the intention to run the ball backwards for no apparent reason.

I had taken a break from blogging for quite a while, and this is my first post. I plan to write about working in technology, living in Austin, and occasionally add in some references to the Seahawks and old school hip-hop. My intention is to help demystify tech, amuse, and educate. I hope that all walks of life can get something out of this and I will eventually start an open source coding project here.