Idea vs. Execution

Last year I was on a flight and the in-flight entertainment switched after the movie to some other types of shows. One of them was around interesting engineering feats and had a feature on a submersible car. It could basically drive into water and then navigate as a submarine (shallow depth naturally) under the water.

A few rows ahead of us I heard a woman turn to her friend and exclaim "hey, I thought of that!"

This betrays, I think, a common propensity to value an idea over execution. Or at least to underestimate the challenges in the execution. Imagine all of the myriad engineering challenges that had to be overcome in order to execute on this idea of a submersible car. And then someone tries to sum it up with "I thought of that too".

For me this story embodies the increasingly common maxim for the entrepreneur that it is the execution that matters. To share your idea. Get feedback. That everyone else has their own ideas. And if somebody pulls off something that you had thought of but didn't execute on - be impressed with them, not with yourself for having the idea too.

Symmetry and Code Refactoring

Whenever I make large refactoring changes within a project I think about it in terms of symmetries. I'm not sure anyone else could find that useful, but it's worth a shot.

While getting my Physics undergrad degree there were two things that really held my fascination, quantum physics in general and the role of symmetry in natural laws.

In my opinion the concept of symmetries in nature as the basis of conservation laws was one of the most elegant findings in Physics. We owe Emmy Noether for that almost 100 years ago (between this, Relativity, and Quantum Mechanics, the early 20th century in Physics was just a ridiculously productive period of progress in scientific understanding).

Since then, I've found it interesting, and sometimes useful, to think about things in terms of symmetries. For instance, I think a fully rational ethical philosophy can be built on top of expressing our existence in terms of symmetries (the ideas behind "walking 1000 miles in someone else's shoes" or "The Golden Rule" I see as rooted in this).

But back to coding...

I've sometimes found myself needing to make major changes to a complex system. This can always, as they say, be "fraught with peril." The first (and biggest) of these started with a monolithic Java app that wasn't built on a framework, represented objects with maps, had manual construction of SQL for database access, used CORBA for Java client communication, had little vertical layering of levels of abstraction and little horizontal separations of logically separate spheres of influence.

Certain types of changes to that type of system were just a nightmare to contend with. A particularly obvious example is how changes to the object model that affected the storage in the database might require changes in several seemingly unrelated places in the code where SQL strings were manually constructed.

The team I led transformed the app (which we already started shipping) to be J2EE based, with an EJB interface, employing an ORM layer, with standard Java communication between client and server, and good horizontal and vertical layering, while adding functionality for continued evolution of the product.

To me, the key to successfully making these changes was symmetry. And the reason why is because symmetry essentially boils down to the invariance of some observable for a given type of transformation to a system.

The simple examples of symmetry are those of geometry. A circle is fully rotationally symmetric because no matter how many degrees you rotate it, its appearance remains the same. A square has a rotational symmetry of the 4th order, because you can rotate it 90 degrees and its appearance remains the same.

And this has to do with code refactoring? Sure. The idea was essentially to map out a series of transformations in the code, with a plan for what behavior of the system was going to be preserved for each particular change. This allowed the ability to test each change to make sure that it preserved the behaviors that it was meant to.

I saw each coding change as rotating the square - and the goal was to rotate it the full 90 degrees so that it still looked like a square. Even if what happened behind the scenes involved major structural change.

It's certainly possible (who knows, maybe advisable) not to think of this in terms of symmetry, but that's just how I do it. The key is really to try not to attack everything at once. But instead, to split the changes you're going to make into changes where each can be tested to not have broken the behaviors that it shouldn't have affected.

For me, thinking about it in terms of symmetry provides discipline in terms of defining how much change should be taken on at any given time. But your mileage may vary.