Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs (The Pragmatic Programmers) Paperback – 9 Apr 2015
|New from||Used from|
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
Frequently bought together
Customers who bought this item also bought
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
About the Author
Adam Tornhill combines degrees in engineering and psychology to get a different perspective on software. He works as an architect and programmer and also writes open-source software in a variety of programming languages. He's the author of the popular book Lisp for the Web and has self-published a book on Patterns in C. Other interests include modern history, music, and martial arts.
What other items do customers buy after viewing this item?
Top customer reviews
By using his knowledge from psychology he also helps us understand how our informal organisational structure and team structure shapes our system. This knowledge is key to create an environment where we can grow solutions organically and move away from legacy systems.
On the whole this is a very good read with extraordinary techniques which will help most programmers and architects tackle legacy systems. Combined with Michel M Feather's Working Effectively with Legacy Code this makes such work more pleasure then pain.
If you are working in a large code base or a large team and you care about the efficiency of the code design, this is an excellent book for you. The book is not about how to design an architecture for your software, nor is it about demonstrating a perfect design pattern, but it is about shifting your focus on finding defects you often neglect or don't even think is there.
If you think you have a perfect design, but you can't figure why features take more time to implement than it used to, more and more people are involved in implementing a simple feature and bugs are hard to identify, you better think twice about that perfect design and read this book.
Most helpful customer reviews on Amazon.com
There are numerous problems with the book though:
1. The toolsets he uses as example in the book are no longer available as binaries. You have to go through searches and download compilers for obscure languages (Clojure? Really? WTF?), plus all of their dependencies, just to get his main app to work in order to follow along with examples (the compiler had to be compiled!) Those are hours of my life I'll never get back. Why put every reader though this kind of nonsense? Publish the binaries and move on...
2. As another reviewer mentioned, the correlations he draws between code history and psychological phenomena are tenuous at best. Still, there are some interesting side-stories.
3. Most of the metrics he measures are absurdly simple. Ultimately I believe that the majority of the kinds of conclusions you will draw from his analysis are already understood (perhaps tacitly) by most everyone on your team(s). For example, if you want to know where the trouble spots in your code base are (hotspots), just about any developer can tell you - you don't need metrics to point you in the right direction. 90% of time the metrics will tell you what you already know.
4. The book constantly refers back to itself (remember when we went over XYZ 3 pages ago? - yes I do), and it gets annoying. For such a short book, these constant back-references are unnecessary. The writing style, while generally breezy, is also a bit repetitive - it's a 182 page book that could have been written in 50 or less.
These criticisms aside, the book is short enough to get through in a day, and you may pick up a few gems along the way. I really liked the trend patterns his discusses, for example, and there are numerous references to other reading that can be helpful.
Adam Tornhill draws from his dual background in psychology and software development to propose innovative techniques that consider how human and social aspects affect code quality and can be monitored with new metrics. The results are both intuitive and surprising - and extremely valuable in understanding the overall quality of a software system.
Adam's ideas are demonstrated by a software versioned control system logs analysis tool - Code Maat - that he graciously made available as open source. Using Code Maat we were able to quickly identify hotspots in our code that demanded close inspection. We found issues that traditional code metrics alone like complexity and code coverage would not have been able to identify, like which modules have been modified by far too many developers, and which ones were decoupled in the design but actually coupled when it came to code changes.
If you care about code quality, don't miss this book. Highly recommended!
From the simple things like getting a view of the hotspots in your codebase, to more advanced technique that can show you the knowledge distribution between your team, you will learn a ton of useful tips in this book.
While Adam does supply some tools to use along with the techniques in the book, the emphasis has been put on giving you the ability to make use of the information on your own and not enforcing a reliability on any particular 3rd party tool.
I highly recommend this book to any developer who wants to learn more about their codebase. Personally I've used the techniques to both help me get a quick introduction to new codebases, and also to help highlight information that is useful not only to myself, but also to the rest of the development team and management.
Look for similar items by category