Graham's .plan:

On Software

It makes me feel old (hah!) when I think about the current direction software seems to be headed. Specifically, it seems like people are "utilizing" complicated communication protocols, causing the relationships between software applications to be ridiculously complex. XML is a moderately ok Markup Language, but if you attempt to convince me to use it for anything else in the universe, including configuration files, the most docile response I will have for you is severe mockery. If XML is so easy to parse, please write me a parser in bash. One that can handle comments. Oh, and don't even get me started on dbus

A recent example that, though not identical, nevertheless reminded me of this is monitoring software. I needed an application to monitor a single host via ping, and alert myself and a coadmin of any downtime. This piece of software did not need to be complex, as the thing it was monitoring was a machine running nagios (yuck), which obviously can not tell us when it is down. After a few minutes of thought, and looking back at all of the research on monitoring that I've done for work's much mightier needs, I decided to roll a quick perl application to take care of the job. The first thing I did was attempt to think of a name, coming up with the most simple, straight foward option possible: "mon". Before creating a git repository, I did a quick check to see if that name was taken by some FOSS software package. A quick aptitude search '^mon$' later, and I had actually found the package that was what I was going to build and name, anyway.

An example of software done (mostly) right, look at just about anything by djb, other than human interaction. It's relatively easy to draw a diagram documenting data movement for any of his software, and though his log formats are braindead, it's fairly easy to debug issues because of this. What's that, you can pass data with STDIN and STDOUT? Miraculous!