A brand new book on Software Development was recently released by O'Reilly, titled Head First Software Development. I had the opportunity to review the book and interview the authors as well.
In this interview, Dan Pilone and Russell Miles, the authors give us an insight into the book and also how they got the opportunity to write for Head First Labs.
1. Dan, Russ, tell us something about yourself. Who you are, where are you located, and what kind of work do you do?
[img_assist|nid=1886|title=|desc=|link=none|align=left|width=75|height=100]Dan> I'm (Dan) original from just outside of Philadelphia but now live and work in the Washington, DC area. I'm a Sr. Software Architect for Vangent, Inc. and am currently leading development for a NASA project in Greenbelt MD. I've done projects for the Naval Research Laboratory, Hughes Networks, UPS, and ARINC in the past. My process background really comes from a RUP focus but over the last few years, working with a fantastic development team, we've adopted a lot of the agile best practices. That's not to say everything worked perfectly or that every agile suggestion is the right way to go, but, like Russ & I talk about in the book, it's all about being willing and able to adapt and having a way to measure whether or not it worked.
[img_assist|nid=1887|title=|desc=|link=none|align=left|width=76|height=100]Russ> Hi Meera, really nice to meet you. I'm Russ Miles and I hail from Eastbourne, England and currently live just
outside London in Guildford. I've been fortunate enough to have worked in all manner of extremes in software development, from banking to mobile, on anything from small 1 month projects to five year+ Defence programme, and working as everything from junior developer to senior technologist. This book has been a fantastic opportunity for me to teach some of those hard-earned experiences.
Right now I am really enjoying being a consultant for Rod Johnson's company, SpringSource, working to help companies apply best practices in enterprise development. I also conduct training for SpringSource in the UK. What's really great is that I can honestly say that a lot of the work I do every day corresponds to the lessons we poured into Head First Software Development.
2. Why did you both decide to write a book about Software Development? Whose idea was it to write this book?
Dan> I think it would be hard to say whose idea it was to write the book - I think we both came at the book looking to write it and O'Reilly wanted it written. It was a win-win-win.. :). For me, the book idea started a little over 5 years ago. I submitted a proposal to O'Reilly for a Software Process Cookbook. The topic list was extremely similar to what
became HFSD. They weren't looking for a Software Process Cookbook at the time, but were looking for an author for some UML books. Three years and three UML books later the Head First team started looking for authors. In order to write for the Head First team you have to audition. Russ and I auditioned at the same time (I knew Russ from
having tech reviewed his book, yet another UML book by strange coincidence) and both made it through to training.
Russ was originally working on a different Head First book but eventually moved over to work with Brett (the should-be-famous Head First editor) and I on HFSD. As for why I wanted to write it, well, funny enough process isn't a
deep passion of mine. Successful, working software is. I was getting frustrated with the philosophical process discussion books that process-kind-of people liked to argue about but the people writing code just didn't bother reading - they had work to do. I wanted a very approachable book that just helped get the job done. This was the idea behind the Software Process Cookbook. I hadn't even dreamed of what would become HFSD - the teaching, fun, and learning aspects of Head First were perfect for what I wanted to do - I just didn't know it.
Russ> I absolutely agree with you there Dan, this type of book was just begging to be written. We were given free reign to explain how we deliver great software, and that meant we could jump out of the strict process-following masses and really get to the practical challenges and solutions to software development at the coal face.
3. Who is the target audience of this book?
Dan> We are officially targeting developers with 3-5 years of experience - but I feel like that answer leaves off a lot of potential readers. Basically this book assumes you know how to program - it's not an introduction to programming. It's a book about how to build professional software. It's _really about building software_ - it's not a philosophical walk through process theory. It's real world, in the trenches, how to get quality software built that meets the customer's needs, is fun to develop, and comes in on time. Even if you're a seasoned software lead we hope that there's material in this book you'll find helpful.
Russ> Absolutely Dan. The great thing about using the Head First style was the sheer accessibility that we could bring to the subject of software development. Typically a book will aim its content at a particular audience segment so you can make certain assumptions about the experience they will come in with and how the content will then make sense to them. As Dan says, we also do that but the really amazing thing is that by using the Head First storytelling style we can also bring along people who don't necessarily have that experience, giving them that experience through the story.
What this means is that if you, for example, haven't personally felt the pain of working without source code management, then a traditional book that touches on SCM might whoosh straight over your head. You haven't felt the pain of no SCM, so your brain is like "why bother learning this?!" In a Head First book we actually put a ton of thought into how to give the reader that tension so by the time we talk about SCM they are really ready for it, and in some cases where the tension is really built up they are crying out for it. This means the content gets right into your brain.
4. Is this book an introduction to Software Engineering?
Dan> It depends a little on what you consider Software Engineering, but I would say yes. It's not a design book - HFOOAD or HF Design Patterns do a great job with that. It's about how to pull all of the people aspects of developing software together to produce quality work. For example, we spend several chapters about capturing and managing requirements. We have chapters on Configuration Management (source code control), Test Driven Development, dealing with requirements change, dealing with bugs, 3rd party code you didn't write but now you're responsible for,
iterative development and schedule tracking, etc. All the real world stuff you run into when you develop software for a living - things you generally don't learn in Java 101 or Data Structures.
Russ> Dan has things down here for sure, nothing to add specifically from me.
5. Is it necessary to read any other Head First Series books before this one? Like Head First Java, Head First Design Patterns and Head First OOA&D.
Dan> If you know how to code, no. You should be able to pick up HFSD and go for it. Basically we view this book as sitting over some of the other HF books. So, reusing my diagram from Head First Labs, it looks something like this:
Head First Software Development
HFJava -> HFOOAD -> HFDP -> HFPMP
So, you don't have to read any of the books on the bottom row, but that's how I see them fitting together. However, if you've never coded before, this might not be the book to start with.
Russ> Could not agree more. HF Software Development collects together the sorts of practices that make software development deliver great software, but it's not tied to one style of programming (OO) and certainly not one style of programming language. These are concrete lessons that, regardless of technology decisions, will help make your software projects a success.
6. How did you get the opportunity to write for Head first Series?
Dan> I think I covered this in #2, but the short version is HF Labs is always looking for new, talented authors. Head over to http://www.headfirstlabs.com and check out the openings.
Russ> I came through a slightly longer route. I'd written for Brett before back on the regular Animal O'Reilly books (shameless plug for Learning UML 2.0 and AspectJ Cookbook here!) and when Brett took up the editing reins on the Head First series I couldn't wait to get involved. It was just a matter of getting the right book... and HF Software Development was definitely it.
7. All the Head First Series follow a pattern in all their books like There Are No Dumb Questions, Sharpen Your Pencil, Fireside Chat, and Brain Power. Do you have to draw all the graphics and come up with all those stories and scenarios in the book?
Dan> As an author you do need to come up with the scenarios and stories and whatnot for the book - but you don't do it in isolation. The HF editorial team is fantastic and there is a very real method to their madness. There are training sessions you attend, a specific process you follow as an author, and tons of resources available to you. At a quick
glance a HF book might look like clip-art but there's a tremendous amount of thought and work put into every single page. There is learning theory spread throughout the book and lots of little tricks and techniques to keep the learner engaged and absorbing the material. We probably redid 350+ pages of HFSD by the time we were done - and that's
not counting the work done before the pages were initially laid out. As for the graphics and images, those are almost always the result of the amazing graphic artists at HF Labs. In particular Lou Barr has the ability to turn odd, pencil drawn stick figures into fantastic pages that make me want to reread the book. Each of the patterns you identified have specific uses - they're not chosen at random and we try to be consistent, not just with those elements but with all the HF elements like characters, layout, etc.
Russ> I think it's also worth mentioning that all those graphics and types of exercises are actually just the tools that we use to make the subject as compelling as possible. Not to cheapen the graphics input at all, because Lou is an absolute rockstar when it comes to graphics and without her our book would certainly be a _lot_ more boring, but the main focus that we place is on storyboarding _everything_ and, as Dan mentioned, this is mostly done on paper.
In fact, by the time we hit the PC we have already written most of the body text, we know what tools we'll use on each page to keep the learner going, and we've drawn up (using stick figures) what the pages should ideally look like. I say ideally because at every stage things can change, but essentially by the time you get to the PC most of the hard work should be done.
8. Is there a selection process for writing Head First Books?
Dan> Yes - there is. In general you need to submit an audition to HF Labs which then goes through several editors. I believe you then get one round of revisions based on their feedback. After that they review your audition and decide whether to invite you to an upcoming training class. At the training class you'll get an overview of writing for the HF teams and the final decision will be made. Bear in mind, I'm an author and not one of the editors, so I'm not entirely sure of the details behind the scenes, but that's the gist of it. Check out the HF Labs website for more information. If you have an idea, give it a shot - writing for the HF team is an amazing experience and you'll never look at books (or
Power Point Presentations or lectures or just about anything else) the same way again.
Russ> Nothing really to add here. Dan has my thoughts down on things pat.
9. Can you share with the readers about the experience of writing for O'Reilly?
Dan> I think I've covered a lot of it already. It's really a great team to work with. They're in the crazy-smart category and really know what they want from Head First. Kathy Sierra and Bert Bates (the creators of the series) have a really strong case for the approach used in HF books and the editors carry that through. Brett McLaughlin, the HFSD editor, doesn't pull any punches and is nearly always right (yes - that's a rough combination.. :). You can't be afraid of work though - HF books are a serious undertaking and sleep is the first thing they cut.
Russ> In a sentence, it's a tough ride by it's is _so_ rewarding. I think every time an author starts to write a book he will be aiming to write the best possible book he can. The great thing about the Head First team is the support you get in really making that happen. In my experience, it's unprecedented. Every person involved wants your book to not just be good, but be great and that raises the bar tremendously. So, to echo Dan, it's a serious amount of work but when your book gets it's final "ready to print, all systems go" you can be very confident that you have something special on your hands.
10. What Software Development techniques are covered in this book?
Dan> We, very deliberately, do not name a specific process in the book. In some of the first drafts of this book we called out specific processes and spent far too much time either defending one process against another or answering Tech Review feedback about how we are biasing one process or another. So, in our rework we decided to punt on specific process and just present a process as we do it. Obviously we use ideas (either directly or with slight twists) from lots of other processes but we aren't trying to teach a specific process. One of the big take-aways from this book is that you need to tailor the process to the project. There's no silver bullet. As for the specific practices we think work, we are big fans of the user story approach to requirements, source control and automated builds, continuous integration, test driven development, code coverage for testing purposes, and short iterations with frequent releases. The general response to the book has been that we are agile-esque. I would agree, but this isn't an "Agile Rules" kind of book. We discuss problems that are going to require more documentation or more formal process components - again, this book is about real world software development.
Russ> Nothing to add here really, Dan covered it nicely :)
11. What's the biggest mistake people make during software development?
Dan> Getting wrapped up in the technology or development and missing the whole point of why you're writing the software - for the customer(s). You need to come up for air and sanity check your work often. If you're software isn't out there solving real business needs or making you loads of money as people keep buying it you're just not solving problems. Technology is great, but it's a tool to solve real problems.
Russ> Could not agree more. In fact, if I had a nickel for every time I'd heard "hey, we're using <insert dev tool of your choice here> so why now is our project still buggy?" then I might not have needed to write a book and could have retired to Belize rather than just spending my honeymoon there... but seriously, the big lessons in software development have less to do with tools and much more to do with practices, and that's why you'll see a dedicated page at the end of each chapter, called your "Software Development Toolbox", that hammers home each of the practices you picked up throughout the chapter. Those best practices really are where the gold is.
12. Can you give a few tips for our readers to avoid making these mistakes?
Dan> Stay customer focused and get your software out there and in their hands as soon as possible and as often as possible. Don't just embrace change, get excited by it. If people are coming back with feature requests and changes that means they're using it - that means they care about what you're producing. Pay attention to them, but not just what they _say_ - let them use your software (which means frequent releases) and see what works and doesn't work for them.
The next most critical recommendation is automate everything you possibly can. Let your team focus on the hard (fun) parts of figuring out what the customer wants and how to build it and let the system handle building it, testing it, packaging it, deploying it, etc.
Russ> Not much I can really add here, this speaks for both of us.
13. Are there are sample chapters which our readers can download?
Dan> Absolutely - Chapter 6 is available at HF Labs here: http://www.headfirstlabs.com/books/hfsd/
Russ> Ditto for me. Writing a Head First book is not a one-stop exercise and if you have any additional questions about the book or software development in general then please mosey on over to the Head First forums (http://www.headfirstlabs.com/phpBB2/). There's a specific forum for Head First Software Development, as well as for the other titles in the series, so feel free to post away. Both Dan and I are frequently on those lists and so there's no better way to get hold of us authors for all your software development questions and queries.
Thanks for the interview, it was fun!