Read more of this story at Slashdot.
Yesterday at a party I was talking with a guy who works for IBM doing "agile" development. It was the first time I had a chance to talk with someone who actually does this, for a length of time, so I could play Q&A to figure out how it maps onto how I do software development. I was pretty sure it did.
I think what I called We Make Shitty Software is in other words the same thing as the agile process. Whatever it's called, we all acknowledge that our software is imperfect, it's a process, but we're working to make it better, and more responsive to users. Other creative arts aren't as iterative as software.
I may have other concepts to contribute, such as Narrate Your Work, and Instant Outlining, which have made big differences in the development process for me and the people I have worked with. We developed Radio UserLand in 2001 and 2002 with instant outlining. And I've been doing Narrate Your Work, which is an individual thing, for well over a year. It gets better all the time. I can't do any development work these days without telling the story in my worknotes site.
For me, the development process is really the work I do. Because that's where it has the greatest impact, not just for software development imho, but in other project-oriented activities. I think all kinds of production are better managed with NYW and I/O. And someday there may be movies or paintings that are iterative, so will benefit from the agile process. Perhaps there already are?
Another thing that works is the idea of code as a weblog. At the top of each part there's a section where each change is explained. The important thing is that with elision (expand/collapse) comments don't take up visual space so there's no penalty for fully explaining the work. Without this ability there's an impossible tradeoff between comments and the clarity of comment-free code. No manager wants to penalize developers for commenting their work. With this change, with outlining, that now works.
We did this at UserLand, starting in the early 90s. There's code in our system with over 15 years of mods to it made by different developers, and you can, if they were careful about it, know what they were thinking as they changed the code. The code tells its story. I have never seen any other devteam do this. If there are other examples, I'd love to compare experiences.
These days I include links to my worknotes in my code, because there is a level of detail I will go into on the website that I won't go into in the code. One of the reasons is that the project is not the same thing as the code modifications. The reasons for making the changes may apply to several objects in the code. So it makes more sense to explain it outside the code. In other words there's a level above the code. That's where my worknotes tie things together.
Here's an example of a piece of code that's been developed iteratively over a couple of years. Look in the Changes section near the top, you'll see that it tells a story. This is real code that's very much deployed, in fact the text you're reading now was rendered with it (as was the code listing).
And an example of day's work in the worknotes site.
Read more of this story at Slashdot.