Ethereum Blog

The Ethereum Development Process

Introduction

user

Gavin Wood


LATEST POSTS

The last Blog Post 11th January, 2016

Chain Reorganisation Depth Expectations 08th August, 2015

technical

The Ethereum Development Process

Posted on .

So I’m not sure if this kind of development methodology has ever been applied to such an extreme before so I figured I’d document it. In a nutshell, it’s sort of like test-driven triplet-programming development.

While speed-developing our alpha codebase, four of us sat around a table in the office in Berlin. Three people (Vitalik, Jeff and me) each coders of their own clean-room implementation of the Ethereum protocol. The fourth was Christoph, our master of testing.

Our target was to have three fully compatible implementations as well as an unambiguous specification by the end of three days of substantial development. Over distance, this process normally takes a few weeks.

This time we needed to expedite it; our process was quite simple. First we discuss the various consensus-breaking changes and formally describe them as best we can. Then, individually we each crack on coding up the changes simultaneously, popping our heads up about possible clarifications to the specifications as needed. Meanwhile, Christoph devises and codes tests, populating the results either manually or with the farthest-ahead of the implementations (C++, generally :-P).

After a milestone’s worth of changes are coded up and the tests written, each clean-room implementation is tested against the common test data that Christoph compiled. Where issues are found, we debug in a group. So far, this has proved to be an effective way of producing well-tested code quickly, and perhaps more importantly, in delivering clear unambiguous formal specifications.

Are there any more examples of such techniques taken to the extreme?

profile

Gavin Wood

http://gavwood.com/

Comments
user

Author Alexandre Van de Sande

Posted at 7:15 pm March 5, 2015.

> Are there any more examples of such techniques taken to the extreme?

It reminds me of the story of the development for navigation software for modern airplanes. I couldn’t find a proper source to put here but what I learned is that Boeing has three different software implementation for their specs, done by completely independent teams in different languages, and they must all be in consensus at all time (or 2 out of 3) in order for it to control the airplane.

Very similar idea.

Reply
    user

    Author AlexPetrenko

    Posted at 3:22 am March 9, 2015.

    Eric Drexler in his beautiful “Engines of Creation” describes this kind of idea as “reliability over design diversity”. The core idea is to have independent implementations developed by different people/teams to minimize the risk of major design and architectural mistakes.

    Reply
user

Author Joshua Davis

Posted at 4:41 pm March 6, 2015.

An example of how the Google Ventures team develops a product in short bursts: http://gimletmedia.com/episode/13-fake-it-til-you-make-it/ – see video in link description.

Reply

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

View Comments (3) ...
Navigation