Book Review: The Manga Guide to Physics

The Manga Guide to Physicsby Hideo Nitta and Keita Takatsu. Published by No Starch Press, ISBN-10: 1593271964.

This book is an awfully fun, highly educational read. My last involvement with physics was 30 years ago in high school when I sat in the back row of Mr. Davis’s classroom with my best friend Ernie Fatta. I was more interested in trying to flirt with the pretty girl who sat near us, plus math wasn’t my strong suit, so I didn’t get much out of the course. Go figure.

This book uses a story line to expose readers to fundamental physics concepts like Newton’s Laws of Motion, vectors of force, and kinetic energy. A patient physics geek walks the main character through the concepts using practical demonstrations with tennis balls, bodies, etc.

All the concepts are laid out in very clear fashion, and the examples are really spot on and understandable. There’s math involved, but it’s kept at an understandable level and is presented in very short, progressive steps.

This was a really enjoyable read – and it was even educational. I loved the format and I really appreciated the effort and thought that went into laying out the material in such a clear fashion.

There’s an entire series of these Manga Guides covering everything from molecular biology to databases. If the others are as good as this one then I’d be happy to read them too!

Book Review: The Economics of Iterative Software Development

The Economics of Iterative Software Development, by Walker Royce, et. al., published by Addison-Wesley, ISBN 0321509358.

This is a lean book (small size, only 170 pages) which attempts to help managers and decision makers move to iterative approaches over waterfall.  The book’s well written and has some good, thought-provoking discussion in it.

You won’t find discussions of specific methodologies in this book, but you will find repeated emphasis on critical concepts like delivering running systems over useless documentation (not ignoring documentation, mind you, but delivering the right amount of it). Doing the right amount of planning at the project’s start is also emphasized: avoiding over-architecting and big design up front.

It struck me that much of the authors’ definition of “iterative” development is subtly scattered around the book. It’s not always In Your Face, and that’s actually OK because you’re able to better focus on their deeper points.

The economics part of the book’s title comes through some good discussion on ensuring you’re delivering business value, plus an entire section on measuring your project’s success. There’s good discussion in those sections to help you understand opportunity cost (if I do this, what else am I unable to do?), net present value, and a great example on prioritizing features based on their value to the business.

Some things in the book are a little vague for my tastes, but the authors did a nice job of keeping the book brief, concise, and on target.

Overall it’s a very good, useful read.

Slides Posted for “Three Tips to Improve Your Process”

Last night I gave my “Three Tips to Improve Your Process” talk at at the Cincinnati Software Process Improvement Network (SPIN). There were some very good discussion-provoking questions – always good for me tuning up my talk for the next time!

The latest iteration of my deck can be found here.

Books I mentioned in the talk:

• Shore & Warden’s The Art of Agile Development
• Steve McConnell’s Software Estimation and the seminal Code Complete
• Tom and Mary Poppendieck’s Lean Software Development and Implementing Lean Software Development

Thanks to the great folks at SPIN for letting me talk!

Book Review: Beautiful Teams

Beautiful Teams, by Andrew Stellman & Jennifer Greene. Published by O’Reilly, ISBN 0596518021.

This book’s a good read and a nice addition to your bookshelf, although its uneven writing style and fractured voice detract from some great tidbits.

Beautiful Teams is a collection of interviews and essays by various folks in and around the software industry.  Each chapter is a great interview with folks like Steve McConnell or Scott Ambler, or an essay-like article from Mike Cohn or Corey Doctorow. Chapters are slotted into broad sections dealing with individuals, goals, practices, obstacles, and music – as in how parallels can be drawn between musicians in a band and members of software teams.

The uneven writing style and fractured voice can be somewhat expected since each author wrote their own articles, but tighter editing could have really polished up the chapters and made the book more cohesive. The tone of many of the articles made it seem they were drawn directly from the authors’ blogs – another point for having had some tighter editing. I also wished that each chapter had an introduction/bio about the author. While these people are supposed industry leaders, there were quite a few authors I wasn’t familiar with, so I was left wondering what their accomplishments were that made them a target to get in the book.

Complaints aside, I got very good value from reading the book. The wisdom in several articles around dealing with team dynamics was exceedingly useful, and I also found it good backup to read industry leaders pointing out it’s important to move poor performers or negative influences off teams.

Several chapters really stood out for me: Grady Booch’s interview on creating team cultures, James Grenning’s article on implementing extreme programming (XP) in a heavily bureaucratic shop during XP’s early days, and Steve McConnell’s interview about improving team skills, morale, and practices.

Booch’s interview really struck home due to his discussion of working on geographically distributed teams. I’m a remote worker and am far away from everyone I work with at Telligent, so this was particularly interesting to me.  Booch’s comments on the importance of trust between team members and dealing with cultural issues really struck home – he emphasized that technology isn’t the limiting factor on poor-performing distributed teams.

Greening’s experience pushing for change was a great read. The tone and style are clunky, but the content’s gold. Greening was learning XP in its earliest days and worked hard to get an XP team going on a project in a very tight-laced, policy-ridden company. The number one takeaway from me from this article was something I’m already a huge believer in: culture change will utterly fail if you don’t have management and leadership that actively supports the change.

I’ve yet to read anything from Steve McConnell that wasn’t ridden with great wisdom, and his interview in this book certainly kept that tradition.  His points on helping establish a team identity were highly useful. I loved his commentary on the asinine failure (my words) of companies to budget funds for team and morale building. It makes no sense that companies will spend millions on payroll, yet do nothing to build and grow team morale.

