4 ms·

Counterpoint: build useless features. Sometimes your CEO doesn't completely trust the development team. Sometimes the client wants to make sure the vendor real

by twic 5y ago

Counterpoint: build useless features. Sometimes your CEO doesn't completely trust the development team. Sometimes the client wants to make sure the vendor really values them. Sometimes the head of sales decides to take a punt on something that has a small chance of a big impact. As a development team, the best thing you can do in each of these cases is to build the useless feature. Build it properly, but build it with a minimum of effort, and be ready to retire it and delete the code when it turns out to be useless. Earn the CEO's trust. Reassure the client. Throw the dice. There are payoffs to work other than value for the end user.

burlesona 5y ago
Yeah I think there’s something to this. You have to be careful because learning to say no, and saying no often, is a critical skill. But I do think that sometimes it’s worth it to find a way to quickly put the “dumb idea” out there and measure what happens. The measurement should resolve the debate. Usually the win is building trust with your team. The people who fought for the bad idea are a little chagrined and trust the process more, so they take it better the next time you say no. And occasionally the dumb idea turns out to be brilliant and you’re all really glad you tried it. _As long as you can keep the time cost very low_, this is a valuable tool to have in your tool belt.
NicoJuicy 5y ago
Well, or redirect the client/CEO to another useful feature that would also help them further. Make it useful. They just want their issue solved. They don't care about the how and they don't care if you don't adjust it exactly like they described it in their request. More than not, there is an underlying issue that could be solved more generally. Eg. in a lot of reporting cases, export to excel would work fine.
- MiddleMan5 5y ago
  This is my mantra as well. Whether or not it's the right one I'll have to write about in a blog post 15 years from now; sometimes it seems like it's nothing but an uphill battle.
lloydatkinson 5y ago
I suppose it depends a lot on how much the organisation values creativity and the passion involved in making features like that. I’ve tried it several times and a lot of the time I or my team that worked on it has been met with apathy and “what’s the point of that” a lot.
x0x0 5y ago
Sometimes execs really do have a good grasp on what customers what. Any good ceo is a salesperson for their company, and spends a great deal of time talking to the most important ($, strategic, etc) customers. Finally, even if the feature ends up being entirely useless, it gives PMs ammunition for the future to push back against ceo requests. And hopefully the ceo is reflective enough to internalize the lesson.
TameAntelope 5y ago
Hell yeah. It’s a futile effort to try and not waste time, because it stifles the creativity of basically everyone involved. If you’re not regularly throwing code away, you’re not taking enough risks. The amount of cool stuff people will build if they feel safe to fail is super duper worth the lost time.
gingerlime 5y ago
> and be ready to retire it and delete the code when it turns out to be useless There lies the problem though. It's so much easier to add stuff, but so much harder to remove it. Because then you get shouted by the loudest 0.1% of your user base, who happen to use this useless feature. And nobody's going to fight for removing something. Well, not nearly as hard as people fight to add their brightest idea to the product.
- twic 5y ago
  One technique i use is to accidentally break features i want to get rid of. Then when nobody complains, i can just delete the old broken feature that nobody uses anyway.
  - MereInterest 5y ago
    That's an interesting idea, and is effectively a trial run of fully removing a feature. Though, does that imply that you're working in a codebase without automated testing? With automated testing, the "accidental" breakage would be more likely to be caught.
    - 8note 5y ago
      It tends to be that for features people mostly don't care about, the automated tests started failing years ago, and nobody will prioritize fixing them. At some point there was automated tests, but their failures are now ignored or have been turned off.
  - Jasper_ 5y ago
    Ah, yes, the Google strategy. Accidentally break the feature, then look at the analytics six months later when nobody uses it because it doesn't work, decide that it was a useless feature, just remove it instead of fixing it. And I mean, I'd lodge a formal complaint about the broken feature but I'm not even sure I can file a bug report with the specific Google service, and the last 10 complaints I managed to file all got bitbucketed anyway so why even bother. So I'll just grumble and stop using your product, because you can't seem to write features that work.
