💾 Archived View for johan.egneblad.se › why-should-users-trust-us.gmi captured on 2023-11-04 at 11:36:50. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-03-01)

-=-=-=-=-=-=-

Why Should User Trust Us?

There is a lack of trust between users and developers. This lack of trust is well earned by years of abuse from us, the developers, of the users. It boils down to communication, or the lack of good communication. Historically, if you ask a developer how long it would take to implement feature X, the answer would always be "two weeks", no matter how big or small the feature is. Even fka twigs commits to that deadline. This led to massive underestimates on a lot of features. This is the think we grew up to learn, developers always underestimate to initially please.

What came after that was the opposite, and that's where we are now. We, with the help of Agile Methodologies, became experts on time estimation, or rather saying that things would take a lot longer than people (stake holders) would expect, and be much more complex than they would be able to understand, so we might as well not do that thing that they need and try to find something else to do that is more aligned with the Roadmap and/or more fun to implement. I am guilty of this all the time. I do it because I have seen what happens if just build everything they ask for in two weeks and never look back.

But what is the purpose of software? Why are we paid to build software?

One might definitely wonder that when the expectations on apps with whole armies of developers behind them perform as reliably as Soviet car would do today. The Googles, Microsofts, fruits, Facebooks and Amazons of this world have taught us that making good software is practically impossible, because if they can't do it properly, who can? Users give up on software, but still use it because there are no alternatives and we are heavily addicted.

So when I as the most common type of developer, I suppose, build a tool that is used internally in a company, the users use it, because they are told to, see the bugs and report them to me and my team so we can fix them which we do immediately. No. That's not what's happening. They do as they learned how to do with software. They learnt that they have no say about software and it will never get any better, so they find a workaround. When asked, they say it's fine. This is the Reversed Expectation Management Problem. Users have too low expectations to even feed back on their user experience. We have to actively extract by asking and asking again and again.

A colleague of mine told me we should just give up this interaction and instead remote log everything via Sentry or similar. I don't want that to be true. I want to build a relation with the users where they feel empowered. We can't do everything they wish for but we should at least respond to everything. And rather quickly, so they know we care. We should prioritize any feedback we get, over other bug fixes, over new features, over documentation and over writing unit tests. Responding to feedback is the most important thing. The users are not our masters but they are our raison d'être. We can never forget that.