E-Prime For Software Engineers

I recently restarted reading Quantum Psychology by Robert Anton Wilson. (Not the easiest read. If you put it down for to long you may have to start over.) The most practical thing I’ve gotten from it thus far is the usefulness of E-Prime. You may already use it and not realize it.

To attempt to summarize E-Prime with a single example, consider the following two statements..

  1. Alice’s code is broken.
  2. When I ran the unit tests this morning, all the code last checked in by Alice (according to the logs) failed to pass. Thus, I think her code is broken.

While the first statement is concise, I’d much rather prefer the second because it conveys information about the observer in addition to the observation.

  • The means of measuring brokenness are specified (“the unit tests”). The reader otherwise does not know how the conclusion of brokenness is being determined. Without this information, how is Alice supposed to go about reproducing the issue?
  • A timeframe of failure is specified (“this morning”). Alice may have made the same observation and made fixes shortly after the unit tests were run. The code may have indeed been broken, but only appeared so at the time it was measured.
  • The observations is attributed to the observer (“[w]hen I ran”, “I think”), rather than claiming the an intrinsic state of brokenness about the code.
  • The scope of the brokenness is described (“all the code last checked in by Alice”). All of Alice’s code probably isn’t broken.
  • It is acknoledges that the observation is limited by the means of measurement (“Thus, I think..”). When judged by another means, the code may appear fine.

In short, E-Prime acknoledges that our capabilities or understanding seem to be limited by our instruments of perception (be them eyes, ears, unit tests or ampmeters). Take a looksy at some other examples.