undefined | Better HN

0 pointsonion2k5y ago0 comments

Yet, I’d say it’s not the teams. In my experience it’s usually management that demands new features and doesn’t care about speed.

This line of reasoning makes me sad. It highlights so many problems in a company that a developer is having to deal with;

- Seeing 'management' and 'devs' as opposing teams shows a lack of communication and a lack of understanding from everyone involved.

- A company where managers aren't willing to listen to developers is never going to put out a great product. Developers have expertise and know what they're doing.

- A company where developers think they know best is never going to put out a great product either. Managers also have expertise and know what they're doing.

- If the "managers" dictating that features are added are "higher ups" rather than product managers then the company is never going to put out a great product because the people who talk to the customers and look at usage metrics should be driving the product roadmap. Customer needs should be driving what gets added.

- Developers who aren't putting up a fight to write good, fast code because they're not being listened to stop caring about what they're building, and that means there's very likely to be other problems like significant bugs, tech debt, etc. That just grinds you down and stresses you out.

All in all, if your opinion is "the product I build sucks because managers make it suck" you probably need to find a new job. Not every company is like that. Find a good one.

0 comments

the_cramer5y ago

"Developers have expertise and know what they're doing."

Unfortunately this is not always the case. Currently there are other "developers" getting access to our sql servers that drag down performance a lot. It looks to me that they may be coming from an OOP world and now trying to force these patterns onto sql which doesn't scale at all.

So developer != developer and not all developers are good imho.

corty5y ago

I think it might be necessary to just frame speed as a problem everyone can relate to, Ferengi as well as developers.

One possibility for speed as in latency would be to pre-agree on a latency budget (as in realtime-systems: if you exceed that deadline, your system has failed). Then have everyone be aware of how they spend that latency budget. Say the latency deadline is at 500ms for your website to full interactivity. Currently you are at 320ms. Marketing wants to include some analytics scripts. Include them in the test page, measure the added latency, then check against your deadline: added 200ms, we are now at 520ms. Do we reject marketing's wishes or do we make the design dept. cut back on their image load times, maybe they can get from 130ms to 90ms? How about investing in better caching to get 100ms?

That way you can discuss numbers and can quantify how something impacts the overall experience. Budgets is something everyone can understand, and taking a big gulp out of a limited budget is something no-one wants to be seen doing.

eska5y ago

A technique I learned from Tanenbaum's operating systems book back in the day, that has served me well over the years, is to come up with the theoretical maximum and compare it to a naive implementation.

For example right now I have to deal with a data interface provided by a partner company. The theoretical limit of the interface should be 1.625 MB/s. If we were to stupidly copy our numeric streaming data over, we would be within our timing budget, and optimizing this would be optional.

However, the implementation of the partner company only reaches 0.1MB/s max. So their "smart" implementation/interface is only 6% efficient, or in other words could be 16 times better. That really helps putting things into perspective, and turns management's bullshit filter on, when the partner company says "you can buy this from us if you want more performance" or "that's just the limit of the hardware".

danjac5y ago

> Customer needs should be driving what gets added.

In enterprise, the "customer" is going to be someone who will almost never touch the product once they've signed off on it. Building something that's a pleasure to use (good UI, responsive etc) for the end-user is usually wayyyy low on their list of priorities.

j / k navigate · click thread line to collapse