Life Science Project

By Rein Ytterberg

Introduction

This is a summary of my contributions to a Life Science project I was responsible for, as CTO, between 2012 and 2014. I hope this text can give a good insight in what kind of experiences and skills I have, should they be of interest for anyone needing my services for similar jobs.

The story is intentionally a bit restrictive. I have no intentions to give away company secrets here. So the project description is very short, and not much of the technologies¹ we've used are presented except in the footnotes, to keep the text short. I don't think this poses a problem though. The situations and solutions I describe here may be found in many other projects, Life Science related or not.

Short Product Description

The intention of this product was (and still is, I guess, when you read this text), to collect health status from a very large group of patients. Most of those patients suffer from diabetes or heart problems², typically arising from a unhealthy life style. As the cost for treating these types of patients accelerates heavily in the western world, something has to be done to lower the pressure on the health care institutions and staff.

By constantly collecting patients' health status via smart phones, we wanted to be able to present it to our other types of users, the medical staff. In order to do so, there should be an algorithm³ which weighted the input parameters against each other, and then between the patients to finally present an ordered list sorted by importance. The patient in most urgent need to get treatment landed on top of the list. Once treated or examined, it would be possible to follow up the treatment or adjust the parameters to meet the patient's personal needs and conditions.

To save time for the medical staff, the smart phone application was also able to remind patients automatically of casual things such as maintaining their recommended diets and physical activities.

So there were two user interfaces. One to the patients, who reached the system via their smart phones. Another to the medical staff, using a web interface on an ordinary PC at the clinic.

Initial Status

The reason why they needed a CTO at this company at all, was to finish off the application and make it ready for the market. When I started in August 2012. The development had been going on for a couple of years, but there were still a lot of loose ends and problems to be addressed, solved and implemented. Some of those problems were just technical, some were architectural related, some were organizational and others concerned which tools and methods to use.

The time pressure was high, because the company expected to be able to release the product to the market "any time". Most problems were finally solved, and the product hit the marked in the end. The rest of this story explains what I had to do to bring it there.

I wasn't the only team member of course. We had some employees and some consultants also. My main responsibility was to steer the project in the right direction, although I sometimes had to do some hands on programming.

Actions Taken

Below, I only list results that origin from my own initiatives. Some of the listed solutions were implemented by myself partly or fully, while some others were just requested by me but implemented by others.

I requested the requirement specification to be reviewed and heavily rewritten, to get rid of contradictions, obsolete requirements, confusing statements and duplicates. I asked DoD⁴ to be added wherever possible and relevant.
Arch Linux was initially used. I decided we should switch to Ubuntu Linux instead⁵.
I requested a GUI makeover, to make the user's flow logical and practical.
I designed an on-line help feature.
I desided we should use GIMP⁶ to draw graphics, for example, icons.
I suggested a feedback⁷ functionality to be added, to allow users to give comments, suggestions or complaints any time they wanted, about anything in the application, allowing us to constantly improve it.
I designed a simulator⁸ that could generate test data. With this we can generate very varied, realistic and huge amount of test data, covering large time periods. This can be used both for testing and for user education. For new users, this simulator creates sandboxes which the users can fiddle with during their training period without risking any real data.
I designed, and actually developed (in PHP) the central algorithm for evaluation of patients' conditions.
I put much work in source code refactoring, and split the source code into logical modules. Much of the source code had to be rewritten from scratch. Partly just to make it work, and partly to make it possible to maintain and extend it in the future.
I wrote technical documentation, for source code, modules, tests, simulation, tools, maintenance, GUI, security, configuration and database.
I defined naming conventions, to avoid further confusion.
I re-factored the database.
I defined test strategies, and implemented automated testing wherever possible.
I moved all locale specific information from source code to separate modules, making it possible to translate the application to any language. Encoding is now completely changed from ISO-8859-1 to UTF-8 to allow translation to, for example, Chinese.
I designed logging facilities. Logs can now be read both by humans and by scripts, typically useful to the automated tests we've implemented.
Earlier hard coded configuration parameters were moved to separate configuration files, implemented in XML format.
I decided a style guide had to be used, to improve source code readability and make it easier for consultants and new employees to get insight to the code quicker.
Continuous upgrades are now possible, since I defined distinct processes, telling exactly how to perform upgrades. Much of the work is supported by scripts which perform and verify the upgrade. Upgrades are also announced to the end user via their smart phones or PC:s.
I demanded that all development documentation, including technical correspondence, requirement specifications and documentation, should be written in English instead of Swedish. This way, we would be able to outsource some development work to any country of choice. I also went to China to evaluate software developers, and we picked one of them to help us.
I implemented Scrum as project method, and gave internal tuition in how to practice it.
I decided we should use Atlassian Jira with Confluence as project management tool. We no longer have to rely on Excel document printouts in paper folders. We can now easily search and find information quickly!
I wrote a backup⁹ system for our development and technical documentation, using bash.
I contributed to an administrative interface which we needed to register our users, and print out their user contracts.
I requested tests to be made, to verify that the application really worked correctly with intended browsers and operating systems.
I implemented CSS3 and HTML5, and separation between source code and display layout. To this, jQuery Mobile has been added.
A common platform was developed on my initiative. It serves as the base for both the patient and medical interfaces. This reduces the need for test and code complexity drastically.

