Super-Agile or Cowboy-Coding?

This is not one of my normal "hey, I found an obscure .NET thing" kind of posts. This is a brain-dump of something I've been thinking about for a while.

A few months ago, there was a bit of discussion on the 'ol blog-o-sphere. Somebody said something about "shipping is a feature" and somebody else said something about "cowboy coding". If you missed it, no big deal; it's the old how much design is the right amount debate. Earlier this week at lunch, I was reading a magazine article where the author made the implicit assumption that coupling is bad, and that prompted this blog post.

To summarize, there are two extreme positions in the argument. Some people push towards perfect designs: there's no coupling, everything is interface-based, every class has high cohesion, and it's documented completely. Other people push towards a working product: something that actually ships, works, has all the expected features, and generates income for the company.

It's an interesting read, but I take a moderate position. I've been pushed both ways in my career: one time I was told to remove the dependency on the Dependency Injection component (just in case we decided to change to a different DI component); another time I was told to just "make it work, and fast" (due to an unethical coworker, the project was dumped on me with no code two weeks after the contracted ship date). I can say from experience: neither extreme is pretty.

Coding with Engineers

I must say, I really enjoy my new job. I'm back at a small engineering company, where everyone you meet is an engineer of some kind. [Even the guy in charge of the network is an ME; and I don't mean an IT guy with an ME degree - I mean an ME who just does the IT stuff in his spare time]. I'm now in my 8th year working at an engineering shop, and let me say that it takes a special kind of programmer to work in this kind of environment.

Engineering companies (at least the small ones in Northern Michigan) don't really know how to do software. After all, that's what programmers are for, right? If they don't know how to do software, who would? Programming positions in engineering shops end up being of the "sink or swim" variety; you either know what you're doing and excel, or don't and are let go.

There is a distinction between good programmers and great programmers; based on my experience, great programmers are between 5 and 12 times more productive than good programmers. Engineering shops cannot afford to hire an entire division of programmers and let them all "balance each other out;" they can only afford to hire the great programmers.

Aside - What Makes a Naturally Great Programmer?

I remember reading the Hacker HOWTO years ago and realizing how true it was; there are a few things mentioned in that article as being common among naturally great programmers. I repeat the ones I've found most accurate:

• "Learn to write your native language well." It is almost always the case that people who spell correctly, capitalize correctly, and use proper grammar also are great programmers. Similarly, it is almost always true that bad spellers, inconsistent capitalizers, and abusers of sentence structure produce worse code.
• "Train in a martial-arts form." The great programmer seems drawn to martial arts of some kind, especially "those which emphasize mental discipline, relaxed awareness, and control". It's been a few years since I've done Tae Kwon Do, but I still enjoy running through my exercises from time to time.
• "Develop an analytical ear for music... Learn to play some musical instrument well, or how to sing." Again, there is an eerie correlation between good programmers and musical abilities; I myself play the violin and sing (getting into barbershop recently).
• "Develop your appreciation of puns and wordplay." Great programmers do seem to enjoy these types of amusements. This is the reason why a lot of programmers have a dry sense of humor; they prefer jokes that require some thought. One of my favorite books is Pride and Prejudice, simply because of Mr. Bennet's statements.

It is rather strange that all these things show up so commonly among the greatest programmers. The Hacker HOWTO postulates a reason, with which I agree wholeheartedly: "they're connected with a mix of left- and right-brain skills that seems to be important; hackers need to be able to both reason logically and step outside the apparent logic of a problem at a moment's notice." I've taken several "measure your brain" tests, and every single one shows a perfectly equal balance; I am neither right-brained nor left-brained. Furthermore, I believe that this is important in being a naturally great programmer: it's possible to break down larger problems into small steps and be very detail-oriented, and it's possible to make the intuitive leaps into new algorithms - at the same time.

For the record, I do believe that a good programmer may learn to become a great programmer. The previous few paragraphs are only discussing common traits of naturally great programmers.

Back to the Engineer Shop

As mentioned, engineer shops cannot afford a software division. If the truth were told, a lot of software methodologies are designed around "balancing" the good and great programmers; there's a constant training of the good programmers and a "holding back" of the great programmers (e.g., by putting off changes until everyone understands them, or just rejecting such changes).

Engineer shops follow a different principle: only hire the great programmers. Usually, there is a probation period that lasts several months, during which time the other engineers determine whether you are a good programmer or a great programmer. At the end of that time, if you don't make the cut, you are shown the door. That might sound harsh, but we are talking about small engineer shops in Northern Michigan here; it's a simple matter of the survival of the company.

In order to make the cut at an engineer shop, each and every prospective programmer must be:

• Motivated - you've got to be self-starting. There is always more work to do, and sometimes you won't have any work assigned. It is up to you to find the work that needs doing and "task it to yourself".
• Able to communicate - part of self-starting is proactively gathering requirements. In an engineering shop, there are no market analysts, designers, or architects. Alternatively, one could say that every programmer is a market analyst, designer, and architect. It's normal for a single programmer to be responsible for gathering requirements, designing, implementing, testing, and supporting (in the field) the software.
• Always learning - no one trains you; there is no programmer with enough time to teach you to be a programmer. Engineering shops generally do not pay for software conferences or seminars. They will provide you the Internet; it is up to you to keep your skills up-to-date.
• Conservative - the decision of when to jump on new technology falls on you; if you jump too soon, you can seriously impact the success of the entire company. In most engineering shops, there's a kind of informal consensus for big decisions; but if everyone knows you championed the MegaFrizzle Software Development Paradigm that just impacted everyone's bottom line, you don't last long.
• Experienced - to make the correct design and architectural decisions, you must be experienced both deeply and widely. "Deep" experience is more than writing some test programs; it's knowing the limitations of an approach by having felt them. "Wide" experience is necessary as well, so that you may choose the best path. I've utilized object-oriented, generic, procedural, and functional designs in various projects, and none of them is inherently better than another.

There are a couple of advantages of being a programmer in an engineer shop:

• Empowerment - we know the true meaning of the word. We have true empowerment.
• Left alone (mostly) - the only people we really have to talk to are all really smart. All the people we work on a day-to-day basis are engineers (even our customer contacts). The data-to-noise ratio of conversations has a high average. :)

However, there are a few disadvantages of being a programmer in an engineer shop, especially in Northern Michigan:

• Difficult to use social programming techniques - in my current job I'm the only .NET programmer. What's even more scary, I've never met anyone in my life who has ever done pair programming or a design or code review. It can be difficult to get others to participate in user "stories". There's a lot of work being done now exploring this kind of "social programming", which is near impossible for us.
• Pressure - we have to stay the best, not just be the best once or twice. This is not so much a risk of losing our jobs, but it's a weight to have that much of the company's success riding on our decisions.

Conclusion

Each engineering programmer stands or falls on their own, with a tremendous amount of autonomy. We almost have too much empowerment...

This brings up the question that started this blog post: Am I "Super-Agile" or just a "Cowboy Coder"?

I don't know the answer, but I'm interested in knowing. If I ever find out, I'll post the results. :)