Reader comments to "How I write software"
I suspect Jim and I are much closer in our ideas than he may think. We seem to have similar backgrounds and have walked down some of the same roads. Our differences come mainly from the title of the column: "How I write software." I meant that literally. With apologies to Red Skelton, I meant "How I (me, Jack Crenshaw, not someone else or a project team) write (program, code, not specify, design, test, or validate) software (not requirements analysis, mission or design specs, or test plans)."
If it seemed that I "jump[ed] right into the code," it's because that's what the column was about. (This month, I write about testing in a similar style.)
Speaking of style, I do write in the first person singular. Mea culpa. It's my style. It's who I am, it's what I do. I'm getting too old to change now. Does this mean that I've never worked as part of a team? Not a bit of it.
Just to be clear, I wasn't advocating that other members of a coding team start a project as I would. I'm not going to tell my team members how they should start on a new project, but the "Hello, world" approach works for me. It helps me put down my design hat and don my coding hat. Why is that a problem? Even if a team of programmers all decided to follow my personal trick, what's the harm in that? Think about it. How long does it take [to write a small snippet of code]? What if we all did it? I disgree that the project would devolve into chaos just because we performed an initial mental exercise to get the coding juices flowing.
Nor was I advocating a "completely undisciplined" approach. I'm was just talking about my approach to implementation.
I disagree that a person stops thinking when he or she starts programming. Programmers don't stop thinking but just think differently. Designing and coding use different sets of neurons. The thought processes are quite different. That's why, in other writings, I've recommended that, even on single-person projects where you're the designer, developer, and perhaps even customer for the product, it's a good idea to stand up, walk away from the computer, go to a different room, and think.
Now, I've known lots of programmers who claimed they could design at the keyboard, while they're coding. I've also seen their code.
I do indeed disagree with Jim that "programming fads . . . spiral development, agile and extreme programming . . ." are fads that will fade away. He seems to favor the classical, "waterfall diagram" approach to product development, which I think is completely discredited. I do agree that more modern methods carry more risk of undisciplined hacking. I also agree that such methods encourage hackers to hack with even more gusto.
But the solution, in my opinion, is not to trash the methods. It's to get rid of (or retrain) the hackers.
Bottom line: a software project requires a lot of skills and a lot of coordination between phases. In the column "How I write software," I wasn't talking about all of them. I was talking about writing software.