Yesterday I was talking to a more experienced developer, who at one point in the conversation commented that I had impressive technical knowledge and skill but that I was not utilizing good practices like what I’ve been learning at CMU. He was totally right.
I think from the fact that my two years’ professional experience is at a tiny company with no methodology to speak of—obviously, with only four developers, I am at least like 25% responsible for this; but hey, I was the last to join which makes me the newcomer—I am actually fighting an uphill battle trying to overcome the bad habits from which my employer suffers and incorporate solid principles like TDD (probably the single easiest agile practice for a single developer to adopt without relying on his or her team/company to make larger procedural changes) into my own work.
Wow, that sentence didn’t seem so ridiculously long when I wrote it. Oh well…
To give you an idea what I’m talking about, let’s put TDD and agile practices in the corner for a second and talk about the Joel Test. This is a fairly well-known list of characteristics proposed by Joel Spolsky (one of the co-founders of Stack Overflow) as a way of determining how healthy a software development team’s process is. Here are the 12 characteristics:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Not to bash my company (you’ve never heard of them, so it would be pointless anyway); but just to give you an idea: our score on the Joel Test would be 2. (The points in green above are the only ones on which we pass.) This is my first professional environment; it’s what I’ve been raised on. So learning agile and TDD, continuous integration, pair programming, etc. at school is incredibly intriguing, but at the same time difficult for me to fully realize or embrace myself.
To be clear: I realize that agile development and the Joel Test are largely unrelated. But they both pertain to good practices, and my point is that at the company where I’ve worked my entire professional life (the last two years), we don’t have any practices at all. Just: here’s a feature we need, code it as quickly as possible, deploy it, and then we’ll see if it works. Then we’ll move on to the next feature, regardless of whether or not there are any bugs in the one that just got added. (I’m exaggerating, of course; but this isn’t as far from the truth as you might think.)
But that conversation yesterday has definitely convinced me to take this a little more seriously. I think it was just the kick in the pants I needed to remind me that learning by doing is really the best way to pick up new ideas. So I need to apply my lessons from school to, if not work*, at least my personal projects.
First order of business: I am not adding anything to Tao.NET until I’ve gotten unit tests for everything in the library. This will be annoying, yes. But once that’s done I will continue development on the library strictly using TDD. It goes against my bad habits—and that’s precisely the point.
*Unfortunately, the culture at work is so fixed and inflexible as to be very difficult to change. I do intend to slowly introduce better practices, but first what I’m doing is trying to get some basic tools in place—for instance, I have just recently introduced a bug/issue tracking database, Redmine, which currently nobody uses other than me—so that we can have a better foundation from which to undergo a paradigm shift.