An interview with Dan Pilone and Russ Miles
We chatted with Dan Pilone and Russ Miles, authors of the upcoming Head First Software Development, and asked them how their book reflects their industry experience.
What are the most common challenges for beginning software developers?
Dan: Making the transition from a hobbyist developer to a full-time, professional developer with a sense of ownership of the project. Coding by yourself at home late into the night is one thing. Working on a team with mixed skill levels and real-world deadlines is very different. You can't lose the fun and satisfaction you get from coding, but you need to figure out how to do it in a way that pays well.
Russ: Number 1 for me would be just figuring out what software development really produces. What's the goal? When you're in a regular academic environment the emphasis is usually on learning syntax, learning programming constructs, and different approaches—all of this set within the sandbox that is undergraduate academic learning. However, what that training gives you is a slightly false sense of security.
When you hit real-world software development, the game changes. At that point it is all about being productive, being professional and being proud enough to stand by your coding decisions while being wise enough to realize that there are still a great many things to learn.
For me, that rough transition from insular academic sandbox to real world software development, where you work in a team to build something that real users will actually use, is the toughest point in a developer's career.
Dan: We try really hard to avoid the technology and process wars and just teach skills and techniques that we use every day on our projects—things that show results and don't involve massive amounts of overhead. The principles we teach in HFSD (like iterative development, TDD, configuration management, and continuous integration) work for almost any software project—whether it's two people working on the next Google in their basement or a full team writing software for NASA.
Russ: By not advocating one set of approaches over another. HFSD is all about learning the best practices to being a great software developer, it's not about learning one particular theoretical or process-oriented set of tools and rules. For this reason, all of the techniques and tools that the learner picks up in our book are applicable in pretty much any software development environment.
That's on purpose, because this book is all about the best practices that transition across all software development domains, keeping that uber focus on being productive and delivering what the customer (whoever that may be) wants.
What problems are professional software developers most concerned with that HFSD will most effectively help them resolve?
Dan: HFSDhelps you build the software the customer really wants built and makes sure that it actually works when they use it. The tricks of a good software process are about letting you focus on the things you need to (solving the hard design problems, handling change when the customer's business keeps moving) and giving you a safety net to actually get your work done (automated testing, automated builds, iterative development).
Russ: Keeping the customer happy. Keeping momentum up. Keeping everyone on track in your development teams, and, finally, shipping great software. All these challenges are key to any and all software developers, and these are the objectives that we focus on in this book.
How have you applied your own professional experience to the scenarios and learning points you emphasize in HFSD?
Dan: First I've probably made almost all of the mistakes we warn you not to make. A lot of HFSD comes from learning things the hard way. When we recommend a technique or a best practice, we've seen it work. We're using it, every day on big and small projects.
Russ: Well, working in a variety of environments has certainly helped. I have worked in just about every type of software development environment, from formal 20-year-long defense research projects through to short, two-month mobile application development. That variety has been key to giving the book a feel that it really does provide common techniques to help all developers. I've been there when communication fails, I've been there when the customer has waited two years for software that doesn't actually do what it was supposed to, from their perspective; so I've learned (at times the hard way) what really doesn't work. I'm also happy to say that for the last five years I've been working on projects that do deliver what the customer wants, that do deliver on time, and that are highly successful. So my input to this book is focusing on those hard-learned lessons to save other people some of that pain.
You both come from very different backgrounds. What have you found most beneficial about your collaboration on Head First Software Development?
Dan: Russ does a lot of day to day coding while I spend more time doing architect/team lead activities. Working together on this book means that each role has a stake in the book and was argued from that side. Anytime I would lean a little process heavy Russ would pull me back to the people cutting the code. All in all, it was a great balance and made for an even stronger book.
Russ: For me, I've found that it's actually surprising how much we agree on things. That's not to say that I expected to argue, but that I felt that there would be dividing lines between smaller projects that I have tended to work upon recently and the larger NASA-based work that is Dan's primary focus.
However, and this was one thing I was very pleased with, there was SO much overlap in our own experience in terms of the core lessons that helped us become successful software developers that immediately I realized that if we could just tap some of that knowledge for our book then that would definitely be the sort of book I would have liked to have read a few years back. Even better, if we could tap most of our knowledge, then we'd actually have a book I'd like to have on my desk now!
So that's what we're doing—really grabbing all of our common good experiences and lessons learned to give everyone from a beginner developer to an experienced old hand some value in every page, picking the best of our knowledge so that everyone has something to take away.
Even the best developers have seen well-intentioned software projects fail. Instead of surrendering to the common problems, let Head First Software Development guide you through the best practices of software development.
We hear you!
Readers love the Head First approach and are asking for titles covering technologies from PHP to .Net to project management. Stay tuned, we'll be announcing many more titles this year.
Suggest a title
Got a title you'd really like to see in the Head First series? Don't be shy. Fill out our Suggest-o-matic form and let us know. Leave us your email and we'll enter you in a drawing for Head First goodies.