Recently, I've been thinking about how to keep myself out of trouble with regards to software engineering. I'm a huge fan of greedy algorithms (simple, straightforward), and kind of related, the KISS principle. Don't get me wrong, I can write some crazy complex software, but I'm past the point in my career development where I feel like the complexity of code I write has any relationship to my standing as a software engineer, except perhaps an inverse relationship might exist.
Anyway, while thinking about how I approach software engineering, I've come across these rules which I apply every time I write code.
Rule 0: Performance is king.
If I don't write performant software in the product that I'm supporting, someone in a competing product will. Features matter, but if folks can't actually use my product because it performs too slowly, then eventually, your company will be lost to those whose tools they can use. Say it with me: "Performance Is King".
Rule 1: Existing patterns should not be changed for light or transient causes.
In other words, if I'm new to the project, and I don't like the patterns, don't change them. In fact, my new code should look remarkably similar to the existing code I find. This is to combat a tendency I have to rewrite more than I need to.
Rule 2: Design twice, code once.
This is the rule which keeps good design firmly in place, regardless of development methodology. It doesn't matter if we choose agile, extreme coding, six sigma, whatever new fancy methodology doesn't exist. If our DNA makes us design twice, code once, then we can avoid the problems I describe here.
Rule 3: Don't trust your own code, ever.
I could have named this rule 'test, test, test'. It never fails that I'll get my code to a state where I feel like I'm ready to ship, and I've dotted my 'I's, and crossed my 'T's. Then I'll write a test (if I didn't start with a test, as I sometimes do), and the code immediately explodes. I was writing a multi-threading client that I got to this state, and writing and running tests actually proved that I couldn't kill the threads once I'd spawned them (coded the way I had). It was simple to fix, but it wasn't lost on me that, in production, I would have toppled servers, with no recovery except to restart them, and potentially huge customer implications.
Rule 4: Code simpler.
This requires a little bit of explanation. If you're like me, and wrote a bunch of code, then there's a possibility that it's over-engineered. My next step these days is to consciously review my code, and see what I can remove, or code that I can't really justify. This dovetails nicely with the extreme programming YAGNI principle. This is a reminder to me that when I think it's simple enough, make it simpler still. As a quick aside, patterns are good. I've mentioned this before. The problem with patterns is that they're often pretty robust, and offer a lot of extra stuff just in case. That's another place this helps. Maybe that extra interface isn't necessary- would a regular class work?
Rule 5: Trust other engineers.
This keeps me out of the NIH trap (not invented here). It also means that if I'm writing a class, and have a property (or method), I default to public accessibility, unless there's a solid and compelling reason to be less accessible. This one rule reminds me that even though I've been coding for 20+ years, it's possible that I don't know everything. This is why I attend meetups like the Seattle Scalability Meetup, and other events to chat with other software engineers, and keep an eye on the evolution of software engineering.
These rules are designed to catch personality hangups I have seen in myself, and so may seem mundane to you if you don't have the same personality snafus. I write them down here, so that just in case, maybe, someone else has the same tendencies, and will get some benefit. Happy coding!
