Make It Easy To Do the Right Thing

Wes Dyer, one of the principal people behind the Volta tier-splitting, was kind enough to leave a comment on my previous post. Here is one quote from that comment:

I do want to clear up a few things about Volta that we apparently didn't make clear enough. We do not believe that you can develop an application as if it will run on a single tier and then just sprinkle a few custom attributes here and there and be done with it. More than anything else, programmers need brains. Volta does not claim that programmer brains can be checked at the door. When the programmer wants to divide the application across a particular boundary then things like network latency, new failure modes, concurrency, etc. need to be considered at that boundary. What Volta does is make expressing the transition between boundaries easier. It reduces the accidental complexity of writing all of the boilerplate code to express the programmer's intention. This allows the programmer to focus on the essential complexity of his problem domain -- figuring out how to write effective code for that particular tier boundary.

For one, it is good to hear that the architects behind Volta have a deeper understanding of distributed computing challenges -- even if the first version doesn't seem to show it. I didn't use Microsoft Volta enough to say that indeed the problem is not with the inherent capabilities and design (let's just take Wes words for that). I am also not against saving the boilerplate code (though I would favor libraries rather than code generation and try to keep the "generation" gap to a minimum; i.e. the amount of generated code or the distance between the abstraction and the next concrete level).

Lastly I am also in favor of trusting developers have brains and that it is okay to provide developer "sharp tools". So if all is good, where's the problem?

The problem is that you have to make it "easy to do the right thing" and provide the means to do the more complicated, less safe things. When I teach my young kids (and I can objectively say they are very
smart :) ) to use a knife, I don't hand them the razor sharp, butcher knife first. They start with the plastic ones. When they've mastered that they can try something more dangerous. When you allow distributing something at a flick of an attribute and put marketing blurb on the site that makes it compelling to use it you create the wrong impression to the less experienced folks.

In one project which architecture I reviewed, the (very talented) architect/developer designed his own distributed transactions system (he shouldn't have been doing that in the first place -- but that's for another post). When designing this he built in a lot ways to control the transaction behavior including the option to allow transaction participants to prevent rollback without failing the transaction. Circumventing the transaction was as easy as making it work properly. Are there edge cases where you may need to have one participant violate the ACIDness of the transaction? I guess so -- but that is not the general rule. Most of the time when you commit a transaction you expect it to be ACID. if for some reason it didn't behave that way -- you want to know about it, even if it didn't actually failed. When you don't make it easy to do the right you get unexpected behaviors, you get hard to explain bugs, you get slow performance, etc.

Developers using tools, smart as they may be, don't usually go and read all the source code of the tool/framework they are using (maybe they should). If two options are just as easy to use, it seems safe to
assume they are just equally right. Things which are unsafe should be clearly marked as such to prevent mis-use by unexperienced users. This is especially true for tools that are targeted for common use and to ease the life of inexperienced developers.

Posted by Arnon Rotem-Gal-Oz at 04:50 PM  Permalink