(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:
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:
* Ruby on Rails (link above), is the foundation of Basecamp, a software service for distributed project management.
Charles Miller made a profound observation:
Working code attracts people who want to code. Design documents attract people who want to talk about coding.
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 wasteJust 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.reading slashdoton reddit.
* Ruby on Rails (link above), is the foundation of Basecamp, a software service for distributed project management.
Comments on “Working code attracts people who want to code”:
<< Home
Great post. I made a few comments in response on my blog here:
http://codebetter.com/blogs/darrell.norton/archive/2005/06/17/64753.aspx
http://codebetter.com/blogs/darrell.norton/archive/2005/06/17/64753.aspx
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.
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
