Blue Collar Software Development

Jeff Atwood

10 Dec 2004 — 2 min read — Comments

There’s a provocative editorial on the “Academication” of software development at DevX:

Software development is not an academic exercise. It has more in common with the blue-collar “build me a house” ethic than it does with ivory tower research. So let’s quit treating it as if it’s university research. It’s not. Define, design, build, test, deploy – that’s what we do. Deliver code that does what the end users of the code need or want. No more, no less.

From Web sites to database applications to games, it’s all about what your code will do for the end user and not about how you did it. Your end users don’t care if you used a Booch diagram or anointed blocks with arrows and written descriptions to communicate to the development team how you were going to build the software. They care only that the software works the way they expect it to.

As an aspiring architect, I tend to agree. It takes a good developer to make a good architect. Never forget that you’re a developer first and an architect second. Forget the ten dollar acronyms and fancy diagrams. Gather feedback from the developers doing the work to determine if your designs are working. Throughout the project, you should continually ask yourself:

Do I have difficulty explaining my design to other developers? When I explain it, do I get the feeling that they are just nodding along to be polite, or do I get a palpable sense of engagement, that my ideas click with them?
Do I make a lot of excuses during the explanations? I wanted to do it this way, but... I know it seems complicated, but... in the next version we’ll improve that...
Do developers tend to write code that fits well with this design? Or do they keep “getting it wrong” and forcing me to intervene?
Am I getting a lot of questions about this design? For things that I consider simple and straightforward?

A software architecture isn’t automatically good just because it came from a $45 book on Amazon. A software architecture is good when – with a little education – it fits the developer’s mental model of the way things should work and it makes them more productive. If your architecture is screwed up, believe me, you don’t need a book to find that out. Just pay attention to the warning signs from your co-workers.

I do agree that patterns are useful as a standard part of our design vocabulary:

The names of patterns give us a lexicon by which we can talk to each other about the arrangement and interaction of components, especially for those arrangements and interactions that we’re likely to encounter again and again. Once again, the onus is on the organization to ensure that there is a standard for pattern names and that the developers in the organization know that standard. Besides, if you’re a professional programmer working in any of the mainstream OO Programming languages, you should be worried if you’re stumped by “Decorator.” In such a case, high-tail it to Amazon or your local bookstore and pick up a copy of Head First Design Patterns.

Patterns are an important part of the continuing evolution of software development. But don’t be a slave to the patterns, either.

What does Stack Overflow want to be when it grows up?

I sometimes get asked by regular people in the actual real world what it is that I do for a living, and here’s my 15 second answer: We built a sort of Wikipedia website for computer programmers to post questions and answers. It’s called Stack Overflow. As of

Civilized Discourse Construction Kit

Occasionally, startups will ask me for advice. That's a shame, because I am a terrible person to ask for advice. The conversation usually goes something like this: We'd love to get your expert advice on our thing. I probably don't use your thing. Even

How to Stop Sucking and Be Awesome Instead

I've been fortunate to have some measure of success in my life, primarily through this very blog over the last eight years, and in creating Stack Overflow and Stack Exchange over the last four years. With the birth of our twin girls, I've had a few

Books: Bits vs. Atoms

I adore words, but let's face it: books suck. More specifically, so many beautiful ideas have been helplessly trapped in physical made-of-atoms books for the last few centuries. How do books suck? Let me count the ways: * They are heavy. * They take up too much space. * They have