by Dan Pilone and Russ Miles
Publisher: O'Reilly Media, Inc.
Publication Date: January 2008
Ahh... software development: the allure of creating something that can change the world out of absolutely nothing but the computer in front of you. If you worked on any software projects in school, you likely worked on them alone. You were in charge of your own design, your own code, your own testing (if you decided to do it at all), and most importantly, your own schedule. In short, you were the master of your domain, and you set your own deliverables.
But then one day, you graduate from school, and you start to work for a software company, and everything begins to change. From that day forward, you have to work on a team, implementing a project that you didn't design, writing new features, and fixing other people's bugs, all the while striving to make deadlines that you didn't even think were possible. Suddenly, things don't seem so easy anymore, and before long, you or your manager are looking for a process to make things a little more manageable.
That's what Head First Software Development is about. Software development is a complex process, and programmers have learned plenty about what works and what doesn't work over the past 30 years. Take, for example, the ubiquitous waterfall model. The waterfall model stresses the idea that you gather your requirements, design, then go off and code by yourself for a while, then test, then deliver the result for verification. At that point, the deliverable is made, and with a little bit of maintenance, everyone is happy.
Unfortunately, the waterfall model never worked well. I have vivid memories of delivering software to people in the mid-1990s, using the waterfall method, and they came back and said, "That's not right. We need to change this requirement." And under duress from my boss and his ever-tightening schedule, I would have to reply something to the effect of, "I'm sorry, but we don't have the time to re-engineer this over again. You should have done the requirements right the first time." Or maybe they got lucky and we said, "OK, we'll make this change, but please don't change the requirements again." The result was that everyone was miserable: Our once-highly venerated waterfall model did not allow us to go back and change the requirements once they were set in stone. To do so was considered bad planning -- something to be strictly avoided, lest you be seen as inefficient and branded as such on your yearly performance review.
Head First Software Development attacks this myth right in the first chapter, by warning us against the pitfalls of "Big Bang" development. The book defines Big Bang development as similar to the traditional waterfall model: You gather the customers' requirements, do your design, then go off and happily code without talking to anyone, then come back with the final result. And it's invariably a mess, because the customers end up with something different than they expected or things changed in the middle.
It's far better to use a cyclical, iterative process, as described in Chapters 2 and 3. With a cyclical process, you frequently communicate with your customers. The key parts of the process are the same: You ask the customers what requirements they have, then brainstorm and estimate with them to come up with a realistic idea of what should be included in the software and when. However, the requirements are broken down into smaller parts and worked into the project piecemeal. This is a tricky area, because it's basically a negotiation game to figure out how you can break down requirements into a manageable set and create programming iterations that, taken as a whole, dictate the schedule of your entire project. Start off badly, and the project is sure to fall short of expectations.
One part of Chapter 3 that really struck a chord with me was the idea that "Programmers think in Utopian days" and "Developers think in real-world days." This reminds me of my days as a solo programmer in school, where I was constantly overestimating what I could get done in a day by assuming that I would be coding from dawn to dusk -- or sometimes dusk to dawn -- without any interruptions. If I got the work done in the estimated time, I would pat myself on the back. But if I didn't, I just said, "Yeah, whatever" and worked on the program again the next day. Unfortunately, this mode of thinking doesn't work in software development teams. Real-world days are filled with all sorts of interruptions, such as dreaded staff meetings and other things that suck away productivity. Thinking in Utopian schedules breeds stress.
Chapter 4 dives deeper into the arcane art of translating user stories -- short descriptions of what the product should do -- into manageable tasks. As I mentioned earlier, those task estimates are the key part of whether your customers are happy working with you or if they'll never recommend you again -- and here is where you start to learn about velocity. Velocity is a key metric that you can use to determine how fast the development team is checking tasks off their lists, and when factoring in how many developers to have on your team, how fast you can get your tasks done.
Chapter 5 was a familiar read: This one is about design. You'll see quite a few UML diagrams in this chapter, and there's good companion reading in Head First Object-Oriented Analysis and Design to keep you grounded. Here's a welcome tip: We all know what happens when you have a bad design. But just as important is that you don't strive for a "perfect" design. In particular, you have to have the ability for your design to be refactored -- the programmer's term for "changed" -- if something unexpected comes up both during development and after the project is implemented.
Chapter 6 covers defensive development, which is this book's way of talking about using version-control tools. Most developers will already be familiar with techniques such as checking out and checking in, using tags, and branching and merging with mainline by using tools such as Clearcase, CVS, or Subversion. If you're already familiar with these tools -- and you should be if you're working on even the simplest development team -- this will be old hat.
The humorously titled Chapter 6.5 (six and a half) discusses another critical portion of software development: your build script. Again, if you're familiar with build tools such as make or Ant, then this will be old hat to you. But it's always a good idea to see what sort of elements make up an industrial-strength build-script, especially when it comes to automated testing and deploying modules into the wild.
On that note, Chapters 7 and 8 thoroughly cover another element that is critical to software development: testing. I've always been a huge proponent of unit testing. If you use a testing tool like JUnit, which comes embedded in the NetBeans IDE, then you know exactly what this chapter talks about. The idea is that you constantly test your software for all the things that can go wrong, using things like black-box testing (I/O testing), grey-box testing (negative code testing), and white-box testing (inside knowledge) to make sure that your code is bulletproof. If you're not familiar with testing techniques, this chapter will get you up to speed quickly.
Chapter 9 talks about system testing, another key aspect of software development, which tests the big program -- in effect, testing to make sure that all the disparate portions created by all the different programmers can work together to make a complete software package.
Chapter 10 discusses working your way toward the next iteration with your customers, especially that painful realization that once everything works the way it should, you need to start changing it again. Chapter 11 discusses what happens when you have to face the fact that a bug is live in the customers' software and how to deal with it in your next iteration.
And then comes Chapter 12, which is arguably the most important chapter. This chapter helps you to come up with a software development process that you can live with. Different development teams work with different processes, and a process that works well in one team may not be the best process for another team.
What I love the most about the Head First series is that it tosses out the dry, technical learning book that we all suffered through in programming class -- and occasionally still suffer through -- and replaces it with something that's, well, just a heck of a lot of fun. Many times, that's a blessing. For example, if you're familiar with the Scrum methodology, you're going to find that many parts of this book are familiar. The roles in Scrum are a little more pronounced, but the core ideas are still there. You'll still have daily stand-up meetings that are very short -- 15 minutes maximum -- and help to show exactly what is getting done and what is starting to show up as a problem on your master whiteboard.
As with all Head First books, Head First Software Development peppers the text with many recommendations, this time for helpful software packages on the Internet. The book frequently initiates free-form discussions as to why adding this software to your development tools is such a good idea, often at the end of the chapter. You would do well to follow most of this advice.
One final word, in the interest of disclosure: I used to work as an editor for O'Reilly Media, Inc., back when it was called O'Reilly and Associates, Inc., and I know the primary editor of this book personally. That being said, I don't get any royalties from this book, nor am I rewarded in any way for reviewing it.
If you are a Java technology publisher and would like me to review your Java SE, Java ME, or Java EE book on java.sun.com, don't hesitate: Send me an email right now. No, I mean it. Stop what you're doing and write me. Have you contacted me yet? OK, good. And now for my standard disclaimer: I won't review every book I receive, but we all know that there are some gems out there that really deserve the limelight. So let me know what they are.