Symphonious

Living in a state of accord.

Decision By Consensus

Rich Bowen – We’ve Always Done It That Way:

Principle 13 in the Toyota Way says that one should make decisions slowly, by consensus, thoroughly considering all options, and then implement those decisions rapidly. We believe a similar thing at the ASF. So to people who have only been around for a short time, it looks like we never change anything. But the truth is that we change things slowly, because what we’re doing works, and we need to be sure that change is warranted, and is a good idea.

I’m a big fan of decision by consensus. It doesn’t mean everyone agrees (consensus does not require unanimity) but it does ensure that the bulk of the team are all on board and moving in the same direction.

It does take longer – much longer. And it requires investing a lot more into the decision making process, having debates, doing research and planning out how things will actually work. In the end though it’s worth it to avoid having the decision undermined by people resistant to the change or having decisions made too independently and then having people heading off in different directions.

Just don’t forget that one of the best ways to build consensus is by running a trial. It’s much easier to plan out a trial (including a rollback plan) and gain consensus for running it than for making the change permanently.

Another example of Less Haste, More Speed.

Less Haste, More Speed

Jeffrey Ventrella in The Case for Slow Programming:

Venture-backed software development here in the San Francisco Bay area is on a fever-pitch fast-track. Money dynamics puts unnatural demands on a process that would be best left to the natural circadian rhythms of design evolution. Fast is not always better. In fact, slower sometimes actually means faster – when all is said and done.

Jeffrey’s right in suggesting that we sometimes need to go slower to go faster, unfortunately he makes the mistake of believing that committing and releasing in very short cycles is the cause of these problems:

My programming style is defined by organic arcs of different sizes and timescales, Each arc starts with exploration, trial and error, hacks, and temporary variables. Basically, a good deal of scaffolding. A picture begins to take shape. Later on, I come back and dot my i’s and cross my t’s. The end of each arc is something like implementation-ready code. (“Cleaning my studio” is a necessary part of finishing the cycle). The development arc of my code contribution is synonymous with the emergence of a strategy, a design scheme, an architecture.

This kind of design and development arc is completely independent of how often the developer commits or how often a release is taken. As you speed up your commit and release cycle, you mostly shouldn’t change the design and development process of any given change you simply reduce the size of the change. By tackling much smaller problems at a time it’s much easier and quicker to go through the full arc of understanding, experimenting, scaffolding, building and tidying.

Part of making each small change is considering how it fits in with and modifies the overall system design. Bad development teams forget this and wind up with an awful mishmash of designs all cobbled together, but that’s a reflection of the team’s design ability, not of the process. Good teams gradually adjust the system design as they go, sometimes in subtle ways sometime with more radical changes. Doing so means the system design is optimal for each stage of its life.

Commenter mmlac nails it:

Maybe [the machine-gun committer] IS doing the same as you, just sharing the progress with the team, so people can spot obvious mistakes earlier and see the approaches and stop him in time if they have more experience with the way they are trying to go?

You are basically advocating waterfall. And the issues you face have nothing to do with the speed of coding and the number of commits.

That’s not to say that there isn’t value in the saying “Go slower to go faster” but the much better way to phrase it is “Less Haste, More Speed”. It’s not about going slow, it’s about not rushing and doing a good job. It means taking the time to break down large changes into smaller, simpler incremental changes so you don’t have to deliver them all in one go. It means considering what adjustments to the overall system design are required for each change to make it fit in well.

And it means committing and releasing more often. Regularly investing time to prove things are completely finished and sent off to users instead of building that time up as technical debt because you’re attempting to make too big a change at once.

You don’t go faster by simply trying to go faster – you go faster by identifying and eliminating bottlenecks which requires you to do things that individually appear to make you go slower but make the overall system go faster. Committing and releasing regularly (continuous integration and continuous deployment respectively) are solutions to the bottle neck of horrendous merge and release processes that result from not doing them regularly enough.

The One True Language

Lawrence Kesteloot has an excellent post Java for Everything.

About a year ago, though, I started to form a strange idea: That Java is the right language for all jobs. (I pause here while you vomit in your mouth.) This rests on the argument that what you perceive to be true does not match reality, and that’s never a popular approach, but let me explain anyway.

There are two key realisations that are vital to understanding why this argument has merit and the first one is right there in the introduction: what you perceive to be true does not match reality. As Lawrence notes:

The problem is that programmers perceive mindless work as painful and time-consuming, but the reality is never so bad. Here’s a quote from a forum about language design:

It really sucks when you have to add type declarations for blindingly obvious things, e.g. Foo x = new Foo(). – @pazsxn

No, actually, typing Foo one extra time does not “really suck”. It’s three letters. The burden is massively overstated because the work is mindless, but it’s really pretty trivial.

Every developer knows the mantra that code is only written once but it’s read many times, yet we focus on the number of keystrokes required to do something or the number of lines required. Besides which, the time required to type statements is almost never the limiting factor for how fast code can be written – it’s almost always dwarfed by the amount of time required to think about what the code should be doing and how it fits into the architecture.

The second key realisation is how powerful consistency is:

This focus on a single language has had an interesting effect: It has encouraged me to improve my personal library of utility functions (teamten.jar above), since my efforts are no longer split across several languages. […] I can now confidently invest in Java as an important part of my professional and personal technical future.

Being consistent in your choice of language allows you to learn it in much greater detail, become more familiar with a wider range of its available libraries and idioms and get a big return on investment when developing tools or libraries to pave over any rough spots.

None of this implies however that different languages aren’t better suited to different tasks. It just means that the benefits from switching languages is generally overstated and the costs generally understated. Thus, it should be far less common for switching languages to be worth it.

There are times when switching languages makes a lot of sense. For example, if your one true language in Java and you need to write code that runs in a web browser, Java is such a poor fit that it is worth switching languages.

Similarly, it doesn’t have to be Java that’s your one true language – C# would probably make more sense if you primarily worked with Windows environments and C would be better if you were a kernel programmer.

Ultimately it’s not so much about what choices you make, rather that it’s about correctly weighting the factors that go into those choices. We need to be aware of the innate bias we have towards overvaluing the elimination of immediate pain and undervaluing longer term benefits.

Safely Encoding Any String Into JavaScript Code Using JavaScript

When generating a JavaScript file dynamically it’s not uncommon to have to embed an arbitrary string into the resulting code so it can be operated on. For example:

function createCode(inputValue) {
return "function getValue() { return '" + inputValue + "'; }"
}

This simplistic version works great for simple strings:

createCode("Hello world!");
// Gives: function getValue() { return 'Hello world!'; }

But breaks as soon as inputValue contains a special character, e.g.

createCode("Hello 'quotes'!");
// Gives: function getValue() { return 'Hello 'quotes' !'; }

You can escape single quotes but it still breaks if the input contains a \ character. The easiest way to fully escape the string is to use JSON.stringify:

function createCode(inputValue) {
return "function getValue() { return " +
JSON.stringify(String(inputValue)) +
"; }"
}

Note that JSON.stringify even adds the quotes for us. This works because a JSON string is a JavaScript string, so if you pass a string to JSON.stringify it will return a perfectly valid JavaScript string complete with quotes that is guaranteed to evaluate back to the original string.

The one catch is that JSON.stringify will happily JavaScript objects and numbers, not just strings, so we need to force the value to be a string first – hence, String(inputValue).