Month: June 2009

Catalog engineering and reverse engineering

Posted on by John

Software development is not just engineering, it’s also reverse engineering. It’s not just about deciding what code should do, it’s also about experimentally discovering what code does do. Many software developers, especially those at the bottom of the career ladder, spend more time reverse engineering than engineering. But even developers working on new “green field” projects spend a significant amount of time reverse engineering either their own code or third party code.

Anyone writing software these days spends a great deal of time researching software libraries. Anybody writing a little web page in PHP, for example, is leveraging a tremendous amount of code that others have written. Programmers work at a much higher level than they did a few years ago. We’re standing on the shoulders of giants.

But there are problems. At a minimum, you’ve got to look up the software pieces you want to use. (Engineers call this catalog engineering, spending all day looking up parts in catalogs rather than designing new parts.) Worse, the software pieces are often poorly documented and buggy. If documentation exists, you have to experiment with the software to determine whether the documentation is correct (or at least to test whether your understanding of the documentation is correct). If documentation doesn’t exist, you have to infer what the software does by searching the web and doing your own experiments. Some pieces of software are better documented and less buggy than others, but all documentation is incomplete and all software has bugs.

That’s what professional software development is like. If you enjoy problem solving and experimentation, you’ll enjoy software development. But if you can’t stand catalog engineering and reverse engineering, don’t go into software development.

Two kinds of software challenges

Posted on by John

Here’s a quote from Bricklin on Technology regarding what colleges should teach in software engineering. (I added the bullets.)

For years we emphasized

  • execution speed,
  • memory constraints,
  • data organization,
  • flashy graphics,

and algorithms for accomplishing this all. Curricula need to also emphasize

  • robustness,
  • testing,
  • maintainability,
  • ease of replacement,
  • security, and
  • verifiability.

The criteria in the first list are primarily mathematical. The criteria in the second list have more to do with human nature. For example, code is maintainable if it’s organized so that a person can readily understand and modify it. That’s a matter of psychology.

More projects fail due to problems with the second list. Problems with the first list tend to be localized. Problems with the second list tend to permeate a project. A clever person may have a quick fix for problems with the first list. Quick fixes are rare for problems on the second list.

Why are bad guys so interesting in novels?

Posted on by John

Ever wonder why so often the evil characters in literature are more interesting than the good ones? Here is an explanation from novelist P. D. James, taken from an interview with Ken Myers.

I suppose that wickedness reveals itself often in action. Goodness also does, but is on a quieter plane. Good people very often reveal their goodness through the whole of the quiet revelation of their character in the ordinary events of life. I mean, if a good person is being courageous, he’s probably being courageous in facing rather ordinary troubles. If you like: sick children, a sick wife, and uncongenial job. … Goodness is very seldom dramatic, I think. And it is much more easy to write about drama.

Ken Myers included the above excerpt in the fifth episode of the Audition podcast from Mars Hill Audio.

Three books on inequalities

Posted on by John

The classic book on inequalities is Inequalities by Hardy, Littlewood, and Pólya, first published in 1934 (ISBN 0521358809). I’ve mentioned it a few times before. The book is quite thorough. I imagine more people use it as a reference than read it cover to cover.

The Cauchy-Schwarz Master Class by Michael Steele (ISBN 052154677X) is a more recent book on inequalities, published in 2004. The preface explains what the title means by a “master class.”

In the fine arts, a master class is a small class where students and coaches work together to support a high level of technical and creative excellence. This book tries to capture the spirit of a master class while providing coaching for readers who want to refine their skills as solvers of problems, especially those problems dealing with mathematical inequalities.

The Cauchy-Schwarz Master Class book lives up to its stated aim. Reading the book and working through the exercises reminds me of taking music lessons. The emphasis is on learning techniques rather than cataloging specific results.

The final book I’ll mention is When Less is More: Visualizing Basic Inequalities by Claudi Alsina and Roger B. Nelsen (ISBN 0883853426). Like The Cauchy-Schwarz Master Class, this book emphasizes problem solving technique. More specifically, it emphasizes geometric techniques for understanding and proving inequalities. (I’ve written a review of When Less is More, but unfortunately you have to log in as an MAA member to read it.) When Less is More is as concerned with beauty as with truth.

You can tell from the cover art and the architectural allusion in the title that this book cares about aesthetics. Each proof is a polished gem.

Related posts

Low-tech ice cream

Posted on by John

Here’s a simple way to make ice cream.

  1. Fill a quart-sized bag with whole milk, sugar, and vanilla then seal it.
  2. Put the quart-sized bad inside a gallon-sized bag, along with ice and salt.
  3. Seal the outer bag and shake it for five minutes.

Project management tip: destroy any hope

Posted on by John

.NET Rocks episode 438 interviewed Patrick Hynds on why projects fail. One of the reasons is unclear expectations. He said in the interview that no matter what you say you’re going to do on a project, clients have additional implicit expectations. Hynds says that in order to have a successful project, you have to “destroy any hope” that you will deliver anything outside the specification. Here’s an excerpt from the podcast transcript, emphasis added.

… if I give you a spec I’m going to give you everything this document says and nothing more. In other words, if it’s not shown or described in detail in this document, it will not be done. … this is going to cost you X thousand dollars and if you expected something else to be in there, it won’t be. It sounds bad but you have to destroy any hope they have that you’re thinking the way that they’re thinking. …

I mean, in web projects we state explicitly what resolutions we will support and none others. What browser versions we will support and no others, what back-end database versions and libraries we will support and no others, that kind of thing. … I find for everything you say you’re going to do, you have to define one or two things you’re not going to do.

Hynds’ advice may sound adversarial, but everyone is happier in the long run when there are clear expectations up front.

Here’s another good quote from Hynds later in the interview.

There’s always someone out there willing to bid less to do a bad job.

Related posts