Poser I thought I'd take a shot at introducing myself here as suggested by Jay and maybe dispel any pretense at being a thinker, heady or no. Frankly, it's probably long past time that I put together some kind of background post about myself if only to give those who disagree with me a way to discount my arguments out of hand.

I suspect this'll be long as I do go on sometimes. You can skip to a recent, similar post if you only want the heart of my current situation.

Street Cred

I've been playing with computers in one way or another since my fifth grade class acquired a then-new PET computer (I recognize the CBM Model 4032 from that link as the one we had). I think it had 8k RAM and we saved and loaded our programs using cassette tapes. I bought my own used Atari 800XL from hard-earned savings as a young teen and have owned a personal computer of some sort continually ever since (frankly, the Atari made it all the way to my Sophomore year of college when PC-envy finally became overwhelming).

It didn't occur to me to take computers seriously as a career until after I graduated college, though. That's right, I went through college working in the computer center and making money on the side setting up personal computers and local networks for small-companies and individuals without realizing that I could actually major in them. The one intro to programming class I took (which I remember was Pascal-based) was so easy (if only from familiarity and years of being a computer geek) that I treated it as a study hall.

After graduation, I discovered that my computer skills were worth more on the market than anything I'd actually studied so that's what I did. This was the mid 1990s so mildly talented lighting fixtures could find programming jobs. Kind of like the mid 2000s, really.

Jacking a Career

I started my actual, salaried career working for a couple of vertical market software vendors who dominated their respective niches by using Pick (which had it all over those stuffy relational databases for the ability to map real-world information). It was with Pick Basic that I discovered the true meaning of Spaghetti Code. With great power comes great responsibility and with great responsibility comes the opportunity to make very large mistakes (none of them mine, of course).

Which means that Visual Basic 6 was an upgrade in sophistication for me. Fortunately, I learn fast—my single greatest career asset. When Visual Studio and the .Net framework came around, I was all over that in turn.

I started my own company with a very talented developer and friend in early 2000 serving the Multi-level Marketing vertical market providing independent compensation programming. If you've ever been in one of those presentations where they describe how you can earn money from the sales of people you recruit and they mention "levels" or "generations" you've pretty much seen the the design documents I was given. Ever wonder how those were programmed? I did, too. I'll just say here that walking a tree with money on the line is an addictive form of adrenaline.

It's a small and competitive niche, though, so it was only really viable while the market was booming. Also, it turns out that I had a lot to learn about marketing and sales.

Developer In Da House

Since then, I've been an in-house developer and/or development manager for various small to medium-sized companies. I've learned enough about how businesses operate to be a good interface to upper management (I can speak all the relevant dialects including accounting, sales, management, and operations) and I work in the trenches enough to not have completely lost the respect of actual developers.

My current position is with a small reading-glasses wholesaler where I am the development department. We're relatively top-heavy in the IT department than you would think we need, but that's because the company's value-add in the marketplace is our ability to orchestrate complex vendor interactions (with up to 120 day lead-times) to provide a flexible product-line at a high-enough volume to satisfy our retailers.

I also contribute to a couple of open source and volunteer projects, the most notable being Subtext. I feel guilty about bringing that one up, though, because it's been months since I've done anything helpful there.

My Hood

Since my in-house projects are small and self-contained, I tend not to use many formal development processes. My users are all within fifty feet of me and I've trained them not to hesitate in letting me know when something goes wrong or when they think of a better way to do something. If you're doing things right in the first place, this isn't really as disruptive as you'd think. My longest project in the last two years has taken less than a month to go from the start of development to deployment. Some of that is because I am just that good, but a lot of it is that we're not doing anything that complex. It's a sweet-spot, I admit.

All of which makes any formal development process so much overkill.

Flashing it Hardcore

I've been around long enough to have seen silver bullets come and go. It has gotten to the point where the only dogma that I'll tolerate is anti-dogma. I am a Microsoft fanboi, but that doesn't mean I don't explore other technologies and ideas. I'm not into didacticism of any flavor.

I do have a core set of practices that I tend to use. They each have two criteria:

  • I understand how they work.
  • I've used them and verified that they work as expected.

There's nothing like real-life to expose flawed base assumptions or principles.

As you can see, this tends to make me a process skeptic. I love iterative development because I've used it and seen that it works. I like Agile as an idea and implementation of iterative development, but I've never actually seen it in action so I try to keep my discussions of it on a theoretical level.

I've been known to create and maintain the occasional unit test, but I've found that even that can be overkill on many of my projects. Test Driven Development is interesting and all but I can't really see myself using it. It'd be a pain to retrain my way of thinking and I'm not convinced that the payoff is there (and yeah, I've heard the testimonials). I'm not going to move to an experiment until I understand how the payoff is supposed to come. And with TDD, I just don't see it.

This attitude is what keeps getting me in trouble with the Dependency Injection crowd. I've worked out a specific, relatively narrow set of circumstances where it can be useful, but as I found out when I actually tried to implement it, those circumstances turn out to be extremely rare in an already well-architected solution.

Busting Out

Skepticism aside, software development fascinates me and I truly cannot leave new stuff alone. I echoed a sentiment by Jay Kimble recently that says essentially that claims of universal applicability are always wrong. But there's a flip side I want to acknowledge as well: every process, tool, or technology is useful somewhere.

What that means for me is that every popular tool or technique deserves a fair hearing and an attempt at understanding to see if there is something there that I can use. Rejecting something new merely because it is popular is no better than adopting it for the same reason. I admit that this is a weird blend of skepticism and optimism. That said it turns out that, while uncomfortable, it's really useful for growth as a developer and maintaining the ability to jump into new situations and still find yourself in familiar territory.

Software development is fun and I can't seem to be able to leave it alone. Fortunately, it's a useful addiction—not unlike, say, air. And if you've stuck with me this far, you're obviously interested in it yourself (or you're my wife who reads every post if only because she knows I'll eventually ask her what she thought of it). I hope you'll stick around and join the conversation if so moved, even if only to tell me where you think that I am wrong.