Sunday, August 3

Developing Useful Applications (Part 3) UX & DX

Table of Contents

 

UX & 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, your 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

If the application is using network resources. There are a host of issues around latency and connectivity. 
  • Do you want to support offline work?
  • Do you want to reconcile when you reconnect?
  • Do you cache?
  • If so how much?
The technology is well established, so its not a big deal, but it is still something that needs to be managed.

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.

SLAs and contracts help—but they're not magic.


In Conclusion

Toy programs teach, they prove concepts, they delight.

Real applications? They endure. They support users, survive entropy, and evolve with time.

To bridge the gap, you need to:

  • Respect complexity
  • Align intent, concept, and implementation
  • Plan for persistence
  • Care about UX and DX
  • Expect change—and design for it

Because software that works once is a demo.
Software that keeps working? That’s the job.
 

Books

Facts and Fallacies of Software Engineering by Robert Glass, Paul Becker, John Fuller
Posted by at
Labels:

No comments:

Post a Comment