Prefer types over booleans

In a recent post I represented whether a TV was on or off as an enum in Java and case objects in Scala. Someone asked me why you would do either one when you could simply represent it as a boolean.

The same reasoning would seem to extend to any situation with two choices:

  1. Male/Female
  2. On/Off
  3. In/Out
  4. Active/Inactive
  5. Hot/Cold
  6. Light/Dark
  7. etc..

I have a rule:

prefer types over booleans

This post is about why.

Continue reading “Prefer types over booleans”

Somehow this dodo bird seems to be appropriate here...

Are the Best Coders Bad Software Engineers?

Bad software engineers aren’t always obvious. Some of them write bad code but make it look “good” or “brilliant.” Randy McDonald has shared one story that I think is a familiar one to anyone who has been around software awhile:

This contractor was quite brilliant, a coding rock star, everyone was in awe of his skill with the keyboard, and often went and sought his advice for the more esoteric coding problems.

That was the problem, no one on the project felt confident enough to challenge him on his work enough for him to back down…

Now he has left and no one likes going into his code because it is so difficult to understand. I don’t actually know the full story of why he left but I do know his attitude played a part in it.

Continue reading “Are the Best Coders Bad Software Engineers?”

Release as Often as Possible

I have written a short paper – Release Often – about why there is a common theme of fast release cycles in many prominent software movements such as RERO, Lean, XP, DevOps, and Continuous Delivery. There is an accompanying Prezi presentation deck below. I presented the talk at Seattle University this past week in our Software Economics class.

Here is a link to the paper:


And the Prezi: