Just do it, why dont you?

Have you ever had a colleague who wants you to make a change in a system/service/component you own say:

Can’t you just do X in < less than a day/ a few days >?

This is typically some senior person in the other team, who’s competent in their domain and would themselves not entertain a similar request against their own system/service component. It doesnt come from a place of malice, but from a mistaken sense of how easy X must be in a domain that’s not theirs. There are also shades of the XY problem in such an ask.

Front end teams typically face it because “UI is easy, just add a button” or “Client libraries are easy, my unit tests are essentially clients to the service”. Backend teams also face it in organizations where front end is king, because it “must be a few lines of validation on the service”. In general, the dominant area of work in a company tends to trivialize the effort that goes into the non-dominant areas.

In my experience, Nothing is ever easy. For example, I used to run a system where the title of a page could be changed easily (as one would expect), but adding a comma required minor refactor of the page structure.

Also, complexity abounds in the simplest of things, sometimes related to things being a big ball of mud. It is easier, for example, to test a service, because operations could be unit tested. On a UI or client library, the useful tests are full use cases, a.k.a integration tests, which needs to factor in state, setting up a headless browser+selenium/cypress, and factoring human think time. Failures are also not cut-and-dry because humans are more forgiving, and succeeding at the 4th try is still “good enough”. This might be seen as a 75% failure if you thought of them as just tests.

How to get better at this

If you are the requester, be mindful of your own biases on what is easy vs hard. Try to avoid the “Can’t you just…?” question, and instead ask: “I need your system/service/component to do Y. What would it take to do that?”

If you are the receipient of such a question, don’t agree or defend. Instead ask why they’re asking for X, which might unearth Y. Also, explain your internal architecture a bit so people understand why a change is hard. If you’re a central team with many such requests, invest in an intranet web page/wiki that explains this, and add that to new ticket templates.

Post script

I’ve written this down now, but this has been in my mind for many years now. As a manager for multiple front end teams across companies, I saw this pattern of request show up quite often.