Software/Device Development and Design

Originally posted: September 16th, 2008

(I wrote this a while ago, but didn't post it for some reason. So I'm posting it now.)

I've been very vocal about my distaste towards many of the features of various dynamic programming languages (at least for the purposes of any non-trivial program). Recently, while reading the first chapter of "Practical Cryptography" (by Niels Ferguson and Bruce Schneier), it occurred to me that authors' explanation of "The Evils of Performance" was very relevant to my opinions of these languages.

In that first chapter, the authors stress the importance of security being made the single top priority. They make this point by looking at security as an engineering discipline. As they point out, good engineering has always been about making safety and reliability the primary concerns. No other concern should ever be optimized to a point where it could interfere with safety or reliability.

The authors go on stating that, in the same way, the computer industry needs to prioritize security far ahead of efficiency. To illustrate, they present the explanation: "We already have enough fast, insecure systems. We don't need another one."

I'd argue that in computer programing, reliability deserves a similar status ahead of efficiency. Just as in other forms of engineering though, this doesn't just mean placing reliability ahead of the actual product's efficiency. This also means placing it ahead of the efficiency of the development process itself. We already have enough unreliable software being churned out.

Which brings me back to dynamic programming languages: The reason I so strongly dislike many (albeit, not all) of the characteristics of these languages is because they treat short-term programmer productivity as a holy grail (sometimes even stating it as the single primary goal), while allowing good engineering principles like reliability to fall by the wayside. The real irony, though, is that maintaining an unreliable program is itself a drain on programmer productivity, thus hijacking any long-term productivity gains. So for any non-trivial project, these languages would have been more productivity-friendly by going the engineering route and making design decisions that focused on aiding the creation of reliable software at a reasonable speed rather than potentially buggy software at rapid speeds.

Read more

Originally posted: April 21st, 2008

Anyone stupid enough to design an interface where the "Close" button minimizes to the system tray instead of closing, deserves to be fired and then restricted to never being allowed to do anything other than cleaning toilets. That’s really all there is to say about it.

UPDATE (4/24/08): A quote:

"If you use option from File>Close then it is supposed to minimize Skype on system Tray."

- Andre: Skype Support

How is it possible that anyone could be that stupid (not to mention inarticulate) and still be allowed to work?

Read more

Originally posted: March 10th, 2008

This pretty much encapsulates exactly what is wrong with the field of Human Resources:

"I don't know anything about programming, but I'm very good at identifying people who are good at it."

That is a real quote. I was actually told that by a recruiter I met with a few months ago. Needless to say, I never called them back.

The saying "It takes one to know one" isn't just a generic insult. It's the honest truth when it comes to identifying skill. HR people should just stick to payroll (Or then again, maybe leave that to the real accountants).

As long as I'm ranting about HR, here's a classic excerpt from "Joel on Software" that I couldn't have worded any better:

"The recruiters-who-use-grep, by the way, are ridiculed here, and for good reason. I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone."

- The Perils of JavaSchools: Joel on Software: Joel Spolsky

Read more

Originally posted: August 14th, 2007

The title sums up why I consider multiple endings a terrible game mechanic.

It's at least tolerable in games like Castlevania (the ones with the "Metroidvania" layout, like Symphony of the Night), where you can find out you got a bad ending, pick up at your last save, and simply continue playing towards the real ending.

Resident Evil 1, on the other hand, demonstrates the wrong way to handle multiple endings (if you must use them, that is):

1. Make an arbitrary branching point halfway through the game.
2. Don't bother making it clear the branching event has two possible outcomes.

Now, when the player finishes the game and…loses, the only way for them to win is to replay the whole game all over again (or just the entire second half if they were lucky enough to maintain a save point from just the right spot). Wonderful!

Speaking of Resident Evil 1, I would rant about "limited save" systems as well, but unlike multiple endings, at least those appear to have gone the way of the interactive B-movie.

Read more

Originally posted: May 16th, 2007...BUT STILL IRRITATINGLY RELEVANT!!

Seriously, am I the only programmer left who uses a light-on-dark color scheme?

It seems like every other program and website I go near has some element that completely chokes on light-on-dark. Commercial, open-source, Windows, *nix, whatever, it happens everywhere. (Except Mac OS. Last I checked (admittedly way back at v10.2), you can’t even set up a custom color scheme on one of those. Unless you count setting the highlight color - whoohoo...)

The rule of thumb I like to follow:

Foreground and background colors: Set both or set neither, but never just one.

In the interest of avoiding potential hypocrisy: If you ever come across something I made that strays from that, feel free to smack me.

Read more