What do you think?
Rate this book
Idea Flow: How to Measure the PAIN in Software Development
A modern strategy for systematically optimizing software productivity with a data-driven feedback loop. By measuring the pain or “friction” in developer experience, we can identify the biggest problems, understand the causes, and run experiments to systematically learn what works. It's data-driven software mastery.
- GenresTechnologySoftware
143 pages, ebook
Published April 5, 2016
2 people are currently reading
138 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 5 of 5 reviews
May 3, 2016
This is a self-published book that covers a lot of ground, and it has some flaws. If you've seen the movie Real Genius, reading this feels sort of like a conversation with the character Jordan -- a non-stop high velocity flow of ideas (sorry, couldn't resist) that can be roughly organized and overwhelming at times.
But the ideas themselves? They are crazy thought provoking. This book has me thinking a lot, and I think you could choose almost any section of it and dig into the ideas for weeks before coming up for air. This book will definitely require a re-read to fully explore what I've discovered from reading it, and I expect to find it just as fascinating the second time through.
As the subtitle might have you guess, this is primarily focused on solving painful projects. As I read the book, I thought back to various projects I've worked on where Idea Flow could have made a tremendous difference in our ability to identify the correct problems, and sell the executives on why we needed to invest in fixing the root issues identified. I've recommended the book to several folks who are currently working on projects that have a lot of "pain" and I expect it will help them quite a bit. One strong reaction I have after reading the book is that Idea Flow strikes me as an idea that would be very difficult to implement as a top-down initiative. This is a developer-led movement for sure -- the amount of data that needs to be collected could easily be perceived as very "big brother"-ish (in fact, more than one developer I've described it to used exactly those words) as a management initiative. Klein's own suggested presentation supports this:
I also haven't fully figured out my own reaction here, but although I think this framework could offer a lot of value to many teams (including teams that I've worked on in the past), I'm quite convinced that the approach described here would add little if any value to my current team. Why is that? I'm not sure -- perhaps my team is small enough that the communication of ideas between the developers and code are easier to keep in sync. Perhaps it's simply that the codebase itself is small enough. Maybe it's just that the group of developers are similar enough to make ideas flow naturally. I'm also willing to concede that I may be flat out wrong. I know I'm going to be thinking through this for a while though, and trying to figure out why I think that this is true.
The book is self-published and, as with many self-published books, it occasionally flared the OCD grammarian in me. A bigger problem for me is that it was not possible to read this on my kobo for two reasons. First, the images flow off to the right of the page, so they're not fully visible. But even allowing for that, color is required for understanding the images -- you're going to have to read this on a color screen (or print it out, I suppose).
Organizationally, the book could use the hand of a professional editor as well. One example -- the book could do a better job of laying out the mechanics of how idea flow mapping works and how to read and idea flow map a little earlier and more clearly. It's not a complicated topic, but the book jumps quickly into showing idea flow maps without a sufficiently basic primer on what they are and how they work. By the end of the book, I think I understand how they work, but during the first few chapters I often felt lost.
Regardless of these small complaints, the book and it's ideas are well worth exploring. You should go read it!
But the ideas themselves? They are crazy thought provoking. This book has me thinking a lot, and I think you could choose almost any section of it and dig into the ideas for weeks before coming up for air. This book will definitely require a re-read to fully explore what I've discovered from reading it, and I expect to find it just as fascinating the second time through.
As the subtitle might have you guess, this is primarily focused on solving painful projects. As I read the book, I thought back to various projects I've worked on where Idea Flow could have made a tremendous difference in our ability to identify the correct problems, and sell the executives on why we needed to invest in fixing the root issues identified. I've recommended the book to several folks who are currently working on projects that have a lot of "pain" and I expect it will help them quite a bit. One strong reaction I have after reading the book is that Idea Flow strikes me as an idea that would be very difficult to implement as a top-down initiative. This is a developer-led movement for sure -- the amount of data that needs to be collected could easily be perceived as very "big brother"-ish (in fact, more than one developer I've described it to used exactly those words) as a management initiative. Klein's own suggested presentation supports this:
I want to make the business case to management for fixing things around here. No more chaos and working on weekends, this needs to stop. I need data to make the case to management, though, so I need everyone’s help.
I also haven't fully figured out my own reaction here, but although I think this framework could offer a lot of value to many teams (including teams that I've worked on in the past), I'm quite convinced that the approach described here would add little if any value to my current team. Why is that? I'm not sure -- perhaps my team is small enough that the communication of ideas between the developers and code are easier to keep in sync. Perhaps it's simply that the codebase itself is small enough. Maybe it's just that the group of developers are similar enough to make ideas flow naturally. I'm also willing to concede that I may be flat out wrong. I know I'm going to be thinking through this for a while though, and trying to figure out why I think that this is true.
The book is self-published and, as with many self-published books, it occasionally flared the OCD grammarian in me. A bigger problem for me is that it was not possible to read this on my kobo for two reasons. First, the images flow off to the right of the page, so they're not fully visible. But even allowing for that, color is required for understanding the images -- you're going to have to read this on a color screen (or print it out, I suppose).
Organizationally, the book could use the hand of a professional editor as well. One example -- the book could do a better job of laying out the mechanics of how idea flow mapping works and how to read and idea flow map a little earlier and more clearly. It's not a complicated topic, but the book jumps quickly into showing idea flow maps without a sufficiently basic primer on what they are and how they work. By the end of the book, I think I understand how they work, but during the first few chapters I often felt lost.
Regardless of these small complaints, the book and it's ideas are well worth exploring. You should go read it!
April 7, 2020
A great book that shows how you can make the pain in software development visible. The Idea Flow graphs show how much a developer spends developing new features and how long he is stuck because the system does not work as expected. I do not often find a book in which I nearly at every page have to say “exactly this!” and find words to describe that feeling of something should be improved. I can highly recommend this book and hope to find time to use the graphs myself to be able to show how the pain of working with some applications manifests itself in the form of delays and surprises.
August 27, 2023
ช่วงแรกระดมไอเดียเน้นปริมาณไม่ใช่คุณค่า จดและทบทวน
February 19, 2024
This book was a total gift from a matter of chance. I saw in my recommended feed a talk by the author, which I did enjoy. So then I happened to find the book and wow! It's full of extremely useful thoughts, quotes and examples of the dysfunctions within a software team can fall into.
We have read it in two bookclubs of mine now and I still spread the recommendation whenever I can. :)
We have read it in two bookclubs of mine now and I still spread the recommendation whenever I can. :)
July 4, 2017
What can you do if you take a data-driven analysis of software development? You start to see actual problems, and you push back against the mindset of the "to-do list for success" --- that is, against the idea of just following the "best practice" (time-boxed releases, test automation...) and everything will be okay. Instead of that, measure the real problems on your project and solve them.
The methodology in here is to record conflicts between what you expect during development, and what happens. Record how long it takes to resolve the conflict. Try to group these. Then try to understand the causes.
I think a big idea here is taking the measurement of pain, and mapping it into the kinds of processes manufacturing has been using around quality. I don't think that has sunk in for me yet. Will probably need to re-read, or apply some of the earlier ideas in the book first.
The methodology in here is to record conflicts between what you expect during development, and what happens. Record how long it takes to resolve the conflict. Try to group these. Then try to understand the causes.
I think a big idea here is taking the measurement of pain, and mapping it into the kinds of processes manufacturing has been using around quality. I don't think that has sunk in for me yet. Will probably need to re-read, or apply some of the earlier ideas in the book first.
Displaying 1 - 5 of 5 reviews