HackerNews Readings
40,000 HackerNews book recommendations identified using NLP and deep learning

Scroll down for comments...

Sorted by relevance

nradovonJan 20, 2016

For a more detailed explanation of the importance of minimizing work in progress (i.e. inventory) I highly recommend "The Principles of Product Development Flow" by Donald G. Reinertsen. It contains a thorough economic analysis based on queuing theory.

http://www.leanproductflow.com/buy-the-books/

mason55onNov 9, 2019

Yeah if we are comparing software to manufacturing, the books I prefer are “High Output Management” and “The Principles of Product Development Flow

jrs235onJune 5, 2020

I need to reread The Goal again.

"people are trying to fallaciously optimize on cost rather than marginal profit."

Pure truth.

Another great book is The Principles of Product Development Flow: Second Generation Lean Product Development

klenwellonOct 5, 2019

A favorite quote of mine from Donald G Reinertsen's Principles of Product Development Flow:

I used to think that sensible and compelling new ideas would be adopted quickly. Today, I believe this view is hopelessly naive. After all, it took 40 years before we recognized the power of the Toyota Production System.

devdasonDec 7, 2019

Goldratt is excellent for optimising processes with well defined goals.

This is ofen true in business software.

If you want to optimise a learning process, The Principles of Product Development Flow is more relevant.

The two books (The Goal vs The Principles of Product Development Flow) give very different, seemingly opposite advice.

jrs235onMay 9, 2018

The Principles of Product Development Flow: Second Generation Lean Product Development

It changed my understanding and thinking about how best to work flow development. I highly highly recommend this book to coders to managers.

sdoeringonMar 3, 2020

The Goal is currently on my list after having read "The Phoenix Project". Thanks for also giving me additional material with "Principles of Product Development Flow".

ianmcgowanonMar 26, 2021

If you haven't already, check out the oft-referenced book "The Principles of Product Development Flow". Based on this comment you'd really like it.

http://www.startuplessonslearned.com/2009/07/principles-of-p...

stretchwithmeonMay 5, 2021

Seems like some of the same ideas in Donald Reinertsen presents in his books and videos. He thinks in queues and the cost of delay.

The cost of delay when you try to keep everyone busy all the time.

I'm reading his book The Principles of Product Development Flow.

klenwellonNov 12, 2020

On that question, I've quoted this here on HN before. From Donald G Reinertsen's Principles of Product Development Flow:

I used to think that sensible and compelling new ideas would be adopted quickly. Today, I believe this view is hopelessly naive. After all, it took 40 years before we recognized the power of the Toyota Production System.

I read this book on the strength of some recommendation here on Hacker News. It is quite relevant to this general topic:

https://www.goodreads.com/book/show/6278270-the-principles-o...

calibraxisonAug 1, 2016

Don Reinertsen mentioned it. At least in a talk, and maybe in his book "The Principles of Product Development Flow".

That's only 1 example, but in my personal estimation he's one of the two most effective management theorists I know. Though I wish he were a better explainer. (The other of course is Shanley Kane.)

knightofmarsonOct 3, 2016

I second this. Additionally, get a grip on your queues!

I have yet to find a better text on how to properly manage software projects than, "The Principles of Product Development Flow: Second Generation Lean Product Development"[0].

[0] https://www.amazon.com/Principles-Product-Development-Flow-G...

klenwellonFeb 17, 2019

So having read the article, why does limiting work-in-progress work? Because it allows you to finish more work that you start? I struggled a little bit initially with the generic concepts used for modeling. But I suppose the real insight is that, focusing only on these 3 basic parameters (work started, work finished, and number of developers), you can get wildly different results. Is that a fair reading?

This is a topic to which I've given a fair deal of attention in leading software development teams using scrum. Especially after reading Donald Reinertsen's Principles of Product Development Flow, where he approaches this topic in more depth:

https://www.goodreads.com/book/show/22586058-the-principles-...

Limiting work-in-progress was a major principle in Reinertsen's book. Another related one which I've applied successfully in practice: limit batch size. In my case using scrum, this meant keeping user stories within a certain size range (2-5 points).

This has an important benefit: it controls scope creep. It does this a couple ways: 1. It's helps during planning avoid overlooking complications or other costly delays before works gets started. 2. When a story starts to creep during development, you tend to catch it sooner and control it more effectively.

Which helps get stuff done, which helps limit WIP, which as the article suggests helps get stuff done.

stretchwithmeonMay 8, 2021

Some of the same ideas, like cost of delay, are presented in The Principles of Product Development Flow.

kqronDec 31, 2020

This was one of the things that made me look into lean manufacturing (book recommendation: The Machine That Changed the World) and lean product development (book recommendation: The Principles of Product Development Flow). The latter is more relevant for software systems, but the former was very good to have read first to see where software is different.

These areas can teach us a lot about the dangers of queues and how to handle them carefully.

deyanonSep 16, 2011

Thanks, I will check those out.

To add: I highly recommend Principles of Product Development Flow (http://www.amazon.com/Principles-Product-Development-Flow-Ge...) - incredibly difficult book to read (i.e. lots of good but dense information) but it explains well the underlying principles - and thus goes beyond the buzzwords.

akoonMay 27, 2019

There's pretty good theory behind the idea of minimizing latency to improve throughput. One of the better books on this is "Managing the Design Factory", and a followup called "The principles of product development flow".

These books are not about software development, but of product development in general. The first one actually predates agile, published in 1997.

Core idea is that minimizing the size of the tasks is the best way to improve productivity. Not getting it done as quickly as possible, but to decrease the size.

Remember that product development (new, innovative, uncertainties) vs product manufacting (repeatable), is not a new problem, and not unique to the software industry. There's a lot to learn from product development in other industries.

Another interesting read is "The Toyota Product Development System: Integrating People, Process And Technology" which talks about ways of making product development predictive, and less risky.

It's interesting to see how little software is used to improve the process of software development. Other industries use a lot of software (cad/cam, visual modelling, testing, impact analysis) to improve efficiency and quality of product development. Software for product development is a huge market.

shooveronOct 15, 2017

I’m surprised that Don Reinertsen’s book The Principles of Product Development Flow doesn’t come up in these discussions. Rich Hickey mentioned it once after a conference years ago and that’s the only time I’ve heard it mentioned. I’ve since found a few blog posts responding to conference talks (of which there are several on YouTube from around 2015), but not many. I think people simply don’t know about it. I wrote it down at the time and finally digested it over the past several months. It’s an incredible book that I think would resonate with many of the commenters here.

I think of Reinertsen’s approach as industrial agile, in the most honorable sense of industrial. There is theory and some math. There is heavy emphasis on project economics as a means of making complex trade-offs and a basis for training, deputizing, and expecting employees at all levels of an organization to make better decisions on the fly as part of doing their jobs. Lessons are drawn from many fields, such as network communications, queueing theory, and the Marines. Contrasts are drawn with manufacturing to explain exactly why some of the techniques we adopt do not apply in product development but where many techniques from kanban systems do apply.

The book is organized around hundreds of principles given as tools, to be considered and applied as needed to your specific situation. Annoyingly, he refuses to get into implementation. At first I thought he was saving pages, but the more I think about I realize the seeming omission was necessary genius. Digging into even one example implementation would result in the death of the message and framework as people copied that and get dogmatic about a methodology all over again.

The whole presentation is beautifully constructed and tight. It puts a perspective and language on things in a way that makes me hopeful and interested in project management, similar to how Rich Hickey’s talks raise my understanding, vocabulary, and aspirations for software engineering.

I would welcome anyone involved in prioritizing commercial software projects to read and discuss this book (and document their implementations).

nyootrononApr 12, 2021

We're a bootstrapped team of 2. We don't find people thinking like this. It was a question. I answered in the affirmative.

We have bet all our savings on saying a bold YES to this question. I think we have the right to comment here. We've spent a good 15 months thinking about this problem.

We've read a ton of material. From the Principles of Product Development Flow to Joel Spolsky's article on Evidence-based Scheduling, distilling everything down into our product.

When you make something, and run into trouble finding early adopters, I'd like to hear all your thoughts on self-promotion.

wpietrionNov 23, 2017

Franz de Waal's "Chimpanzee Politics". It's nominally about the social relationships of a chimp colony in a Dutch zoo. But it made me see the extent to which humans are just another great ape, and a lot of human dynamics are really primate dynamics, especially around social power.

Johnstone's "Impro". It's about improvisational theater, and mainly meant for people learning improv. But the section on status transactions helped me see a lot about how we express those primate dominance dynamics. There's also great material on the nature of creativity.

"Getting to Yes" is a great book about business negotiation, but is lessons about shifting discussions from zero-sum to positive-sum are things I use a lot.

Braitenberg's "Vehicles: Experiments in Synthetic Psychology" is a way of thinking about psychology (and our inference of mind) by examining imaginary robots.

"The Toyota Way" and other books on Lean Manufacturing are about running extremely effective manufacturing operations. But they have deeply changed how I think about systems of making software and running businesses. Other great books in this category include "Toyota Kata" and "Principles of Product Development Flow".

"Crossing the Chasm" is about how tech products get adopted. But its mindset around segmenting audiences and building credibility taught me a lot about any sort of social change.

"Why Does He Do That? Inside the Minds of Angry and Controlling Men" is nominally about abuse in romantic relationships. But its insights about power and control have been useful to me way beyond that. E.g., so much behavior in large corporations is inexplicable if you look at it in business terms, and perfectly sensible if you think about if from the perspective of, "What would a person with abusive tendencies gain from this situation?"

Also, hearty +1s for books "Design of Everyday Things", "Finite and Infinite Games", and "Punished by Rewards".

mjbellantonionDec 23, 2014

Agreed! I recommend reading "The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G. Reinertsen, which while not actually about Scrum, explains a lot of the useful underlying principles at work in Scrum -- like queueing theory.

brightballonMay 7, 2020

This hits on exactly why I was drawn to SAFe.

After all the feedback I got from this...

https://news.ycombinator.com/item?id=17154355

Someone pointed me to Reinertsen's Principles of Product Development Flow book, which put into numbers and models everything I'd been trying to say (and then some).

It worked great with my team, but I was failing hard at communicating and involving everyone on the business side so I started researching for something that provided the business side, wrapped around his methods. Which drew me to Scaled Agile Framework.

There's a lot in it, but the core of it is simply on a pace of 8-12 week increments, you spend 2 days letting your developers provide you with a plan, estimated based on 2/3 of their actual available time. They make the plan...not management.

The plan is presented to management, management discusses tradeoffs and options, then ultimately management will accept a final plan and the developers provide a confidence level in their ability to deliver the plan that they have set out.

When new requests come in, they are discussed for the next 8-12 week increment so the developers can focus on executing the plan that everyone agreed on.

There's still room left for small things that come up, there are progress check-ins and communications that happen along the way. Risks to the plan are identified and discussed so everyone is aware of them up front. Variability is assumed (up and down) throughout the plan. The only assumed commitment is to the 8-12 week deliverable. Nothing in between is expected to have a guaranteed delivery date.

It leaves little room for surprises and plenty of room for people to work in a reasonable manner. I can't speak highly enough of how effective it is to addressing this problem.

knightofmarsonApr 5, 2018

The Principles of Product Development Flow: Second Generation Lean Product Development

by Donald G. Reinertsen

https://www.amazon.com/Principles-Product-Development-Flow-G...

lfy_googleonSep 24, 2018

There's also "The Machine That Changed the World":

https://www.lean.org/Bookstore/ProductDetails.cfm?SelectedPr...

Generally, anything auto manufacturing related works too.

Also:

"The Principles of Product Development Flow: Second Generation Lean Product Development"

https://www.goodreads.com/book/show/6278270-the-principles-o...

We see a lot of words written on "lean" software development but I feel like it's better to learn from broader sources, and from industries that have had a lot more regulation and time to develop good practices.

jrs235onMay 25, 2018

Have you read "The Principles of Product Development Flow: Second Generation Lean Product Development" by
Donald G. Reinertsen?

NyxWulfonOct 16, 2012

The arguments advanced against an "Operations mindset" are mostly strawmen. Operations is primarily about efficiently operating an organization towards a goal. The type of thinking advanced in the article however is more likely to be pushed by someone with no operations management training.

For instance, putting people on multiple projects versus single projects. Multi-tasking and context switching cause known losses in efficiency even under the perfect scenario with no startup time. So if you want to emphasize getting projects completed, multi-tasking must go. This is an operations management mindset, though it runs against much current practice.

The points about efficiency are similarly misguided. You don't focus on worker efficiency, operations points you at throughput and global optimization rather than local optimization.

Those however are about focusing on improvements and operations of the current systems. It is true that innovation is different than operations. In the same way that learning to program efficiently in a language is different than inventing a programming language. They are different kinds of things. Many operations principles however can be successfully applied to innovation. For an excellent read on the topic, read "The Principles of Product Development Flow" by Reinertsen.

To get a better understanding of operations in general, and not the hyperbole advanced in the article a good starting place is "The Goal" by Goldratt.

One big revelation I learned while studying operations is that the things that largely drive developers crazy aren't good management practices. They aren't advanced by operations researchers. They are in fact what I always thought they were, bad management practices.

klenwellonFeb 1, 2019

This reminded me to look up the "Metrics for Flow-based Product Development" that Donald Reinertsen lists in Principles of Product Development Flow (Figure 8-6).

The difficulty would be in defining and quantifying these concept -- things like Cost of Queues, Transaction Cost per Batch, or Trends in Cadence.

My team, inspired in part by Reinertsen's book, has already optimized batch size (i.e. user story size) with noticeable positive effects. I guess the KPI could be maintaining certain parameters rather than assuming they need to be improved.

Thanks. This does remind me that this is an area I wanted to explore.

jrs235onFeb 3, 2018

The one I'm about to finish: The Principles of Product Development Flow: Second Generation Lean Product Development [1]

Wish I had read this years ago! I think every developer can benefit greatly from understanding these principles. Plus if they were more widely known and adopted it would be easier to get other managers to go along with them.

[1] http://amzn.to/2GL17hs (affiliate link)

reginaldoonJuly 31, 2012

The book linked from the show is The Principle of Product Development Flow: Second Generation Lean Product Development.

Link (no affiliates): http://www.amazon.com/The-Principles-Product-Development-Flo...

calibraxisonMar 5, 2015

Not knowing much about him, let's throw a bunch of things at the wall and see what sticks:

- https://model-view-culture.myshopify.com/products/your-start...

- https://modelviewculture.com/

- Something by Don Reinertsen, maybe The Principles of Product Development Flow, maybe something else.

- Valve Employee Handbook http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...

- http://thinkrelevance.com/how-we-work

- Ries, The Lean Startup

All of these sources hide lots of dysfunction, so as always take them with a grain of salt. Take Ricardo Semler's fun books. In one of his Harvard Business School lectures, he mentioned how his books are artificially optimistic, because publishers want to sell more books.

devdasonJuly 17, 2020

Construction and manufacturing are usually about cookie cutter replicas, with log degrees of customisation. There isn't a feedback loop in the manufacturing line to product development once you have a stable product.

This is roughly analogous to corporate IT operations. There's a set of standard services which everyone uses, and there's no innovation on the desktop by most users.

On the other hand, with software and R&D, the feedback loops are primary drivers of generating information (and value). This is why so many of us preach about "testing in production" for web services.

The core of these two philosophies is pretty much summarised by two books:
The Goal, by E. Goldratt (ISBN: 9780884271956 ).
The Principles of Product Development Flow, by D. Reinertsen (ISBN: 9781935401001).

elliusonFeb 22, 2020

As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility.

Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half-aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned.

The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle.

The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.

klenwellonFeb 6, 2018

That's an interesting idea. I picked up this book, Principles of Product Development Flow, based on some recommendations I think I came across here on HN:

https://www.goodreads.com/book/show/6278270-the-principles-o...

Reinertsen really helps you appreciate the costs associated with queues (of which the TODO list would be a common form) and this seems consistent with the principles he advocates.

One key quote related to this that I am still trying to wrap my head around:

Few product developers are aware of the causal links between high capacity-utilization, queues, and poor economic performance. Instead, developers assume that their cycle times will be faster when resources are fully utilized. In reality, as we shall see later, high levels of capacity utilization are actually a primary cause of long cycle time.

wpietrionMar 4, 2020

> Why do you want a display of open PRs at all?

All PRs are WIP, and minimizing WIP is very valuable in product development processes. See Reinertsen's The Principles of Product Development Flow for the math, but basically high/unpredictable latency drastically limits the pace of learning and causes a lot of upstream thrash and waste.

I remember talking with one team at the bird-themed social media company that was frustrated with slow PRs; they dropped average delay from 3-4 days to under 4 hours. They said it made a huge experiential difference and they loved the change.

nradovonJan 6, 2017

If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay. For a detailed quantitative economic analysis of why this works please read "The Principles of Product
Development Flow
" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate your thinking in multiple areas.)

For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams".
http://www.innolution.com/resources/presentations/svaln-2015...

No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.

arielweisbergonOct 12, 2015

I recently read "The Principles of Product Development Flow: Second Generation Lean Product Development"[1] that was recommended to me.

Some of it was familiar. Some of it was new. The language used and how the book articulates the reasoning behind various strategies has been invaluable to me in expressing to others why something is a tractable problem as opposed to an unavoidable one that is just the cost of doing business.

To date I have not succeeded in getting anyone to read it though.

[1] http://www.amazon.com/The-Principles-Product-Development-Flo...

Built withby tracyhenry

.

Follow me on