Overall I’ve really enjoyed reading this book. It’s one of the few I’ll keep around on my bookshelf.

Book Review: Making Things Happen

Making Things Happen: Mastering Project Management by Scott Berkun, pub. O’Reilly, ISBN 0596517718.

This book’s been enjoyable and useful to read. There are some sections which didn’t give me a lot of value, and I think some hard trimming to shorten the book’s length would have been useful, but overall it’s been a positive addition to my bookshelf.

I don’t line up 100% with Berkun’s approach to project management – he seems to be  heavy on loading up on extensive documentation up front, and he’s seemingly tepid about specs being a conversation vehicle between stakeholders and developers. I’m adamant that specs need to evolve with the stakeholders, analysts, devs, testers, and other team members being active participants in the process.

Those nits aside, I got great value out of a number of Berkun’s chapters, particularly those around leadership and trust, decision making, and recovering when things go wrong. He’s also got exercises at the end of each chapter which help get thought-provoking juices flowing.  Additionally, there’s a lot of small, useful details in this book as well, ranging from writing good e-mails to advice on running meetings.

Overall it’s been a good read and I’d happily recommend it.

Book Review: Implementing Automated Software Testing

Implementing Automated Software Testing by Elfriede Dustin, Thom Carrett, Bernie Gauf. Addison-Wesley. ISBN 0321580516.

This book isn’t for everyone, but everyone can get some value out of it. What I mean by that rather confusing statement is that folks working in Agile environments will likely want to throw the book across the room while folks in more bureaucratic environments like CMMI or other waterfall environments will likely get a great deal of value from the book.

I’m an Agile fanatic and I had a difficult time dealing with book’s approach which emphasizes spending large amounts of time creating documentation such as requirements traceability matrixes, detailed test plans, etc. My preferred approach is to have testers working side-by-side as part of a team, creating specifications from user stories/requirements and moving those right in to automated test suites via tools like Selenium, Cucumber, or RSpec.

That said, I did indeed get some good value from the book. I found the discussions on making hard evaluations on what to test very worthwhile reading: teams can easily vaporize large amounts of time creating large suites of brittle, unmaintainable automated tests. This book has several really good chapters on using business cases to drive return on investment (ROI) decisions for testing, understanding automated test pitfalls, and adjusting your testing as you progress through your project.

Additionally, one of the book’s high points was on building the test team: “Put the Right People on the Project – Know the Skill Sets Required.” This is a great chapter which emphasizes starting the search by focusing on how to interview test team members – and how those testers’ skills are greatly different than other members of the team.

The book’s very academic, dry tone makes for some difficult reading, and few concrete examples are used until very late in the book. Having spent a large number of years either in the DOD or working for DOD contractors, it quickly became apparent that much of the book seemed targeted to folks working in those environments – too many dry acronyms are scattered through the book, adding to the difficulty in reading.

The lack of examples using real tools frustrated me. While the appendices contain some examples of comparing various tools, the book doesn’t actually show how a real world testing environment would use those tools. One appendix, eight or nine pages in length, is touted as a “Case Study” but falls short, in my opinion.

Overall it’s a decent book. The dry tone and lack of real environments is balanced out by the excellent coverage of team skills and emphasis on selecting how and what you test.

.NET Work in Frederick, MD

Normally I don’t use my blog as a venue for job postings, but this one’s for a rather unique opportunity.

My wife works for Syracuse Research Corporation, a great company based out of, wait for it, Syracuse, NY. The company targets support and research work for the Department of Defense, and I’ve really, REALLY liked what I’ve seen for their culture, leadership, and employee support. If you’ve read my blog much then you may know how critically important those three things are to me.

They currently have an opening for a .NET person in Frederick, Maryland. The position requires a Top Secret/SCI clearance, so it’s a tough billet to fill.

If you’re in that area, or are willing to relocate, I’d encourage you to have a look at the job’s description. If you’re interested, contact me (see link on sidebar) and I can put you in touch with the right folks.

Dayton Code & Coffee, Tuesday 5/5

Following the neat idea of the Columbus Code & Coffee, Chris Schroll, Derek Hubbard, and I are going to meet up at the Panera Bread at Fairfield Commons on Tuesday, 5/5, at 8:00 am.

We’re thinking of working through some of the Ruby Koans from the geeks at EdgeCase, or maybe having a look at Sean Chambers’ SOLID stuff out on Git.

Stop by if you’re interested in gabbing about code or pairing up. Don’t worry about your skill level – just bring some interest!

Remote Retrospectives with Twiddla

I’m a big fan of retrospectives for teams. Retrospectives smooth out bumps in your team’s environment and it gives everyone a sense they’ve had a chance to air their gripes – or offer up praises, even!

Retrospectives for remote teams can be tough, simply because so much value for retrospectives is gained through the interaction of folks in a room. At Telligent the team I’m on is four guys scattered between Ohio and Florida. While I’d really like an excuse to travel down to see Sean near Jacksonville, that won’t quite work.

At yesterday’s retrospective we gave a shot at using Twiddla as a retrospective board. Twiddla, coupled with Tokbox for video/audio, turned out to be a great no-friction solution as a place to put our Good/Bad/Confusing topics. It was also stupid easy to move those topics around as we did our organization phase.

The red/yellow/green dots were my addition after we’d moved and voted on things – I realized that we didn’t have a way to remember which topics were in which category. (Green for good/Red for bad/Yellow for confusing) I think next retrospective we’ll simply preface each topic with G/B/C to keep those straight.

We had a great retrospective, and it was in part because we found a tool that didn’t get in the way. Low-friction, usable tools, FTW!