Best essays on software

Are you interested in reading quality essays on subjects related to software development? If so, then treat yourself to Neil Kandalgaonkar’s Links to essays in the book Best Software Writing I, or buy the hardcopy.

In the interest of letting people get to the links quickly, I’m copying-and-pasting Neil Kandalgaonkar’s links:


Joel Spolsky – Introduction

Refactoring Rules

Tried-and-true refactoring rules:

  1. Find the smallest change that could possibly work, and check it in. “If I make this change, it will change nothing else.”
  2. Revert early, and revert often. If you lose a half-day of work because the refactoring change is too large, that’s okay. Better to start over than to cost the rest of the team precious time struggling with a broken build.
  3. Do not write new code while refactoring.
  4. Always use cut-and-paste, never copy-and-paste.
  5. Just because the unit tests pass, doesn’t mean that the product still works after your refactor. You may need to add new unit tests before you refactor. And you may need to do some acceptance-testing for things that aren’t unit-testable.

General Advice:

  1. Don’t checkin changes to the version control system just before you go home. Wait for the next day.

Types of Refactoring:

  1. Refer to Martin Fowler’s “Refactoring” book
  2. Refer to Fowler’s website: http://www.refactoring.com/ and his catalog of refactorings

Is open source software sustainable?

Recently, a genuinely concerned coworker expressed concern that “not paying for software [may] ultimately kill the industry” because it encourages people expect something for nothing.

For those who would like this and other common concerns about open software answered, I recommend reading Open Source-onomics. Here’s a list of concerns it addresses:

  • “Open Source is not economically viable”
  • “Not paying for software will ultimately kill the industry”
  • “Why will programmers continue to contribute code if they can’t make money from it?”
  • “Even Open Source development involves effort, so there has to be payment for that effort”
  • “Are Open Source programmers writing themselves out of their jobs?”
  • “But free isn’t natural. There’s no such thing as a free lunch.”
  • “Is software a commodity?”
  • “Who will invest in software development if it doesn’t yield a return?”
  • “Open Source may have a niche, but proprietary commercial products will continue to rule”
  • “Customers will never trust something that is free”
  • “Open Source may release value, but it doesn’t create value”

For those who would like even more detailed reading, I recommend David Wheeler’s “Why Open Source Software? Look at the numbers!

Refactoring C++ with Ref++

IntelliJ IDEA has world-class refactoring support for Java. I’ve never seen a good tool for refactoring C++ code, until now: Ref++ for Visual Studio 2003 and 2005. Admittedly, it isn’t nearly as good as the refactoring tools available for Java code, but it’s a start, and Ref++ saves time.

Subversion and file properties

It’s nice to have proper line-endings on various operating systems when files are retrieved from a Subversion repository. It doesn’t happen automatically unless users configure their client-side settings. You can download a sample config file that shows how I do it. When properties need to be set on files already submitted, it’s nice to have an automated way to do it. I wrote a script, svn-propset.sh, to set the properties. Maybe someone else has done this too.

Run time linker and library symbols

Did you know that almost all programs are incomplete until you start them? When programmers compile a program, it is only partially complete. When you start a program, the operating system looks at the program and runs another program to make it complete — called a run time linker. In the case of modern Linux, it’s usually /lib/ld-linux.so.2. Read the manpage on ‘ld.so‘ for more information.

  • You can find out what libraries your program uses with ldd /path/to/program. You can also run it as follows (assuming you’re using bash/ksh/zsh): LD_DEBUG=files program
  • Find out what symbols a program uses and from which shared libraries: LD_DEBUG=bindings program
  • Have you ever wanted to find out what shared library contains the code or definition for a function or symbol? David Wheeler shows how you can find it: nm -o /lib/* /usr/lib/*/* | grep symbol_name Then look for the capital “T”. Read the Program Library HOWTO by David Wheeler.