Albers Projection for Maps

 I wrote this Python code a couple months ago when I needed a simple stand-alone way to plot cities on an SVG representation of a map.  There were no good, standalone Python references I could find.  Even when I found something in other languages, the readability of it was somewhat lacking.  

It seems the more math you know, the fewer characters you put in your variable names. Sigh.  Are they using meters or miles? Are they using radians or degrees? You have no idea from looking at the code, so you *have* to understand the math to be able to decipher it.

Developing this code required some investment of time in not just the math, but the geographic uses of the Albers projection. I figured it might be generally useful, so have made the code available in GitHub here:

https://github.com/cassandra/geo_maps

It includes an example that deals with some tricky issues that can come up if you want to plot points against a map of the U.S.  

When you see those U.S. maps where they have relocated Alaska and Hawaii to be in the lower left of the map, it is obvious they are not in the right location and are of different scale than the contiguous 48 states. However, did you know that they are using completely different projection parameters *and* have rotated them?  I learned this the hard way.

Starting Over

I read a thought provoking article:

How to hire senior developers: Give them more autonomy

It contains the provocatively titled section "Your Code is Worthless", and it makes a good case for this being true.  The context here is not that the running code is worthless to the business, but that the code itself is of no value to anyone else. i.e., Worrying about a competitor stealing your code base is pointless.

A basis of the argument is that the software engineering process is not about creating an artifact (the code base), but about building a "theory".  Another way to express this idea that I have seen is: the software development process is a group exercise in the organization of information.  The code is nothing more that the way to capture the outcome of that collaborative process.

To reach the conclusion that the resulting code is worthless, the article borrows from work by Peter Naur (of BNF fame) which says it is impossible for software, or its documentation, to encode all the information that was collectively organized and which is necessary to efficiently maintain it.  

There are a lot of good supporting details in that article, so it is definitely worth reading. Many of the points are aligned with my experiences.  The one conclusion that got me thinking is the premise that it is cheaper and faster to start from scratch than to try to adopt an unfamiliar code base. I do agree that this is true for a competitor getting a hold of other company's code. But could this apply to the company that owns the code?

What if a company had 100% turn-over of their developers, is starting over the best choice for the company?

Engineers usually tend to think a rebuild is the right answer in this case, but the business side never does. Is the business perspective wrong?

I have been in a situations where there was 100% turnover in a complicated code base.  I pushed to keep some of the previous developers on contract because I knew how crucial it was to leverage the information in their brains. Even if a rewrite was the right answer, this was not going to happen instantaneously and the business needed to keep operating. 

So maybe it is this continuity aspect that changes the equation.  If you have no choice but to figure out the code base, then a rewrite is only an added cost, not a replacement cost.

Can We Please Keep it Simple?

There is a famous quote about software that I have heard attributed to Brian Kernighan:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

I do not think you would find a software developer that disagrees with that statement, yet the field is overrun by a culture that seems to value succinctness more than readability.

When I began to write a lot of Perl, I wrote it like I wrote C programs and caught the ridicule of the Perl wizards who told me it was "better" to rewrite it as something that would wind up looking like this:

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];

I continued to write the code simply with the fewest "Perl-isms" I could. Our hiring budget would only allowed us to hire mere mortals to help maintain it.

Ten year later, the pattern repeats itself. When I write Python, people point out all the extra syntax I do not need, even though it is my deliberate attempt to make things more explicit and readable. Optimizing character and line counts seems to be a reflex for many programmers.

I have grown to abhor this sentence:

"Look what I can do in just one line of code."

This is usually pitched to me in the context of someone trying to convince me of the wonders of the latest, greatest programming language.

Of all the languages I have learned, there have been only a handful of language advances I have encountered where truly "better" syntax was introduced in terms of readability.  Some of them include:

• try-catch exception handling
• "finally" blocks
• "else" for for loops
• list comprehensions (but only if used judiciously)
• string interpolations

In general, if the syntactic feature is specific to a language, I will avoid using it.  I shift around writing code in many languages and the more I can do to minimize the context shift, the better.

With software, readability is 99% of the problem to be solved. As Martin Fowler has said:

"Any fool can write code that a computer can understand.  Good programmers write code that humans can understand."

I was inspired to share these thoughts after reading this article that also makes the case for keeping it simple:

 Simplistic programming is underrated

I have also recently read this related article:

Developers spend most of their time figuring the system out

This is definitely in line with my experiences and helps to emphasize how important code readability truly is.