(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Wednesday, June 15, 2005
  Working code attracts people who want to code

Charles Miller made a profound observation:
Working code attracts people who want to code. Design documents attract people who want to talk about coding.
Finding Discord in Harmony

He happened to be talking about a new open source initiative, but I couldn’t help but relate this simple principle to my experience with agile methodologies.

I have found that Big Design Up Front environments attract people who want to talk about software development, while iterative environments attract people who want to develop software. Is it any surpise that in companies where BDUF is predominant, nobody wants to stoop to coding? Everyone wants to be an “architect” or a “Business Analyst” or a “Product Manager.”

Recently I met a very bright fellow who is implementing a big new framework initiative. Developing within the framework seems to be quite frustrating and time consuming. Of course, there are many buzzword-compliant benefits promised from the framework. But there’s a certain “smell” to the project.

After some reflection, I realized that the problem with the framework is that the “architects” behind it have little or no interest in software development. Unlike today’s flavour-of-the-moment open source framework,* the developers of the framework do not actually use the framework. They’re architects, they don’t actually code applications. They don’t eat their own dogfood.

Their framework was developed for people who like design documents, buzzwords, and PowerPoint slides. And for that reason, there is lots of documentation and white papers. But there is precious little in the way of working example applications.

I suspect—although I don’t actually know—that the framework began with a white paper, and its destiny was forged then and there by that simple act.

Turning back toward the light, I think there’s a powerful lesson. Begin each project as Scrum begins, with the simplest chunk of code that delivers a benefit. If you’re building a framework, start with an example application in mind. Don’t make it “hello, framework.” Begin with something you can use and make sure your framework actually makes your life easier.

I’ll close with a joke:
A programmer is someone who is so irritated by small inconveniences that they will spend weeks writing a script, so they can spend days debugging same script, so they can save five minutes of their time, which they will waste reading slashdot on reddit.
Just remember that if your work actually saves you some time you’ve created something of value. And the best way to make that happen is to start with working code.

* Ruby on Rails (link above), is the foundation of Basecamp, a software service for distributed project management.

Labels: ,


Comments on “Working code attracts people who want to code:
Great post. I made a few comments in response on my blog here:

Another thing that I have observed is that dev's with skills to really really code, IE dev's that can write good code fast enough they get carpel tunnel coding, have much more confidence to start with code vs. design. Because as they realize mistakes they'll just rewrite the entire thing. Other dev's that aren't as strong or that skilled often should or prefer to start with design. The most dangerous are those who think they are good, write bad code, and fall in love with it, and then move on leaving others with their screwed up legacy.
Yes, I've noticed this myself. The way that I prefer to sum it up is that an architect must code to support his design, whereas a developer must design to support his code.

If you don't involve yourself in either part your bound to make mistakes. How much is necessary is a qualitative issue that everyone must make for themselves, but recognizing that a proper mix is necessary is the first step.

To read more, check out What is a software Architect

I also recently worked on a project where this effect was very obvious. I had been talking to the team about some designs, but they felt more like just doing it the way they always have. My solution was to take a weekend and write the framework, along with a test app.

When I showed it to the team on Monday they were alot more happy and ran with it to create results I was very happy with. The really odd part about it all was that beyond taking ownership they started push me away from the coding.

I have to admit that was a bit annoying, but it was a short project, I had lots of other work to get done, and they were doing a great job so it made more sense not to create conflict just because I wanted to write some code. I still got around to reviewing all of the code so at least I wasn't totally out of the loop.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /