An epic treatise on scheduling, bug tracking, and triage (2017)
apenwarr.ca
apenwarr.ca
An epic treatise on scheduling, bug tracking, and triage - https://news.ycombinator.com/item?id=15912929 - Dec 2017 (65 comments)
Before you disagree, consider how many other professions have pair-working in any shape or form. Is there any pair-management going on? How about pair-assembly line working? Yes, multiple people work on an assembly line - but they are performing different tasks, not just checking up on each other in real time, 8 hours per day! People work in teams, I get that, and it requires interaction between team members. But name me one team where there are two people permanently assigned to literally the same task, with no goals other than 'improving efficiency'. It's just amazing that anyone would put up with that.
I assume assembly line workers also pair work while the new worker is getting up to speed.
At any rate, the more you're working in a large team, the less your programming should be "an intensely personal task". We have style guides for a reason...
> You can produce 20% more by hiring one more person for your 5-person team, and nobody even has to work overtime. Forget it.
not to take away from the original point of the author, but unless a team/software/business is architected for scaling up-front, just adding another person rarely nets a linear increase in output, and sometimes actually reduces itIt's difficult to give a single recommendation, because it's a broad topic that branches off into several important directions. A continuously improving learning organisation takes many interlocking ideas to work, relating to long-term value powered culture, economic and probabilistic reasoning, uncertainty reduction techniques, including running experiments and gathering data on them, and analysing that data. But more important than running experiments are figuring out where the heck you stand and where you want to go. Just knowing that gets you halfway there.
----
These first four I would consider mandatory for anyone interested in this kind of stuff.
- Out of the Crisis or The New Economics (I keep confusing these with each other because I read them after each other -- well, you've probably read these already given your comment)
- The Machine That Changed the World (this seminal study introduced the industry to the idea of lean manufacturing, and it tells you exactly how important the ideas of lean/flow are)
- Principles of Product Development Flow (the author is a guru in applying lean/flow ideas to product development and teaches you to not blindly apply lean manufacturing ideas to development, but to adapt them to the economic conditions of development)
- Lean Product and Process Development (an opinionated but very intriguing view on how product development should be done, with focus on building a learning organisation)
----
These next ones are a little less mandatory and not necessarily extremely topical, but still interesting.
- How To Measure Anything (before you collect data the most expensive way possible -- with experimentation -- try estimation using proper techniques first; it's really cheap and surprisingly good)
- Understanding Variation (a good introduction to statistical process control, which helps you interpret your operational experience)
- Learning To See (value stream mapping is a way to visualise some wastes in processes)
- Accelerate (huge, impressive study of what high performing development organisations do differently)
- Drive (primer on the psychology of motivation)
- Trustworthy Online Controlled Experiments (there are probably better books on experimental design -- I've been eyeing some of Deming's myself -- but this one is probably as good a primer as any)
- The Flaw of Averages (to get more accurate predictions, focus on distributions and ranges, not single numbers)
- Toyota Kata (a rote way to build a culture of continuous improvement)
- Making Software: What Really Works, and Why We Believe It (general high-quality exposition on evidence-backed techniques -- maybe not strictly in the scheduling/project management realm)
- Rapid Development (like Making Software except older and thicker)
- Turn the Ship Around (case study in applying some of these principles to completely change the performance of a team)
- Lean Enterprise (more on how to adapt lean ideas to the whole development organisation, with case studies, IIRC)
- Willful Ignorance (what are probabilistic statements, really?)
----
I have many more recommendations if you want to go deeper into a specific sub-topic, but this is probably enough for a cursory comment.