Category Archives: software

The Infinite Software Release

Software Versions

Software is living and breathing, it is something that is continually changing with “the times”, to be successful over time you must continually be iterating and updating software, working to create the best experience for your end user. Software shouldn’t be stagnant.

Many vendors in the software industry are fighting with “The Innovator’s Dilemma“, where the company has not moved to building software in fast iterative cycles. The best way to create a nimble release cycle culture in your company is to have your software created and maintained in the cloud. For vendors pre-cloud movement, it is hard for them to move to a cloud software and to Software as a Service (SaaS) models when customers are paying for older software that is working right now for them. What will justify the moved to the cloud when the customer paid large sums of money for software that is working for them. Overtime, non-cloud base software will become stagnant, it is a struggle to keep all of your users up to date.

The risk of doing large software releases in the worst case scenario; when a large software update is released, users reject it and don’t use the software at all. There is also the risk that a large software update takes to long and the software is delayed to a point where the application is “stale” altogether or never released.

The Infinite Software Release

Have you ever heard of the “infinite release cycle”? The goal is to release often allowing continuous small daily, weekly or monthly incremental changes to software. Doing large/major version releases of software every year slows down developers from moving fast and getting input. A large software release benefit’s marketing the product, the product queues up for launch and gives the marketing team something big to announce, but doing so slows down getting the product out to market for real users to take advantage of getting feedback.

For example, the drchrono iPad and Web EHR is a continual work in progress, starting January 2009 and we have been on an “infinite release cycle”, pushing code to quickly, not releasing yearly or monthly but daily or close to daily. Within a given year, we have released at least 100 to 400+ versions of drchrono, that is how we are making the drchrono platform better and better at a rapid pace.
Look at the graph below at how infinite release cycles can change the customer experience and feedback loop. The green line represents a company that is on a yearly release cycle, great for marketing and launching a product right out of the gate will tons of features, but this is sometimes bad. Customers don’t have a chance to help you refine and give input the software. The blue line represents the quarterly release cycle, it is a better then yearly releases, allowing customers a chance to give feedback and learn about software in increments. With an infinite release cycle, customers can learn the product as it comes out and as enhancements come out, the learning curve is less drastic. Fast release cycles provide quick feedback loops to be able to make changes fast for refinement. Do you think it would be easy to do this if you are building for a year in an insular environment, then realizing a customer wants a major change? It is much harder to make a major refinement if a years worth of work is complex to change, which happens often.

Software Reversibility

Version 0 of drchrono

Version “day 1”, year 2009. drchrono iPad EHR.

In a new world of cloud-based apps and services, rolling out software in the past was episodic. Now things are moving to an almost continuous release cycle, happening fast. In today’s environment aren’t products “done” like they used to be, they can’t be. Do you recall the days of software on DVD and CD? You can’t just ship a DVD with software on it and call it a day anymore. The focus has shifted to pushing code and having the capacity for reversibility. You need to build software in real-time so you can iterate fast but also build fail-safes in place so if there is an issue, the software can be fixed it before users notice it. Reversibility is very important if you’re rolling new software out that is broken. It must be tested, one great company that does testing is Rain Forest, they have an on demand Uber-like service for quality assurance (QA) testing. As part of the deployment cycle, you need to test and talk to customers, showing them the new software, react to feedback and iterate.

Move Fast and Release Often

Track Metrics

A critical metric to track is how long did a cycle take and what can you do to make the next cycle faster?

Be sure to track after a developer writes code and committed to run the unit test and then how fast the code gets into production. If you can get the code out into production in 15 minutes from a change in code base out to users allows faster iteration and feedback.

  • After developer code is written and committed track these
    • Time after code was written, track how long until a unit test is run
    • Time after code was written, how fast the code gets into production

If you don’t track that metric, release cycles will generally get slower and slower.

Many startups start moving fast and naturally slow down on release cycles, to bi-weekly, weekly, then semi-monthly, then monthly. It can get worse from there.

A great talk from Startup School 2017 from Adam D’Angelo about this. Watch from 43 minutes into the talk.

 

Will Open EMR Survive?

When we started drchrono, we contemplated using open source software to build the company.

We thought about running instances of Open EMR for medical practice clients. The idea was great in concept, we would become the “Red Hat” like company to the EMR world. There were and still are other companies doing this and it looked like a viable option at the time.

Showing our first paying users Open EMR to see if it would fit their needs, the physicians looked at the software in a skeptical way saying it was missing critical components.

We reviewed everything Open EMR over and over, it has scheduling and it’s cloud based. Sounds good right? Well there is a lot that is missing. It doesn’t really cut it. To me it almost felt like a valiant effort to a failed operating system Kernel.

I thought about it and asked myself, why isn’t Open EMR up to par with where it should be? The passion wasn’t persistent over time with the people working on it. The love that was needed to build and maintain something of that magnitude wasn’t there, it looks like the developers gave up.
Yes it is there and yes it “works”, but it is more of a starting point. It needed and needs massive amounts of work.

Take a look at how old Open EMR feels –
OpenEMR-Calendar

OpenEMR-Demographics

So we looked for other solutions and there simply wasn’t a good open source EMR with a good vibrant developer and support community around it. We thought about it, we could invest our time submitting updates to Open EMR, that was an option, but we didn’t like the technology and the lack of love that was put into the project. It felt like we would be doing the heavy lifting if we invested into the project.

It was at this point we realized we needed to build our own EHR from scratch, from the ground up, it was a long term endeavor, but we committed to building the best EHR in the world. Year after year, improvement after improvement, we leap leapfrogged anything Open EMR could do. There is still a lot to do. ( I just want to thank the drchrono team for working so hard to get to were we are. )

We are meaningful use stage 1 certified and working on getting meaningful use stage 2 certified. We were voted the best Mobile EHR by Blackbook rankings who surveyed over 16 thousand physicians. We are pushing hard to be the best disruptor in the space.

Open EMR isn’t meaningful use certified, hasn’t won any awards that I have heard of. We made the right move building our own platform.

But now that we have built the best EHR, “the kernel to our operating system”, we are now focusing on having developers join the platform as we just released the drchrono healthcare API. There is so much the developer community can do to help us fix healthcare.

Coming full circle we are now allowing developers to build on the drchrono healthcare API. With 100’s of developers looking to join our vibrant community, we would love to see the open source community build on top of drchrono along with proprietary being developed.

So this is a challenge to every developer out there, build on the “new Open EMR”, our goal at drchrono is to supporting the “Kernel”, with developers building with us.

WILL OPEN EMR DIE?

The answer is no, but will the community of developers who are building the software keep innovating on Open EMR? I would say no.