Up at 5AM: The 5AM Solutions Blog

For the past 6+ years, since I escaped was sent off lovingly with a diploma from college, I have been working on contracts that have all dealt with improving workflows and systems through technology. This has provided me with opportunity for many musings on the process of changing these workflows and how to make sure you can make a system that not only does what it’s supposed to, but does it better.

First and foremost, you’ve got to keep in mind the problem that has to be solved. Often you won’t be solving new problems right off the bat, but it will begin with translating a workflow from one process to another. In most cases this will mean you will be taking a paper process that has been in place for years (even decades) and replacing it with a digital process, though there are occasions where this might just be moving from an older clunky digital system to a new fancy state of the art system. Henry Ford is often quoted as saying, (which may not actually be true) "If I had asked people what they wanted, they would have said faster horses.” We can use this in how we think about transitioning from old workflows to new ones as well. Think about if Ford’s car wasn’t the Model T as we know it, but was a flying car instead. Users would still be able to travel much faster than they could on horse and could even take things (or more people) with them, but the result is so different that people who were used to horses wouldn’t know what to do with it. We need to be conscious of these same changes as we change workflows, as we want to innovate and build a more efficient version of their current workflow but we don’t want to overwhelm the users too much. We want to change how they work without too many surprises.

Why are we doing this project if not to improve? The worst feeling in the world is to know that you are wasting your time working on something that isn’t going to be used. So while you are working towards change, you need to keep in mind the major hassles that users go through with the current process. How can you make their lives easier and make the user WANT to use your new application over the way they’ve been doing it for years? Look at how they do things and how things could be better. If the user constantly has to be going to their computer or calling someone up to find the same information over and over again, think about how you can link that system into yours. Does the user have to go through the hassle of gathering up documents and mailing them off and hoping they get there in time (or at all)? How about figuring out a way for them to be able to digitally submit all of that to the recipient? What also needs to be kept in mind is that the system can’t have steps that prove to be a greater hassle as compared to how much easier it is to use as this might drive users away. You don’t want the user to feel like there is greater relative burden on them now that they are in a system that they don’t encounter on paper. The first iteration of any system is to entice and bring users into the fold of the application and to start convincing them that your system gives them more benefits vs. sticking with the old way, while not introducing new hassles.

Evolution occurs over time...

Although not biological by definition, applications are growing organisms in their own right. They change and evolve as time progresses absorbing new capabilities and losing some of now useless features that were moved over from the old processes / systems it was deemed to replace. This is an expectation that needs to be accepted from the very beginning, making sure that the initial scope is actually doable and the expected features match those of the current process. As the application is built and once it has been released, you will receive user feedback from those who actually will be using the application. During this time you find out even more about what direction the application will begin to grow as users provide feedback about what is good and what isn’t. This allows the application to adjust to its environment becoming stronger and better equipped to handle the tasks at hand.

Learn from the Phoenix...

The application you are working on now will die. It might not be soon and you might not have anything to do with it when it does, but you might wind up working on a different application to replace an existing application. In these circumstances we must remember the Phoenix in that from the ashes of the existing application a new one will be born. An application tends to die for a few different reasons:

1. It is no longer useful as the processes it was meant to cover no longer exist.

2. It is outdated, or the technology used in it is no longer relevant and it is more beneficial to rewrite from scratch than put a new coat of paint on the old one.

3. It has been replaced by something different.

In the second two situations the need still exists for the project and likely a lot of the business rules and knowledge about the application can be reused. The application might be completely different but the work and knowledge of everything can be used as a foundation to build that new application to replace the old. In the first situation, it’s hard to defeat irrelevancy so the application and its functionality won’t be replaced by anything. It is likely that the pieces of the old application could be re-purposed to other closely related areas. In any situation, keeping the application evolving with the needs and the technology of the times can maximize the duration that the application will hold its existence and the longer the application is useful the most worthwhile the application was to build in the first place. But in the end, don’t we all just want what we build to be useful?

-Adam Swift, 5AM Solutions

On a random, early Saturday morning, I was listening to a story featured on WAMU 88.5 (American University Radio) related to a recent advance reported in Nature (Dymond, J. S. et al. Nature 2011). Essentially, scientists are working on manipulating yeast to behave like a little factory for humans, producing fuels and specialty chemicals.

While the radio piece articulated at the consumer level the story of synthetic biology in about 30 seconds (which alone is cool for this layperson), highlighting the story of aspirin from Hippocrates’ initial suggestion that pain could be treated with willow bark to our ability to extract and then make the ingredients required. Jef Boeke at John Hopkins discussed some of the potential future uses for developing yeast optimized for specific purposes, such as production of biofuels, vaccines or drugs. Super cool. But so what?

Peter Enyeart, a Texas at Austin graduate student who reviewed the Nature paper, articulated something transcendent between the worlds of experimentation and discovery and software development--"Evolution remains our best option for designing code, which makes sense because that's how nature does it." While he was speaking to the "scramble technology" approach being used by the Boeke's lab--which creates a massive set of synthetic mutations which can be iteratively gone through to choose which ones work best for a given purpose--I'd propose that his other comment, "if you just try to intelligently design it - if it works at all, it probably won't work well" speaks right to the heart of quality software engineering.

We have learned in the vastly immature art of software engineering (as compared to the long practiced art of medicine), that in projects large or small, trying to elicit all the requirements, come up with a grand "intelligent" design, and then code and test it out probably won't work and surely won't work well - because "change" happens. "Needs" evolve. What is originally envisioned can change frequently during the development process for a multitude of reasons. I don't mean to suggest that performing comprehensive design exercises is futile. What I am inspired by, and continue to see in our results, is that getting at the basis for what software needs to accomplish, coming up with the best design possible, trying it out and doing so in short intervals that balance pressures of budget, time, and quality is the best way we know to deliver value. We represent that belief in our Glassbox Development Process - itself an evolving methodology, and it is comforting to know that in our target markets of health and life science, a similar belief is held.

-Brent Gendleman, 5AM Solutions

Photo Credit: Wikimedia Commons