My Agile Reading List
I came up with the following reading list, which interestingly, doesn’t include any books with the words agile or SCRUM in the title!
Though this is a relatively new book, I believe this is the one that has been the most beneficial to me as a developer. All of my jobs in software development have had significant operations components – building and packaging releases, automated testing, configuration management, deployments etc. Bringing the spirit of automation and repeatability to this in the aim of being able to deliver faster, more repeatably, with less effort is a huge area of low hanging fruit for software teams.
Growing Object Oriented Software
I have used test driven development for a number of years, but this book really bought home how we can relentlessly use tests to optimise the design, clarity, and quality of the code and eventually the products that we are building. I believe that automated tests at multiple levels of abstraction are absolutely fundamental to agile delivery of software, and that you need to adopt TDD as a fundamental practice if you are going to deliver complex software as early and often as agile and nowadays continuous delivery implies.
The Pragmatic Programmer
This is the first book that I read which made me start to think of development as a process that is much bigger than simply writing code. Things such as your tools and environment, your team, your tools, your testing strategies, your attitudes and your approaches to problem solving and learning. All of the items discussed in the book are fertile areas for optimisation which can provide a net benefit to your software product and team. The Pragmatic Programmer is all about working smarter, not harder, which is something I try to keep at the front of my mind during the day job.
Peopleware concentrates on the human side of software development work and backs up the claims with reference to real data. Most techies and managers would think it was a little fluffy to talk about concerns such as how the office is laid out, working hours, the need for flow, dress codes etc, but software development is a team sport and the human factor is always more prescient than we give it credit for. By improving tools you can improve productivity in small increments, but by improving the situation, working practices, and motivation of your people, you’ll likely gain out-sized benefits for relatively small investments.
This is not a software book but focuses on system operations and ‘systems thinking’. If we step back and look at most working software teams, they’re generally part of some broader system providing inputs (requirements, bugs) and outputs (working software, bugs!). And like any system, this broad end to end process incorporates bottlenecks, constraints, feedback loops, inefficiencies etc. By stepping back and viewing the system, we can optimise it and smooth out the workloads, making some really quite substantial improvements to the throughput of the system and the quality of the outputs.
This is a really readable and very broad book that really brings home the fact that your application lives and operates in some context that can cause you unexpected problems – a changing user base, integration points, components outside of your control etc. As junior developers we think that writing software is simply about writing code, when in reality, it’s the kind of stuff and scenarios discussed in this book which end up giving you more problems, and which can make or break the success and perception of your application.
So that’s my list. I think what all of these titles have in common is that they are all about the things that developers need to spend time on that is slightly around the edge of the act of physically writing code. All of this extraneous stuff has huge potential for optimisation, but has traditionally just been left to evolve without any critical thought and with minimal attempt to improve upon. These books are great starting points towards this broader focus.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)