[candeira]

I'm currently reading Marianne Bellotti's Kill It With Fire, which is about upgrading and maintaining legacy projects. It's more about meta-software-architecture (how to think about choosing and replacing architectures) than about software architecture itself.

It's very well written and full of useful insights for practitioners, while using language and descriptions that would be approachable to the layperson. This seems like a book that an engineering manager and a product owner can read together to better understand the shared endeavour of upgrading a legacy service.

Halfway through Chapter 3, I haven't learned anything I didn't know... but on the other hand, I find myself in violent agreement with each one of the author's points. And though it's a book that's well written and could be a breezy read, I find myself stopping to ponder on he consequences of each paragraph.

One great aspect of this book is that Bellotti was trained as anthropologist, and she brings the analytical tools of her studies to the human aspects of software development. The book offers a vocabulary/framework for the software development process, legacy or not, and better models for framing our own professional experiences when approaching client work.

Heartily recommended.

[Xunjin]

Can I be the "lazy person" and ask which are the author's points?!

[candeira]

> Can I be the "lazy person" and ask which are the author's points?!

Yes, you can, and I can be the hurried person with no time to summarise, and recommend you read the book yourself. It's not like those business books that have a single thesis, backed by 100 examples to support it, where the thesis itself can be written on the back of a stamp.

I can however try and describe to you what the book is about.

It's a book about how legacy software interventions are about the people as much as about the code and the machines, with advice for aligning incentives between stakeholders, developers and managers,

It's about prioritising competing goals under different sets of constraints, with useful advice for ensuring psychological safety in your team.

It's about measuring risk, and acting on the measurements.

It's about anthropology of software-using organisations, and about organisational design, and how those disciplines inform the job of recovering wayward software projects. It's not a book about computers, or about programming, or even about software management. It's about people in organisations doing all of the above.

It's about defining the right job to do lest you attempt to do the wrong job right.

It reads like an instant classic, like a "missing manual" for running software development operations in big organisations... but with advice that's also applicable at smaller scales.

I just finished reading it and I started on Chapter 1 again. It's that good.