Footnotes

1. Some key technologies used were: Mercurial, jQuery Mobile, Twig, Ubuntu Linux, mySQL, JavaScript, Ajax, JSON, LaTeX, Bash, GIMP, CSS3, HTML5.

2. The initial system design was actually designed only for diabetes and heart patients. Since we had to re-factor the source code anyway, I suggested we could redesign the solution to make it more general without losing much time. So in the new design, health parameters are moved from source code to database, allowing us to add support for any health conditions in any combinations in a streamlined and normalized manner without any, or very little source code updates. This not just makes the application easier to extend and adapt to new environments and requirements, it also makes it easier to test and maintain.

3. This central algorithm was both very tricky and interesting. For example, questions like the following had to be considered: Which of those patients is most urgent: The one who gained 5 kg body weight, the one who just smoked two packets of cigarettes, or the one who hasn't worked out for three weeks and failed to take medicine X?. We also had to consider parameter changes over time. For example, a 170 kg heavy over-weight patient couldn't be told to drop to 90 kg directly. It had to go in steps. First maybe try to reach 150 kg and when that's achieved, change recommendation to 130 kg and so on.

4. I noticed that the planning meetings were often delayed due to misunderstandings or vague definitions of terms, so much time was spent on clarifying statements. Sometimes when developers were asked whether a task was finished or not, they couldn't produce a straigh answer because the requirement wasn't clearly stated. For example, it might not say whether Done just meant writing the code, or also test it. By adding DoD comments, things became much clearer and the daily scrum meetings could be shortened down to a minimum.

5. I have nothing against Arch Linux. But the reason for switching to Ubuntu is that it's more commonly used and known. I expected the company to grow, and more consultants to participate. By using Ubuntu, I estimated the start-up time for new developers to become shorter, and therefore, cheaper.

6. GIMP is a very good graphics tool, available on both Linux and Windows. I suggested it because then we'd have a common tool, as not all designers are using Linux. One mistake, where I'm to blame, is that the graphics were not vector based. A lesson to learn!

7. The feedback function saved users' comments together with the exact state of the application, and the data the user saw on the screen, so we could get a clear view of the context.

8. This simulator (which I gave the name Overdoze) is truly powerful. It has a simple command line interface to allow it to be easily called from other applications or graphical interface if needed. Among many things it is capable of, one was to populate the sandboxes with realistic data. So for example, it could be told to generate random names of patients and medical staff, or simulate medical status for a patient who gains weight over a period of several years.

9. The backup system became very convenient. The staff just plugged in their USB sticks to the port of a Linux computer, to load an updated archive. When the coping was over, the LED went out. Loss of the USB stick posed no problem, since everything was encrypted. There were also redundant archives. All backups were logged, so searching lost data and restoring it was quick and smooth.