Catalog engineering and reverse engineering

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.