From kernel drivers to modern web apps: The faster you build, the more you deliver.

As developers, we know that shorter dev cycles lead to better productivity and align us better with business goals. Back in 2010, I was working on a Linux kernel driver and experienced first hand the magical impact of a shorter dev cycle. I'd like to share this story here, and show how you can enjoy the same magic in your web dev workflow.
Almost ten years ago I was building an enterprise storage product at IBM. The very day I joined, I inherited the kernel driver for the box's fibre channel card. That high-speed connection was the primary read and write interface to our storage device.
That driver originated with the card manufacturer itself. It later went through an open source phase and then through a couple of iterations with developers inside our group. When it found its way to me, the driver consisted of 37,000 lines of code! And it had a bug.
It was one of those nasty bugs. The kind that just happens every once in a while and nobody knows why. To make things worse, that particular driver bug generated a kernel panic (the Linux equivalent of the Blue Screen of Death) and caused one of the internal components to restart. This was a customer visible event with the side effect of slowing the entire storage device down for a few hours. Hardly a desired situation.
Several of our best kernel experts looked through the driver code, and couldn’t find anything wrong with it. The code seemed fine. The data seemed fine. The card seemed fine as well. No one could put their finger on any underlying issue, yet the bug kept rearing its ugly head. Something had to be done.

Getting the driver out of the kernel

One day we realized that we really didn't care so much about the bug. We did, however, care a lot about its side effects. A kernel panic is a major incident, whereas a driver failure is a minor event we could easily live with.
We came up with a plan to convert this kernel driver into a regular user application. Application failures cannot cause kernel panics and so the side effects of the bug would be eliminated.
Over the course of two weeks, we built a micro version of the driver to control the fibre channel card from inside the kernel. We then moved the bulk of the driver's code into a regular application, where it ran on top of a thin shim we built to emulate the kernel environment.
The results were incredible. Immediately, our storage system became much more stable, with zero impact on performance. The nasty bug was still there, but instead of crashing an entire machine, it would now crash a single application. No more panics. No more restarts.
Surprisingly, the biggest benefit was something we never anticipated. Building a kernel driver takes time. The development cycle for kernel software on our system was 3-4 minutes. Every change made to the code took 3-4 minutes to test. That's a very long time, and you tend to wander off to check your email, browse the web or make a nice hot cup of tea while you wait.
With the driver now running as a regular application, it took mere 3-4 *seconds* to test code changes. This was life-changing for us. Three seconds is a short enough period and so you don't lose focus. You are waiting synchronously to see how your changes affect your code. You are in the zone.
This unexpected side benefit triggered an amazing coding frenzy. Over the course of these two months, I rewrote every line of code in that driver. I could easily run small and quick experiments, and ended up deleting 30,000 lines of unneeded logic. At the end of those two months, the driver consisted of only 7000 lines of code. I also ended up eliminating that original bug, but at that point (even though we didn't care so much anymore). The experience opened my eyes to the magic of the short development cycle.

Webpack

A few years later, I started to dabble in web development. I have always been fascinated by user experience, and the web was the new front. Building for the web was an immediate delight. You code, save, reload, and voila - changes appear in the browser right in front of your eyes.
Webpack has taken this a step forward. It includes a local development server which continuously watches your source files. It also injects a small piece of JavaScript code into your pages, that continuously monitors the server for updates. Now, every time you save your code, the server detects the change and tells the page to reload. If you use auto-save, you are basically able to see your app changes as you type. Amazing.

This is the best development experience I have ever had. This kind of immediacy helps you find and fix problems faster. It removes all mental clutter and lets you focus on what you're building. It unleashes creativity like nothing I have ever seen before.

So what about the backend?

Unfortunately, only frontend development provides this kind of experience today. Backend code typically takes minutes to update. Frontend developers who depend on independent backend teams may find themselves waiting for days until backend changes come through.
We think this is unacceptable. At Reshuffle, we enable React developers to build full-stack applications, by extending the magic of Webpack to the cloud. The idea is simple: you add backend logic directly to your frontend projects. This backend logic consists of simple JavaScript functions, that your frontend code can call like any other function. Simple, right?
Behind the scenes, Reshuffle seamlessly deploys those functions to the backend runtime, be it a local development server or a fully scalable, production-grade cloud environment. We replace the original functions with stubs that generate HTTP requests to the server, taking care of encoding, serialization and errors in the process.
The result is a fast, seamless coding experience. You can focus on your app instead of boilerplate code, deployment or managing the cloud. You get that short, immediate dev cycle for your frontend and your backend. Your newfound productivity lets you focus on being creative.
Try it out today at reshuffle.com.