When you code, do you know your Master(s)?

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.

Bag-o-Tricks Christmas Edition

Here's a token gift from me to you. An update to the bag-o-tricks. No earth-shattering features, but a bunch of clean-up. I've made everything work under VS 2008 and rolled up a bunch of common files under a 'common' assembly.

I've renamed the assemblies so it's easy to keep track of what comes from me--everything starts with J832.

I've also done some tweaking so that, by default, images are picked up from the users image folder on XP. You can still override this with a command line parameter.

As I hinted to with my post about TortoiseSVN, I've also put all of my code up on an SVN share: j832.com/PublicSoftware.

I'll try to make sure that the bits I check-in are at least building, but no promises. If you want to fix any bugs and send me the patch, I'd love to try it out. Promise that it's your own code and that you're willing to license your work under the MIT License. You can find my email address on my blog.

Happy hacking and happy holidays!

TortoiseSVN Rocks!

Yes, I'm considering writing a book: "Kevin Explores Things That Rock".

My company uses Perforce for source control. It works pretty well (although there is no shell integration and the Visual Studio integration is a bit flaky.)

I have my own projects on the side that I'd like to managed with source control. These are both code projects and non-code (poetry, screen plays, other writing) projects. Like I said, anything that I want backed-up, synced and versioned.

If you're like me, you share a set of conflicting tendencies.

• First, a tendency to have many machines that you work on.
• Second, a tendency to be paranoid about keeping important data backed-up and protected with good redundancy.
• Third, a tendency to hate redundancy! This goes along with SPOT. I hate when things get out of sync. I hate having things spread all over a bunch of machines.

Using a source control system helps a lot with this (especially if you're dealing with text-based data formats).

In the world of OSS, Subversion (SVN) is a big player in source management. It's supported by SourceForge. It's used by a mountain of OSS projects. And (drum roll) it has an amazing Windows shell extension: Tortoise.

• Step one: install.
• Step two: make directory somewhere on your machine.
• Step three: right-click and pick "SVN Checkout..."
• Step four: type in the URL of a public SVN repository. There are many out there. Check the list above.
• Step five: laugh at how easy it all is.

Tortoise supports the creation of patches. Renaming and branching. It even has great shell indicators so you know what's checked-in and what's pending check-in. (It works great on XP. So-so on Vista.)

Take a look at TortoiseSVN.

If you're looking for hosting for your SVN repository, check out DreamHost.

Happy Hacking...and don't forget to build an test before you check-in. :-)

DreamHost Rocks!

I've been all over the map with hosting services. Each has it's own cool features and things that are annoying.

I've finally found one that (almost) has it all: DreamHost.

For $10 a month (paid yearly):

• 5120 GB per month bandwidth. No, that is not a miss-type. Put another way: 5.120 TB a month. (Now, being realistic, the box it's hosted on would probably melt before you hit that mark. It's almost like offering 50,000 minutes on a cell phone plan when there's only 44,640 minutes in a month. But at least you won't get charged for a Digg hit or something.)
• 500 GB of storage. Again, not a typo. 0.5 TB.
• As many domains as you want. You have to buy the domain names, but you can host 'em all on one account.
• As many MySQL databases as you want. Size comes out of your 500 GB of storage so make 'em as big as you want.
• Shell access. We're talkin' SSH. (Well, if I could figure out the damn certificate thingy.) I'm using 'ln -s' to create symbolic links for the first time in 6 years. Reminds me of college...
• The deal-maker: SVN. For those that don't mind (or prefer) OSS source control, this is it. I use it for all of my code and personal writing--all things I want to backup, sync reliably across machines, and keep version history on. I'll post later on my love of Tortoise.
• Oh, and they're carbon neutral. It's almost silly.

I said almost above. What's the catch?

Well, there's not a huge number of easy-to-install software packages. They don't use cPanel/Fantastico like a lot of Linux hosting shops. The interface they do provide is very clean and one can manually install most things, but it's kinda nice to do a click-and-install for Drupal.

That's my only nit, actually. Everything is super fast. I'm super happy.

Check 'em out.

But Kevin, this is a Linux hosting package. Where's the Windows Server 2008 package?

Sigh. The world is so much larger than the Microsoft stack of technologies. I love VS as much as anyone, but getting a broad skill set is important, right? Plus the OSS web community is insanely strong. The content, energy and enthusiasm are amazing.

Full disclosure: Yes, the links provided are for a referral program. Yes, I get a kick-back if you sign-up. No, I would never pitch anything just for the kick-back.

I've had plenty of services offer kick-backs that I blinked at--that I never felt strongly about. This is proof I have no subtext. These guys are that good.

In search of DRY SPOT

I realized there is a concept I come back to often in a lot of my software implementation and in a lot of my discussions. It goes by two common acronyms that are pretty much interchangeable.

DRY: Don't Repeat Yourself.
SPOT: Single Point of Truth.

DRY is articulated in the book The Pragmatic Programmer, although Eric Raymond likes to call it SPOT.

How does this exist in our world of C# and .NET? Well, every time you define a private const string or private const int instead of sprinkling magic values all over your code, every time you generate documentation from your source files, every time you develop a clever data structure to represent both the execution and the description of a process, you are practicing SPOT.

Quite often, my SPOT will live in a static class Util that I create for almost all of my software projects. If I have one way to handle errors, one pay to deal with collection, one way to handle user input, centralizing it makes bug fixing so much easier. It actually minimizes bugs in a lot of cases, which minimizes the need to fix them.

If you haven't heard of these concepts, they are great to add to your software vocabulary.

For many, I'm sure the idea has always been floating around, just without a good name.

Now you have a good shorthand when you are mocking someone else's code.

Happy hacking!