Correct, Understandable, Fast

Alex Reid recently wrote a blog posting about there being no shame in code that is "good enough".  I suspect most people are only going to read the first few paragraphs and use this as some sort of justification for producing crappy code. So, as a service, I am going to quote the important part at the end of the blog posting.

Good enough doesn't imply half-arsed or lashed together. It should concisely meet the requirements at hand, not what you think the requirements might be next week. It doesn't mean you are naive and haven't considered the big picture, nor are you lazy or stupid. It doesn't mean you are a moron if you don't use wildcard generics and don't have a fetish for multiple inheritance.
I believe all developers should have a geek valve that prevents them from introducing overly-generic, indecipherable black magic to a codebase. In conversation you would look a bit unusual if you insisted on using flowery language to express a point that could be adequately conveyed in more standard terms. Some people may miss your point. The fact that their grasp of English isn't as advanced as yours doesn't make them stupid. It means you aren't communicating efficiently. Why can't the same logic apply to code? Favour explicit and clear over clever.

The challenge is in defining what "good enough" means.  I'm not going to attempt that here, but I am going to say something about what I minimally expect from code that I am supposed to take seriously.

When I write code I have the following priorities:

1. Correct
2. Understandable
3. Fast

Correct.

If the code is not correct it has no reason to exist in the first place.  The most convenient way to verify that the code is correct is to write proper tests.  If I stumble across a piece of code that lacks tests, I am going to assume that the author either doesn't know or doesn't care if his or her code actually works.  

It is not okay to skip writing tests.  Yes, I know all the excuses for not writing tests so you can spare me the tedium of repeating them.

Understandable.

The code you write is for communicating with other people.  Not for communicating with the compiler.   The compiler will accept a lot of unreadable nonsense -- your coworkers will not.  For your code to be understandable its intent has to be clear.  Once the intent is clear you should aim for the simplest solution that will do -- the simpler a solution is the easier it will be to verify.

It is not okay to skip documenting your code.  It is not okay to add layers of abstraction where none are needed.

Fast.

If you have managed to demonstrate that your code is correct and understandable, you should ask yourself if it will perform adequately.  In a lot of cases there will be no need to optimize your code.  The first thing you need to do is to understand what your performance goal is.  Then you measure.  Then you optimize.

Most programmers are bad at writing correct and understandable code -- which sort of makes it irrelevant whether it is fast or not.

Receipts

While I'm sorting through the receipts from this year's travels, one thing really annoys me: the terrible formatting of receipts.

A receipt essentially has only three interesting pieces of information:

• What
• When
• How much

If I can't find the "when" and "how much" in under a second, the person doing the receipt layout has failed.

Usually, the hardest piece of information to locate is the when. Our inability to express times and dates has always amazed me.  I can't think of any single piece of common data that incurs more processing cost and errors than dates and times.

Why does anything related to accounting have to be so badly designed?  Is this stupidity or laziness?

Democracy and the press.

According to the "Democracy Index 2010" from The Economist, democracy is steadily retreating.  The world is gradually becoming less democratic.

A few days ago I heard that CNN is letting something like 50 of their reporters go.  The reasoning was that CNN would rather not have that many editors, reporters and photographers on staff, but want to source the material from "citizen reporting".

Whatever that means.

The biggest problem with this is that when a private person starts taking pictures of something that isn't quite right, there is a risk that law-enforcement will intervene and harass the individual attempting to record events in any way.  People have ended up getting harsh sentences for recording the actions of law enforcement in public spaces.  Pointing a camera at a police officer is extremely high risk.  Even in many western countries.

The threshold for throwing an accredited journalist in jail is considerably higher.  First off, law-enforcement usually think twice about molesting journalists in nominally democratic countries.  Second, journalists are usually more aware of their rights and more prepared to challenge law enforcement.  Third, if they do end up in jail, they have the backing of organizations that know a thing or two about making life miserable for corrupt officials.

We need proper journalists to poke their lenses in the faces of those tasked with upholding the law.  "Citizen reporting" is all well and good, but it is inadequate to prevent our democracies from crumbling.

Sound, dynamics, and such

This morning I came across a newspaper article trying to describe difference between current and former mastering practices for records.  And of course with generous helpings of confusion.  Most records today are mastered in a way that leaves very little dynamics.  For those of you not familiar with what "dynamics" means in this context;  high dynamics means that there is a bigger difference between the loud and the silent parts of a recording.

There are lots of tricks to boost silent parts and dampen the loud parts, but the most important tool in the arsenal to accomplish this is various forms of compressors.  For more information on dynamic compressors the article on Wikipedia might be helpful.

