14. What Is Good Technology?
The Problem: Working and Being Good Are Not the Same
In front of a subway gate, an elderly man taps his phone screen again and again. The app is up to date, and the server response time is fast. But the text is small, and the error message says only, “Invalid request.” As people wait behind him, he eventually asks a staff member for help. The system worked. Authentication succeeded, payment was processed, and the failure rate remained within its target. Yet it would be difficult to call this scene an example of good technology.
In engineering, the word “good” is often translated into metrics such as performance, scalability, and reliability. Those things matter. A slow system or one that frequently stops can be violent toward its users. But there are losses that metrics do not capture: an experience in which the user cannot tell why they were rejected, automation that takes away choices, data that cannot be corrected, and decisions whose owner cannot be found. Good technology is not merely technology that satisfies requirements. It is technology that enables people and organizations to understand, bear, and revise its consequences.
The Philosophical Question: Technology's Value Is Not Determined by Its Results Alone
If we see technology only as a tool, the standard for evaluation becomes simple: how quickly and cheaply does it achieve its purpose? But technology changes people's behavior and relationships as it carries out a purpose. Even when the result is the same, the experience and distribution of power change depending on the path taken to reach it.
Suppose a lending model has become more accurate than its predecessor. What if its overall approval-prediction rate has risen, but applicants cannot learn why they were rejected and have no channel through which to appeal? The model may have improved statistically while regressing institutionally. Accuracy describes the quality of an outcome; legitimacy describes the conditions under which that outcome is produced and can be challenged. Good technology does not choose between the two. It improves accuracy while designing the level of explanation, the reconsideration process, and the ability to correct data.
Autonomy here is not the formal choice of “you do not have to use it if you do not want to.” Users must be able to understand the consequences of a choice, reject or reverse it, and leave the system without losing every relationship connected to it. An editor that does not let users turn off autosave, a subscription service that hides its cancellation button, or a platform that restricts its entire functionality when a user rejects recommendations may appear to offer convenience while actually reducing the user's bargaining power.
An Engineering Case: Good Design Reveals Itself at the Moment of Failure
A demo of the happy path can make almost any product look beautiful. Enter an email address, press the green button, and see the success screen. But real users upload the wrong file, press a button in airplane mode, lose a permission, or receive a phone call halfway through. Good technology does not stop at making success smooth. It makes failure explainable and recoverable.
A file-upload service should distinguish what went wrong instead of simply saying “Upload failed.” It should say whether the network was interrupted, the file format was invalid, or the permission had expired, and, where possible, resume from the point at which the upload stopped. Not making users wait through the entire process again is both a performance optimization and an expression of respect. Deletion works the same way. Destructive actions should have clear confirmation and a grace period, along with a path to recovery. An operator should not have to be someone who never makes mistakes; the operator should be able to resolve a mistake after it happens.
In organizational decision-making, good technology can conflict with short-term results. Investing in observability does not immediately increase the number of customer-facing features. Granular access controls for internal tools make the workflow somewhat slower. Continuing to patch an old module instead of replacing it may make this quarter's goals easier to meet. But these choices do not eliminate costs; they move them onto other people and into the future. A good organization does not hide that transfer as “a technical detail.” It counts on-call hours, recovery time, churn, and repetitive work for the support team as parts of product quality.
Objection and Tension: Good for Whom?
“Good” is not a neutral word. A convenient feature for one user may be surveillance for another. A forced update that gives an operations team stability may feel like control to workers in the field. There are cases in which a design cannot be good for everyone at the same time.
Engineers should therefore resist turning “the user” into a single average. They must consider not only the people who use the system most often, but also those who experience the greatest failures, those with the fewest resources to absorb an error, and those who find it difficult to refuse the system's decisions. Instead of pretending conflicts over priority do not exist, they should make them visible and record who benefits and who bears the burden. Accessibility reviews, threat modeling, privacy impact assessments, and decommissioning plans are not decorative processes that delay a release. They are practices that expand the scope of what “good” can mean.
Questions to Leave With
As much as we ask how well this technology works, can we ask who can understand and repair it? When it fails, can the user receive an explanation, reverse the outcome, and appeal to a person? As our metrics rise, are someone else's choices quietly shrinking? Good technology demands a harder standard than convenience. Instead of forcing people to fit the system, it asks the system to endure the complexity of people.