Categories
Projects

The “Reverse King Stahlman Method” in Writing Software

If you are from Southern California you’re likely familiar with the slogan from King Stahlman’s Bail Bonds:

“Better have me and not need me, than need me and not have me “

– Any book of matches

This phrase has many applications in life, but its very important not to use it when writing software. In fact, its better to not have anything in your code you don’t need right now.

I’m sorry to make you throw away your beautiful code, but until its serving a purpose, its vestigial. You should always use the reverse King Stahlman method:

“Better to need me and not have me, than have me and not need me”.

Writing code that isn’t useful today will lead to the following problems, even if you’re pretty sure the code will be needed:

  • Rigidity – Your code is now more difficult to refactor and less portable because there are additional methods or logic you need to continue to support (can’t let those unit tests fail!)
  • More test time – If you’re writing code you should be writing tests. Now you have to write tests for code that currently has no value. Those tests also take precious time on every build/deploy/etc.
  • Confusing code – The less stuff you have in your code, the easier it is to read and understand. For this reason alone you should remove anything in your code that isn’t being used. Also, when you have functions that are never called, its difficult to understand their purpose.

Reverse King Stahlman’s Exception

You can’t be dogmatic about any rules in writing software. JLAM (just like anything, man). So, you know, there are going to be some times when its okay to write some piece of code that is going to get used in the epic or series of stories you’re currently working on. There might be cases where adding something now can save you hours of work down the road. In those cases you can safely ignore the Reverse King Stahlman Method.

3 replies on “The “Reverse King Stahlman Method” in Writing Software”

What if i throw away existing ugly code, and then build a superset of functionality that isn’t all needed at the current time?

Leave a Reply

Your email address will not be published.