Contents:
- This month's Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 2
- Announcements
=-=-=-=-=-
Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 2
Last month, I suggested some approaches for making a waterfall work for you. If you missed that issue, see <https://www.jrothman.com/pragmaticmanager/waterfallpart1.html>.
Assuming you're somewhere in the coding phase of your project, here are some possibilities for making the waterfall work for you:
- Ask the developers to integrate code review as part of their coding.
One of the easiest and cheapest ways to obtain feedback about the project's progress is to have a culture of code review. I certainly agree that reviewing other documents helps with the project, but let's face it. What we ship is code. What our customers run is executable code. So the more code review the project team can integrate into the project, the more likely each developer is to obtain feedback about his or her code.
I've used several types of code review: inspections, peer review, walkthroughs, buddy review, and pair programming. Formal inspections are great and provide tons of feedback to the developer (and project manager). On the other hand, it's difficult to maintain a culture of inspection when the project starts slipping. Peer review, when one or two peers review completed code and comment back to the author is also useful and depends on the peers to have enough time to review the completed code. Walkthroughs, where the author walks through the work with other people can be useful in some circumstances, such as, “Harry, I can't see my problem here. Can I walk you through it?”
My two favorite kinds of code review are buddy review and pair programming. With buddy review, two people write code for an hour or two. At the end of that timebox, they exchange their code, no matter what shape it's in. They make comments on the other person's code, and return it to the author. The author has a chance to fix whatever isn't quite right, and then the two people break for lunch or the end of the day. Buddies can write code in 2-hour chunks, review and fix in an hour. You don't need to keep the same buddy for the whole day or the whole week. Since the amount of code is small, it's relatively easy to review and maintain the rhythm of review. Because the buddies timebox their work, they're more likely to complete small pieces rather than have lots of things partially done.
Pair programming, where two people share one computer, one keyboard, one mouse, and one screen to write code has review built into it. Both people are focused on doing the right thing in the code, and the person who's not typing is continuously reviewing. For those of you who are concerned: the productivity of the two people pairing is significantly higher than just two people separately.
- Implement by feature, not by architectural layer.
It's very tempting to implement by architectural layer. After all, the architects have beautiful pictures of what the architecture should look like and how it should work. Somehow, the final product never quite looks like the architectural picture. Something had to give to make that piece of functionality work. Maybe more than one something.
If you don't implement by architecture, you're free to implement by feature. When you implement by feature, you implement only the architectural pieces needed for this feature. For some classically trained developers, this is a hard idea to put into practice. We were taught a top-down architecture-design-implementation approach, and for small easy projects, it might even have worked.
But no one works on small easy projects anymore. All the projects are more complex with more pieces and exceptions and difficult-to-imagine interdependencies. If you implement by feature, those interdependencies tend to be more visible earlier–certainly before final integration and testing.
One of the other benefits of implementing by feature is that the entire project team can see progress. When you've finished a feature, it's really finished. Not finished–except for integration– or –except for testing–, it's really finished.
- Integrate the code continuously.
Back in the days of mainframes and mini-computers–expensive computers and cheap people–one person had the chance to run their code on the computer alone. I was one of those people who saved my work and built a new executable several times a day (on the mini-computers). That way if I introduced a problem, I knew where the problem was.
Now that computers are cheap and people are expensive, some developers think it's worth waiting until all the coding is “done” for a feature or a set of features, or for an architectural layer to be finished. But integrating–checking in your code at least once a day, building the system, and verifying you haven't broken anything–is faster when you have just a little bit of work to check in, build, and test.
Some of you are probably rolling your eyes. “JR, we can't do that–our build takes longer than a day to finish.” That's a huge problem. And it's not just a problem now, in the middle of the project. Nope, it's a problem at the end when three days before you want to release, you find a Really Big Bad Enormous Gigantic Bug Which Will Make All Your Customers Run Away If You Release With It. That's when your inability to make small changes and check them rapidly could kill your company.
If you're a project manager, make it your business to know how long the build takes. If it takes more than an hour, do whatever you need to do to get the build time to under an hour. Then work to make it no more than a few minutes. Continuous integration is one of the fastest ways to eliminate the waterfall lifecycle schedule risk.
- Ask the testers to test whatever is available every day.
Some testers think that they should only receive what the developers say is “done.” That's a nice thought, but testers can test whatever was checked in, if they can think creatively enough about the testing and test from underneath the GUI. (This is quite hard to do.) You might have a small piece of a feature, or two-thirds of a set of features where the GUI may still be in flux.
Once the GUI is available, the testers can test from the GUI.
The testers are a great source of feedback to the developers, about how pieces of the system interact with each other. Testers can see where the system looks good and where it doesn't. Testers who provide visibility into the general integration of the system are worth their weight in gold. Maybe platinum.
Testers don't have to go back and test everything every day. If they test the new features, working in concert with the developers, the entire project team will know what's working and what's not much earlier than they might have expected in a waterfall lifecycle.
You've noticed that “integration” is a theme in this issue. That's because, especially for software projects, the more integrated–cross-functional–you can make all the activities, the more likely you are to be successful in your project.
I'll have more tips for the end of the project in my next Pragmatic Manager.
=-=-=-=-=-
Announcements:
I've added several new workshops to my workshop page. See <https://www.jrothman.com/workshops.html> for the full list. I would be happy to customize workshops for you based on your needs.
The next AYE conference is November 4-7, 2007 in Phoenix. See <http://www.ayeconference.com> for more details. I hope you decide to join us. Email me for more details or to be added to our mailing list. If you'd like to sign up directly for our email list, go to <http://www.ayeconference.com/signup.cgi>.
As always, take a look at my blogs to see my most recent writing.
Managing Product Development
Hiring Technical People
Thanks for reading, and please do send me your comments.
Johanna
© 2007 Johanna Rothman
If you'd like some common sense, down-to-earth ideas about how to manage your projects, manage your people, or manage your individual work, you've come to the right place.
See back issues of my email newsletter here.
Tell me how you've used these ideas. Or, if you have questions, comments, or feedback, tell me that too.