I knew a police officer who I thought was not a particularly “good driver”, although he thought he was. Since he had passed the EVOC course at the academy with flying colors, he thought that is what made him a good driver (excellent driver, in his words!). Meanwhile, if you were driving behind him, he never used a blinker, wouldn’t turn on his headlights until it was dark out (not during twilight), he’d pull out in front of you, etc. So what is that discrepancy? Why are there two opinions over the same reality?
Well, there is the one mindset that “a good driver is someone who can handle emergency/technical situations” versus “a good driver is someone who communicates well and integrates with the surrounding drivers, in a safe way”. Put another way it’s: “someone who is technical” vs “someone who integrates better”.
In the same way, there are two mindsets with developers of what it means to be a “good developer”. There is the: “a good coder can do the most clever, technical things possible” versus “a good coder makes choices that are ‘good for the codebase’, and writes code that other developers can adapt to easily”.
I’m a believer in the latter.
I have had the very fortunate opportunity to work for a large organization (40,000+ employees) for the past 4.5 years. Our group is responsible for researching and publishing best-practices, for the .NET technology, for the enterprise. That is around 800 .NET developers. One the most educational aspects of my job, is the amount of code I’m exposed to. In our VB6 to .NET conversion, as well as our prep for Vista and Windows 7, our group has done hundreds of code reviews. Code reviews for everything from batch, windows services, desktop apps, ASP.NET apps, and in C# or VB.NET. It is amazing what you learn from seeing code from so many other developers! It’s the most accelerated and potent way to learn about programming approaches (good and bad), that I know.
Naturally, we all have our own preferences and may think “I would’ve done this differently”, but many times I’ve run across good code and thought “wow, I wouldn’t have thought of that!” – either way, it’s educational for sure! Another aspect though of these code reviews, is that “we” (the other members of my group) found some code that was consistently harder to understand, more difficult to follow, and unreasonable to debug.
Now, before we go any further, what does this mean? What are the implications of this? I am a “somewhat” seasoned developer (~16 years of coding), and I’m struggling a lot with code that I’m looking at. This means:
- Costs more: It’s going to be difficult for other developers to roll onto the project. This means this codebase is going to be more expensive to maintain, and will take longer to bring new releases to market. So this code is going to take longer and cost more money.
- Less agile: I’m not talking about Agile here, I’m talking about code that is written in a way where the development team can respond to the business and quickly turn around new changes to the software that add value to the business. With difficult code, this will be harder to do, and will be more expensive.
OK, so if we can agree that code that was difficult to understand and debug is “more expensive” and “not ideal”, let’s look into the “why”. Why was this code difficult to work with? Generally, it comes down to a few main things (from my experience):
- Naming standards: most developers have now adopted the teachings of the Abrams and Cwalina in Framework Design Guidelines and the use of camelCase and PascalCase. Mostly, it seems that Hungarian notation seems to mostly be on the decline. However, when developers still use Hungarian, it can really be difficult. For example, if you have a variable named dstCtdrs, that doesn’t help me – in fact, it requires extra brainpower for me to try to remember that name, and I still don’t even know what that is. If that is a “dataset of customer detail recordset”, then maybe call if “customerDetails”. Even though it would seem that something like naming standards is simply personal preference, I would argue that this can be a big help or hindrance in understanding code. If you don’t believe me, run your code through Dotfuscator. You’ll find names are more important than you may have thought. If the naming standard doesn’t mean anything then you can read through Dotfuscated code, just as quickly – right?
- Clever code or “lazy” code: there is a whirlwind programming fad at the moment around dynamic typing, abuse of anonymous delegates, and the like. You’ll often hear fans of Ruby say that you “don’t have to” declare a type. “Just because you don’t have to, doesn’t mean you shouldn’t!”. Whom does this benefit? The compiler? The end-user? The future developer that will work on this code? Or….. you? Most people don’t stop to ask that question. Unfortunately, it’s the most important question of all! Unless you own your own company, the code you write isn’t yours. You’re contributing to the codebase of the company. I would argue that taking shortcuts like dynamic (or weak-typing) isn’t helpful for anyone, except the developer writing the code. In fact, that often hurts the codebase because you, and future developers will have more run-time errors (because the compiler can’t enforce your typing in some cases), and it will be more difficult to debug.
I’ve already talked about my case against the “var” keyword. My issue is that the fad of weak-typing is being made vocal by people who I don’t think (and I hope are not), professional developers. The problem is, professional developers start taking this advice as if it’s legitimate! So, I’m writing my opinion on this so that there is some opposing propaganda on the Interweb.
For what it’s worth, I am a professional developer. I have been for a long time, and this is my professional opinion on the matter. So regardless of the blog posts or tweets you may read, Ruby will likely not take over the world, and if you are doing development as a profession, declare your variables. Not for you. Not for the compiler (well, sometimes) – but do it for the poor jerk who is going to have to support your code when you leave the company. And consider that your code will live on for years after you leave. I’m arguing that the professional thing to do is to write proper code that is maintainable and intuitive. That is more valuable than clever code.
Ruby and the weak/dynamic typing has it’s place, and go have fun with it on your personal website. But for professional applications, you’re just undermining your own codebase. At least, in my humble opinion.