TDD and Me

A lot of folks in the RoR community are into the concept of Test Driven Development. The logic of it makes sense to me, if the implementation doesn't.

Here's the main argument. A guy becomes part of a team. He is a TDD guru or disciple, all about testing. He believes every piece of code written should have a test written for it first. This is the part I can partially get behind, since writing tests makes code easier to handle and understand. So what's the issue?

Basically, it boils down to these words: EVERY PIECE OF CODE WRITTEN. Really? Coverage percentages do not indicate success. As a matter of fact, the only thing they indicate is a frenetic desire to write lots of test code. I feel humbled as a lesser developer when I don't use the TATFT principle. It's a great principle, but when you find your tests extending into scripts 10 times larger than the code, it's time to re-examine what you are doing.

I'd like to work on a concept that is slightly different. This idea is CDD, Customer Driven Development. This is easy to grasp. You will still write tests for you code, it's unavoidable and it should be done, without getting out of hand. The difference is not spending exorbitant amounts of time changing your tests every time a customer changes their whimsical mind. If simple changes break your tests, maybe TDD isn't the best option for you.

That being said, TDD is good, but needs to evolve past the idea of coverage and tests for the sake of tests. Good code is seen with or without them. Is it possible I'm wrong? Absolutely.

I am just waiting for the one thing (and I don't know what that might be) that will turn me into the frenetic Test Guy in the office.

The Culture of Developers

While the world seems to think geek is a single variety, I am noticing more and more the myriad of flavors when it comes to your average developer, their work habits, and work environment. It's easy to see not every workplace is the same for everyone and a buffet style of job site might be the best option any web or software development company can hope for.

So I thought I would jot down a few examples of the different types of developers I've seen over the years. This is not an exhaustive list, but it might give some non-developers a bit of an eye-opener when they realize Programmer is not a "one-size-fits-all" label.

1. The Hacker
   
   This is the guy who wears jeans and t-shirts daily, talks about popular music and style, probably loves the environment and politics, and never seems appropriate in an office setting. More than likely, he goes to extremes, either constantly speaking in techno babble, or calling everything technical by a wrong or simply made up name. He may be awesome at what he does, but then no one really understands what he's doing and his laid back attitude makes it seem like he isn't doing much anyway.




2. The Legacy Coder
   
   This guy or gal knows every ounce of legacy code you have. And they can fix it, so long as it's C, Cobol, Fortran, or some other antiquated language. They like to say things like "normalization" and talk about how stable the dino languages were compared to the new fangled open source stuff of these days. And you'd love to say, "Of course it was stable...it didn't really do much". They are great at keeping the old clients happy, but change is what they fear most.




3. The Rock Star
   
   The rock star and the hacker have a lot in common. The difference being where they rate in the "community". Generally, the rock star has contributed to the big code out there (bug fixes for a linux distro or a new gem for RoR). They go to conferences and groups because people know they are awesome and they like to know that other folks know how awesome they are. A rock star may have even written a book or might have produced a tutorial podcast. Again, great coders to have on your team, especially if you are a start up looking for name recognition.




4. The Coach
   
   The Coach is awesome. He never really gets much done himself, but he knows how to do it and sits on the bench waiting for someone to ask him how something gets done. From code technique to policy, this guy has your back. Since everyone always talks about working on teams, I suppose a coach is necessary.




5. Dudley (or Dudleyette?) Do-right
   
   I am relatively sure every team of considerable size has one of theses. A person who is so intent on good form and what is appropriate, they lose site of the project and simply go on making sure every bit of minutiae is handled. Which generally leaves the big picture wide open for bugs and ambiguities. This person does have a purpose though. They keep the hacker in line and make sure no short-cuts are taken, even if it means missing a deadline.




6. The Midnight Cowboy
   
   Alone in a basement...all you can hear is a frantic tapping of keys and the 1993 album Gish playing quietly in the background. It's 3 AM. Isn't work for work time? Not for the midnight cowboy! Staying up all night coding and designing and too tired during regular work hours to do anything more than function in meetings is the way these modern day cow punchers live. They get it done...the deadlines are met, with a pasty hand stretched out for a high five everytime.

So those are just a few examples of coders I've experienced over the years. Some people are combinations of more than one so every gets to have mutliple personality disorder. But then, isn't re-combination what creativity (and coding is creativity) is all about?