There are a whole set of blog posts floating around my head. Discussions of immutability, pre-condition checking, etc. I realized I needed to cover a meta-topic first: the notion of "masters" while programming.

This is a concept I think everyone has, but for most, it remains fuzzy, undefined and un-discussed--which is fine, if you work by yourself.

As I've dived into the software engineering role in the last few months, I've been required to justify my implementation decisions and opinions with co-workers. Given the seemingly limitless ways in which one could solve a given problem with a file full of curly braces and semi-colons, why did I choose the approach I did? Why do I want to change a bunch of existing code? Why am I asking my colleagues to change how they write software?

When it's a simple matter of "does it work or not" there isn't much of a problem, but as many know, writing solid code goes well beyond getting things to build and run.

So, what drives how you write software? When you are at a cross roads (with a co-worker or even with yourself) about how to approach implementation, what guides your discussion? These are your masters.

Examples:

• Minimize code size
• Minimize code complexity
• Minimize unnecessary code churn
• Maximize code readability
• Maximize correctness
• Maximize robustness
• Maximize flexibility
• Maximize code maintainability
• Maximize CPU performance characteristics
• Maximize Memory performance characteristics
• Maximize API ease-of-use
• Maximize the chance another dev will use an API correctly (see Pit of Success)
• Opt for immutable data structures
• Opt for thread-safe data structures and APIs
• Verify pre-conditions
• Follow design guidelines
• Get it done yesterday!

And none of these have anything to do with solving the problem at hand. They are, for lack of a better term, taxes. Well, except for get it done yesterday.

Some observations:

1) Many (Most? All?) of the masters conflict with at least one other master. CPU vs Memory performance is a trade off for many algorithms. Performance optimizations often hurt code readability. API ease-of-use often bumps up against immutability and thread safety. Therefor...

2) Context really matters. This is an important point to bring up when discussing with co-workers. In this situation, which master is most important?

3) When making your case in a disagreement, make it in terms of the masters you are prioritizing in a given situation. If someone doesn't understand the importance of--say--immutability, you'd better be able to articulate it.

4) Speaking in terms of masters makes everyone a lot more sane. How often have implementation discussions turned into irrational arguments? Using a master-focused format, I've found disagreements turn into pretty simple cases of a disagreement about the relative importance of two masters. Other times, it's a matter of agreeing on an exception to general rule. "While in general, Master A is more important than Master B, in this situation, we should prioritize B because of X, Y, Z..."

5) "Fake" masters get exposed--vices wearing the mask of a real master. This is amazingly important, too. Lazy often wears the mask of code size or get it done yesterday. Clever often wears the guise of unnecessary flexibility or performance improvements, while increasing code complexity and decreasing code readability. (I'm often guilty of this.)

So...

Next time you are struggling with several valid ways to implement something, make the mental check-list: what masters am I serving with each implementation? What masters are really important in this situation?

Next time you disagree with a co-worker about an implementation, ask yourself: what masters is she arguing for? What masters am I arguing for? What masters really matter? Maybe step back a bit and talk through your respective masters and make sure you both understand before you dig in.

Next time you are trying to get it done yesterday, ask yourself: am I just being lazy? :-)

Happy hacking...

Note 1: Huge props to my co-worker, David Potter. A more brilliant, friendly, and fun colleagues I could not ask for. We've been using this master-focused mind set for weeks now and it makes collaborating a blast.

Note 2: I always get a little nervous posting these long, pseudo-philosophical rants with no source code. As always, if you write a comment saying you read this far (and you don't think I'm crazy) you'll make my day.