The tagline for this blog is carefully considered. Think – Design – Build. Three steps, in a precise order, the way software development should be. I have been working in an agile environment for about three years now, I like the concept. As mentioned earlier on this blog, I have been a proponent of agile concepts since 1999 or 2000 when I read a copy of Kent Beck’s Extreme Programming Explained.
I’m still uneasy with the way I understand agile and the way I have seen it implemented. You can’t build great, long-lasting, well-designed software by starting with the most important feature first, and just doing what is necessary to make it work. That is much of agile, summed up in a single sentence. Building on that, you can really build a lot of software and you can make a lot of progress. But, it comes at a price.
Without planning ahead and thinking about the entire picture of what you are trying to build, you are very likely to end up with what us old-timers call “spaghetti code.” Then, we are told, you just refactor it (see Martin Fowler’s Refactoring: Improving the Design of Existing Code). Now, I think the concept of refactoring is a great idea, and whatever we can learn about how to do that well will serve us in our endeavors. However, by definition, we are admitting that we didn’t do it right the first time. As they say, “You don’t have time to do it right, but you have time to do it over.”
I haven’t completely made up my mind about this paradox, but I will share one of the best lessons I learned when I first began developing on a product that was intended to be sold to dozens, hopefully hundreds of clients. I was new in the field of 3rd party vendor software in the IBM mainframe world. I had developed code for 5-6 years, but this was my first experience in developing code for programs that would be sold and shipped to dozens of clients who would all get on the phone and call the minute they started using it if it didn’t work. This stuff had to work.
I took my job very seriously, so when I was given a task, I got started right away. Can’t waste any time, have to start writing code and figure this out. And so, I spent a couple of hours planning my approach and starting shoveling in the BAL instructions. I was pretty good at it too. Along about lunch time I went to see my team leader, Jim, who was also a developer. The organization we worked for believed that team leaders should develop code – kept them sharp, they understood what they were “leading.” He had a part of the project that my module was to fit into. I wondered how far along he was.
When I got to his cube to check, I realized he hadn’t started yet. He wasn’t even behind his 3270 terminal. He was sitting by the window at a little table, looking out the window. I knew he was good – maybe he was done.
“Have you started coding yet?”, I asked him.
“No, ” he replied, “I’m thinking.
Thinking! That is all he did for three days. Everytime I stopped by he cube it was quiet. No keystrokes, no mad debugging sessions, no cups of half-drank coffee lying around. Just peace and quiet.
“When are you going to start coding?”, I asked him. “I’m almost done with my module and I’ll be needing your piece soon.”
“You can finish when you like,” he told me. ”I’m not starting it till I know how it will end. I have to figure it out. By the way, how are you going to handle the carriage control?”
“Well, I haven’t figured that out yet, ” I admitted. ”I don’t think it will be that hard. I left it till the end, I’ll figure out exactly how it fits in when I get there. It is just a minor part of the whole thing.”
To his credit, he didn’t laugh at me or fire me. He just kind of smiled and went back to thinking.
A couple of days later while I was “refactoring” to try to get carriage control to fit into my module, I went to his cube because I heard wonderful noise. He was typing. I stepped into his cube, but he barely looked up while he waved me away. ”Don’t bother me right now, I’m almost done.”
I walked away, but I smiled as I did. ”Almost done?” There was no way, his part was more difficult than mine and I knew he hadn’t even started till this morning.
When he came to my cube late in the afternoon, he was tired, but looked happy. He was ready to test it. He needed my module. Unfortunately, my module was in pieces all over the DASD. It wasn’t ready to be integration tested, it couldn’t even be unit tested.
We began to talk, and as we talked I realized that most of what I had written wasn’t going to work. I had missed a couple of important design requirements. He showed me his code – beautiful, well-structured, easy-to-read, well-commented BAL code. I tried to keep my code away from him, didn’t want him to see it, but eventually he needed to look at it so that he could help me figure out what was wrong.
We did make it work. It was pretty clever, as most of the stuff we wrote together was. That code probably died a natural death 10 years ago or more, but I learned an important lesson, “Think first.” It makes the rest of the project easier.
That concerns me about agile. The code is the thing! I like that. But I think it misses the point. The code is the result of a good developer understanding what the problem is and thinking about a way to solve the problem. The code is really the AFTER THOUGHT.
Think first – code after you know what you are going to do. You might just end up with something that doesn’t need “refactored.”