I read Baldur’s book “Out of the Software Crisis” a while back and have been meaning to publish some of my highlighted excerpts and notes.
It’s always hard reading a book like this because I highlight so much and have so many thoughts that I could spend hours and hours rehashing it all.
But alas, there’s no time. So it will have to suffice to say: I enjoyed the book, here are a few excerpts I want to note for future reference.
(Oh, and once I finish them, I’ve got a few other blog posts with added excerpts/commentary from the the book.)
In web dev, money follows novelty:
The programming pop culture defines change—any change—as progress.
Software is a holistic problem:
Brilliant code with a poor interface is a poor app. A thoughtful and effective design backed by trash code is a trash app. Software is a holistic problem.
Lol, this description of modern software:
We throw two half-baked unfinished designs into a functional shipping application that people rely on to do their work and use Data™ to see which unmitigated disaster is marginally less disastrous for the working lives of those held hostage by our applications.
In software, churn is self-sabotage:
Churn is devastating for software quality as it destroys institutional memory and sabotages many of the fundamental mechanisms of programming, which require stability and consistency.
You can make a living on crappy software:
You don’t need good software to make money in software…[you can] capture a corner of the market with barely functioning software.
Process exists as a feedback loop:
Processes aren’t about managing the team or the project. They are feedback loops that provide elements of the system…with the information they need to adjust flows.
Software quality is a people problem, it needs to genuinely understand and care about people.
Designers push pixels, but you don’t hire them for that:
[aesthetics are] part of what design does. It isn’t what you hire designers to do.
Programming is more akin to design than engineering:
From a systems-thinking perspective, programming is not in any way, shape, or form an engineering discipline. It doesn't work like engineering; it doesn't manage like engineering; it does not have the consistency or reliability of engineering; it does not have the outcomes that resemble those of engineering.
Software development is a creative field. It has more in common with filmmaking than it does with bridge-building.
you need to collect good software, try it, experience it, and get to know what well-made feels like
Agile became the villain it was born to defeat:
Agile is a reaction to the trauma of bad management.
Agile wasn't progress. At its heart, it was a coping mechanism whose acceptance gave us a temporary respite from the still pervasive mismanagement of software until, inevitably, the machinery of agile was coopted and became integral parts of the broken system we were trying to fix.
The best tool: mindfulness.
You try a new thing. It works for a while. Then it doesn’t; because what worked was the change which forced you to pay attention to what you were doing.
Good software is built on top of people questions, not technical ones. Static types or unit tests don’t address these fundamental questions:
- What is good management?
- How do we prevent escalating complexity?
- How do we prevent harmful software? Software that's harmful to society, culture, the workforce, or the environment?
- What is good software?
- How do we recognise good software?
- How do we develop a culture for talking about, analysing, and enjoying well-made software?
- Are we in a position where we can even tell whether our software is good?
- Do we have any capacity to acknowledge that the quality of our software is declining?
- Or, not increasing when it should?
- Are we capable of recognising when the process serves the product's end-user?
- Or, when it's not?