This past week I finished reading the very interesting book, How Google Tests Software. I first heard about this book from an IT-Conversations interview with one of its co-authors, James Whittaker. The interview provides a good overview of many of the key points made in the book, but I still found it worthwhile to read the book.
The book itself is not a how-to book, providing concrete steps on how to test software. Instead the focus is at a higher level with much of the book devoted to describing the different testing roles within the company. There were three particular themes that jumped out at me from both the interview and the book itself.
I came across two articles over the past few days, both of which resonated with me, but neither of which filled me with much hope for a resolution to the problem they addressed.
Ron Jeffries‘ article, Estimation is Evil: Overcoming the Estimation Obsession, enumerates some well-known issues with how software estimates are interpreted and the problems they cause. His suggestion is to forego estimation, start building software, and come to a go/no-go decision after a couple of iteration cycles.
I assume that like many developers, I first became interested in computers while playing computer games. Our family owned a Commodore 64 and I can only wonder how many hours I wasted collecting cave artifacts, dodging neighborhood obstacles on my paper route, and conquering the new world. And the theme song to M.U.L.E. will forever be ingrained into my memory (side note: A really interesting article on the creation of M.U.L.E.).
Unfortunately, I spent all of my time playing games and not learning how to create them. My BASIC knowledge didn’t get past:
10 PRINT "SOME PHRASE FUNNY TO A 12-YEAR OLD"; : GOTO 10
I’ve always wanted to learn more about game development and decided to start learning some of the basics. I thought a good first step would be looking into collision detection. One quick Google search later and I came across a great post by Paul Firth on that exact topic. I only needed to get halfway through the article to learn how to animate balls bouncing in a box, animate balls bouncing in a rotated box, and to develop a simple game of Pong (source code can be found here). Paul’s blog contains a wealth of in-depth information about game creation and I hope to get through many more of his posts.
I’m currently making my way through Charles Petzold’s book The Annotated Turing. Petzold’s book, Code: The Hidden Language of Computer Hardware, is a must read for any software developer and is my favorite computer-related book. The Annotated Turing is proving to be just as interesting.
I’m only halfway through the book so I can’t provide a complete review. The first few chapters discuss Alan Turing’s educational background along with some introductory information on computability and number theory.
Petzold then breaks down Turing’s seminal paper, On Computable Numbers, With an Application to the Entscheidungsproblem. I started this book thinking much of the information would be over my head, but Petzold does a great job of breaking things down and providing easy-to-understand explanations.
Along with Petzold’s commentary, I decided it wold be helpful to create a Turing Machine simulator that I could use as I read through the book. The source code can be found here and a running demo can be found here. The demo includes some pre-configured Turing machine samples from the book, but allows you to define your own machine. Since I’m only halfway through the book, the simulator likely does not simulate the Universal Turing Machine that Turing ultimately designed. I’m hoping to continue updating the code as I finish the rest of the book.
So go out and grab the book, test out different machines on the simulator (or better yet, write your own simulator) and see how the computing age began. It’s a great way to learn about number theory, state machines, and is also a great reminder that we are all standing on the shoulders of giants.
When I was first asked to manage a project at Art & Logic, I had my reservations. Did I really want to start down a career path that led to less development? Would my skills as a developer go stale? My first few projects as a manager were solo projects so I still had plenty of development work and fortunately, I found myself to be a pretty easy person to manage. As time went on I started managing larger projects and with them came the responsibility to manage other developers. To my surprise I found project management to be rewarding and dare I say, even fun. It’s very satisfying to work with clients, helping them define their visions and seeing those visions come to life.
It’s in this context that I was very interested to read the article Engineering Management is Dying and the subsequent discussion on Hacker News. The author seems to define Engineering Management at a step above project management, those managers responsible for teams at a human resources level. However, some of his thoughts still ring true at the project manager level, especially that “…the hackers themselves tend to the business of building things.”
When I first started out as a project manager, I struggled with how best to provide value to the team. Yes, keeping track of task lists and budgets are important tasks that need to be done. But they don’t require any special skill. Like the author, I find that staying “hands-on” is critical, both for understanding the problems your teams face and feeling like you’re an active part of the building process. I try to work on smaller items around the edges of the project, avoiding critical paths in case my management duties need to take priority. I also find that bug fixing is a good way to stay active in the building process as it gives me a chance to review code and perform some ad-hoc testing in the project.
But while it is important to remain “hands-on,” I think there is a function of project management that provides essential value to a project and will never become irrelevant, especially in the context of consulting. That function is communication with the client and maintaining a positive client relationship. More often than not, problems that come up in projects are due to lack of communication and have little to do with technical limitations. You thought the client’s main priority was feature X, but they really think feature Y is critical to their application’s success. The client heard you say feature Z was possible in a short amount of time, but didn’t understand the caveats you laid down. The “boss-less” companies such as GitHub and Valve have the luxury of defining their own visions, but good communication is still essential to a successful project and a great personal asset to have no matter what role you fill.
Whether you seek to stay down in the trenches of code or work your way up to pointy-haired status, you can only benefit from learning to be a better communicator. Two resources I find valuable that discuss these topics are the randsinrepose blog and the Manager Tools podcasts.
(image by DailyPic)