delusional 5y ago
My Dad is an independent blacksmith. One of his principles for dealing with new customers who don't trust him yet is: Talk then down, then deliver a little extra. I think the same goes for software development.
simonw 5y ago
This is why I like encouraging a tradition of hack days or hackathons at companies where I work - once or twice a year set aside a couple of days where engineering teams (or individual engineers) can build anything that they want. It's a fantastic release valve for people who have an idea that they've not been able to pursue before, it gives people a safe venue in which to try out new technology and it's a great tool for team building and morale boosting in general.

by twic 5y ago

burlesona 5y ago

Yeah I think there’s something to this. You have to be careful because learning to say no, and saying no often, is a critical skill. But I do think that sometimes it’s worth it to find a way to quickly put the “dumb idea” out there and measure what happens. The measurement should resolve the debate. Usually the win is building trust with your team. The people who fought for the bad idea are a little chagrined and trust the process more, so they take it better the next time you say no. And occasionally the dumb idea turns out to be brilliant and you’re all really glad you tried it. _As long as you can keep the time cost very low_, this is a valuable tool to have in your tool belt.

NicoJuicy 5y ago

Well, or redirect the client/CEO to another useful feature that would also help them further. Make it useful. They just want their issue solved. They don't care about the how and they don't care if you don't adjust it exactly like they described it in their request. More than not, there is an underlying issue that could be solved more generally. Eg. in a lot of reporting cases, export to excel would work fine.

MiddleMan5 5y ago
This is my mantra as well. Whether or not it's the right one I'll have to write about in a blog post 15 years from now; sometimes it seems like it's nothing but an uphill battle.

lloydatkinson 5y ago

I suppose it depends a lot on how much the organisation values creativity and the passion involved in making features like that. I’ve tried it several times and a lot of the time I or my team that worked on it has been met with apathy and “what’s the point of that” a lot.

x0x0 5y ago

Sometimes execs really do have a good grasp on what customers what. Any good ceo is a salesperson for their company, and spends a great deal of time talking to the most important ($, strategic, etc) customers. Finally, even if the feature ends up being entirely useless, it gives PMs ammunition for the future to push back against ceo requests. And hopefully the ceo is reflective enough to internalize the lesson.

TameAntelope 5y ago

Hell yeah. It’s a futile effort to try and not waste time, because it stifles the creativity of basically everyone involved. If you’re not regularly throwing code away, you’re not taking enough risks. The amount of cool stuff people will build if they feel safe to fail is super duper worth the lost time.

gingerlime 5y ago

> and be ready to retire it and delete the code when it turns out to be useless There lies the problem though. It's so much easier to add stuff, but so much harder to remove it. Because then you get shouted by the loudest 0.1% of your user base, who happen to use this useless feature. And nobody's going to fight for removing something. Well, not nearly as hard as people fight to add their brightest idea to the product.

twic 5y ago
One technique i use is to accidentally break features i want to get rid of. Then when nobody complains, i can just delete the old broken feature that nobody uses anyway.
- MereInterest 5y ago
  That's an interesting idea, and is effectively a trial run of fully removing a feature. Though, does that imply that you're working in a codebase without automated testing? With automated testing, the "accidental" breakage would be more likely to be caught.
  - 8note 5y ago
    It tends to be that for features people mostly don't care about, the automated tests started failing years ago, and nobody will prioritize fixing them. At some point there was automated tests, but their failures are now ignored or have been turned off.
- Jasper_ 5y ago
  Ah, yes, the Google strategy. Accidentally break the feature, then look at the analytics six months later when nobody uses it because it doesn't work, decide that it was a useless feature, just remove it instead of fixing it. And I mean, I'd lodge a formal complaint about the broken feature but I'm not even sure I can file a bug report with the specific Google service, and the last 10 complaints I managed to file all got bitbucketed anyway so why even bother. So I'll just grumble and stop using your product, because you can't seem to write features that work.

delusional 5y ago

My Dad is an independent blacksmith. One of his principles for dealing with new customers who don't trust him yet is: Talk then down, then deliver a little extra. I think the same goes for software development.

simonw 5y ago

This is why I like encouraging a tradition of hack days or hackathons at companies where I work - once or twice a year set aside a couple of days where engineering teams (or individual engineers) can build anything that they want. It's a fantastic release valve for people who have an idea that they've not been able to pursue before, it gives people a safe venue in which to try out new technology and it's a great tool for team building and morale boosting in general.