Table of Contents
- Breaking It Down (Part 1)
- Persistence (Part 2)
- The Challenges of Persistent Information
- Source Code and Software Assets Are Data Too
- Software Entropy and Long-Term Maintainability
- Project Management Generates Persistent Data
- Garbage In, Garbage Out: When Bad Data Distorts Decisions
- Conclusion: Treat All Project Information as an Asset
- Further Information
- Frequently Forgotten Factors (this part)
X & DX: Why you need both
- UX makes users actually want to use your app.
- DX makes developers actually want to build and maintain your app.
One creates value. The other keeps your team sane and your costs under control.
What Makes a Difference
Whether you're building for users or developers, remember:
- People make mistakes—design for the unhappy path.
- People are trying to get things done—don’t block them.
- The more frequently something is done, the easier and more visible it should be.
- If information is required to make a decision, make sure it’s visible at the moment of decision, not buried somewhere else.
These principles apply equally to user interfaces and developer tooling.
UX & DX: Neither Comes Free
A great user experience (UX) and a joyful developer experience (DX) don’t appear by accident. They take deliberate design, thoughtful architecture, and—at some point—someone insisting that the quick-and-dirty way isn’t good enough.
It’s easy to throw together a working prototype without considering UX or DX. But here’s the trap: the moment stakeholders see that it "works," they’ll want to ship it.
If that prototype becomes the product, things fall apart fast. The flaws that were acceptable in a demo become frustrating in daily use. Stakeholders, forgetting their own impatience, will blame the developers. And if the team pushes forward anyway? Time they could have used to drive the project forward they are now spending ensuring they are not going backwards. They are throwing together patchwork fixes to minimise the damage of an application that is now the face of the team, an application never intended to support real users or real workloads.
The Rule of Three
(a.k.a. Why This Will Take Way Longer Than You Think)
There are two versions of the Rule of Three—and because software people love recursion, each version has two parts.
Both point to the hidden costs of building software that is reliable, usable, and maintainable.
Version 1: The Mythical Man-Month Edition
This version deals with whole applications:
- If you’re going to use a piece of software more than once, it’ll take three times longer to build than a throwaway script.
- If more than one person needs to use it, multiply that by another three.
That’s a 9x effort multiplier—before you've even polished the UX or refined the API.
Version 2: Facts and Fallacies of Software Engineering
This one focuses on reusable components:
- Making a component reusable takes three times more effort than building it for a single use.
- To prove it's truly reusable, you need to use it in three different apps. Until then, you’re relying on hope rather than evidence
Skipping UX and DX might save time up front—but it guarantees pain later.
Networking: It’s fine, until it isn’t
- Do you want to support offline work?
- Do you want to reconcile when you reconnect?
- Do you cache?
- If so how much?
Third Parties: You’re Not in Control
- Their schedule isn’t your schedule.
- Their uptime isn’t your uptime.
- Their API changes don’t ask for permission.
In Conclusion
- Respect complexity
- Align intent, concept, and implementation
- Plan for persistence
- Care about UX and DX
- Expect change—and design for it
Books
No comments:
Post a Comment