Cap'n Arbyte's

Advertisements


Local interest


Other sites


Blogroll

The KISS of Robustness

The "KISS" mantra — keep it simple, stupid — is a beloved design principle. Simpler systems are easier to understand, easier to create, and easier to validate. Over the past couple weeks I've bumped into this several times in diverse contexts and wanted to share an anecdote of what I consider good software philosophy.

Yeah, this is perilously close to "blogging about work". I usually try to avoid that, but it's For A Good Cause™.

Since a bunch of my co-workers read my blog I have to preface this by saying that I don't intend any disrespect by my choice of example. I understand the circumstances under which the tool was created, and it was reasonable for it to turn out the way that it did, even though I don't like it. :)

Intel has been selling multi-core processors for several years, and one very nebulous and mysterious piece of internal software whose source code I recently got to see just happens to care about how many cores there are. In this context the software is associated with a simulation of a processor, not with a physical processor. It's important to note that the number of cores running in the simulation can be fewer than the number of cores in a physical processor. These smaller simulations run faster and consume fewer resources, so we prefer them in many circumstances.

Our mysterious software requires the user to specify the number of cores.

That's dumb.

This mysterious software has access to the simulator, and the simulator already knows how many cores it's simulating. The mysterious software should learn how many cores are running from the simulator, not from the user.

Requiring the user to specify it is to invite error. If they do it manually, they might use the wrong number. If it's part of an automated work flow, that flow has to have the sophistication to provide the correct number. You get to choose between error-prone or complicated — what a great choice!

The KISS advice is for the mysterious software to take care of itself. Don't burden the user or the automated work flow. It's easy to learn how many cores there are by simply trying to "attach" to each possible core and stopping when the attempt to attach fails. Yeah, that means your software will have to <gasp> loop over the possible cores and <choke> check for failure to "attach". (But you're already checking for failures because you're a disciplined programmer, aren't you?)

The beauty of this approach is that it can't break. There's no concern about the user doing something wrong, or about adding complexity or maintenance work to an automation system. The complexity of dealing with a variable number of cores remains, but it's contained within the mysterious software itself and does not pollute its software ecosystem.

And did I mention it can't break? You should be as excited about that as I am — it's always correct, automatically, and nobody ever has to worry about it again! Awesome!

When the mysterious software can take care of itself, no one else has to do it. Simple is robust.


Warning: mysql_pconnect(): The server requested authentication method unknown to the client [mysql_old_password] in /home/kmarkley/scripts/arrcom.php on line 47

Warning: mysql_pconnect(): The server requested authentication method unknown to the client in /home/kmarkley/scripts/arrcom.php on line 47
Tiny Island