While over-zealous use of compressors makes the sound somewhat dull and uninteresting it might be useful to point out why this is done.  It is an adaptation to make recordings sound a bit better in challenging listening conditions.  Most of us do the majority of our listening (to music and other content) on crappy earbuds in noisy environments.  By compressing the dynamic range you don't have to ride the volume controls on your device when you are listening to music in your car, for instance.

This is nothing new, but it is, and has always been, a balancing act.  There have always been devices and listening conditions where dynamics is a challenge.  For instance, a lot of mastering engineers will have multiple sets of loudspeakers, some of which are rubbish, to test their settings.  In an interview I read years ago, one mastering engineer pointed out that he used the crappy stereo in his car to test his work.  If it worked there, and on his high end studio monitors, it was probably a good final master.

As a consumer I've long wished for compressors to become part of the player -- so that you can choose to what degree content should have its dynamic range compressed.  For instance, if I am listening to a record at home, on a decent'ish stereo, I want the full dynamic range and as little compression as possible.  However, if I am in my car, I might want the dynamic range to be as narrow as possible so the faint parts are not drowned out by noise and the loud parts do not burst my eardrums.

Some movies have awful sound mixing.  The silent parts are too silent and the loud parts are too loud. If you are watching a movie in a noisy environment you end up riding the volume buttons and being annoyed.

Some devices have very simple compressors.  For instance I had a CD player years ago that had a built-in compressor.  (Generally you want to perform any compression on the digital signal, not the analog signal).  However, this is not a very wide-spread feature.

Learning how to use a mastering compressor takes time.  In fact, they can be quite complex beasts, featuring different compression parameters for different frequency bands etc.  It is going to take a while for fully automated detection of adequate compression parameters is going to sound good.  This is why I would love if the sound industry could come up with a reference model for compressors and encode the parameters into an automation track delivered with the content.  This way the consumer could turn compression on when desirable -- or even be given a control that lets the consumer decide the severity of compression.

The lost art of mending.

A couple of years ago one of my Alesis M1 speakers stopped working.  These are powered studio monitors, which means they have a PSU in each speaker and an embedded amplifier.  This is a known issue for these speakers.  The problem is a 2 watt resistor that is mounted too close to an electrolytic capacitor, so the resistor heats up and over time ends up frying the capacitor.

At the time when this happened I didn't bother googling it, so I just noted the problem and dropped the speaker off at a company that my local dealer of sound equipment recommended.

It took them a couple of weeks to fix and the bill was for about $500-600.  The guy had just thrown out the PSU, ordered a brand new one and put it in.

Of course, the other PSU failed shortly after.

Not wanting to spend another chunk of cash, this time I researched the issue a bit.  All in all it took me 3 minutes of googling to figure out what was wrong.  At the time I didn't have a selection of components lying around, so I had to spend 3-4 minutes online finding and ordering the components.  They arrived 2 days later and then it took me all of 10 minutes to get set up, replace the components (with somewhat uprated components) and verify that the repair worked.

Total component cost was something in the area of $2-3 and then I had nine spare sets of components, so if the problem returns I can fix it easily.  Any idiot can fix it.

What depresses me is that people don't know how to fix things.  The dude in the shop apparently had no useful skills.  Because if he did he could have saved himself the hassle of ordering (and waiting for) a new part, and he could have saved me a huge bill and perhaps seen some return business.

I see the same thing with my car.  Every spring and every fall I switch to or from winter wheels and I stored the other set at this company.  The last time I picked up my car, one of the wheel nuts was missing and about 4-5 of the remaining wheel nuts had been over-torqued thus destroying them.  You would think that when you pay someone to do this, and they do this for a living, they would be able to do a better job.  Even I know that you can't apply arbitrary amounts of torque to the wheel nuts, and I am not a mechanic -- I don't do wheel changes for a living.

About once per year I go to the local landfill to get rid of things I don't need.  Thankfully, they have various recycling stations there so I can at least hope that some of the things I get rid of there actually are recycled responsibly.  But I am still depressed when I drive home.  So much STUFF.  And most of it still usable -- and a lot of the stuff that is broken should be easily fixable.

If you care about the environment you should care about the fixability of your gadgets.  You can buy carbon offsets or take part in all manner of feelgood environmental nonsense,  but the fact is that the device you are using to read this blog posting will end up in a landfill when it breaks or when you get a new gadget.  Because you are not going to fix it, and I am pretty sure you do not know of anyone capable, willing or qualified to fix it either.  It might end up in some third world country where some kid is going to set fire to it to get the metals out of it -- releasing noxious gases.

If you have kids or you want a hobby: lots of gadgets have cool components that you can scavenge. Rather than throwing away that useless printer, rip it apart and have a look inside.  There's lots of fun stuff inside that you can build interesting toys from.  And it isn't hard.  You don't have to be a genius to play with these things.  Get an Arduino and learn.

I think we need to make it cool to know how to fix stuff again.