Don't build useless features
staysaasy.com
staysaasy.com
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.
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.
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.
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.
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.
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.
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.
At some point there was automated tests, but their failures are now ignored or have been turned off.
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.
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.
- You have a group chat and collaboration product that supports multi-way audio and video calls between individuals, as well as channel calls (calls visible to a channel that channel members can join).
- Somehow this is not enough, so you invent a new word for group calls: "huddle". Unfortunately, you then also implement it.
- "Huddle" has different UI. Starting a huddle, joining and leaving are different, but it's exactly like group call.
- "Huddle" doesn't honor "call" preferences like "start with microphone muted".
- This is not bungled up enough, so then you change the "Start a call" button on a channel to bring up a pop up menu whose first element is "Start a huddle". Starting a call is the second item, whose menu label is ... the product name rather than "Start a call".
- So now users expected to start a group call are accidentally starting huddles, which some team members don't notice because they are looking for a call notification.
I thought it was a third party thing we had installed but that doesn't seem to be the case. Is it an acquisition perhaps? Or what could possibly be the logic there?
Knockoff aside, the idea is a place where you can come and go without the formality of explicitly managing a group call. I've used it a few times with my team and it's basically "everyone just work on whatever they were working on, and if a question arises go ahead and ask, we're all here and we will answer". It's not a core part of our daily workflow, but I know some all remote teams who do "everyone on huddle between 1-3pm every day". They say they really like it.
Oh god this is my nightmare. I can't imagine trying to get any focused work done like this.
It leaves the rest of your time in the day to be focussed. Unfortunately, our new manager didn't quite like it and scheduled meetings over top of it, so if you really wanted to talk to somebody about something, you'd end up waiting extra days, or just scheduling a meeting instead.
"That's interesting, let's bring it up in work chat tmw" was a great way to stay focused throughout the day
95% of the time, the chat is silence, as everyone is doing their job. 4% of the time, it's the users talking to each other to coordinate something they're doing; i can mostly tune this out because it doesn't directly involve me, but it's good for the developers to maintain some vague awareness of it, because it might be something we can help with, or suggest a way to improve the software. The other 1% of the time, it's developers talking about something urgent, that's worth interrupting me for.
We also have regular meetings, separate to the chat, where we have deep conversations. And we have a couple of Slack channels (one for the four developers, and one for all six of us), which we use for conversations which aren't worth taking to chat.
A key fact, i think, is that the channel is mostly silent. If it was full of developers getting into deep technical conversations all day, it would be a productivity destroyer.
I once inherited a messed-up codebase. The project started to solve the company's internal problem for the sales department, but they also wanted it as a complete SaaS. So the former team implemented features like complex user management, request slotting, billing, etc.
It turned out that it required a lot of development time and money, and if they continued, they would fail to provide essential features to the original customer, the sales department. So they decided to stop implementing features for SaaS but didn't remove them (because we'll need them later! Of course..).
Then I joined the team and helped develop and fix bugs. It was a complete nightmare. Every time I fixed something, somewhere I didn't know even it existed broke, and it somehow affected essential features. No test (because why waste dev time), so I found it in the staging or sometimes in the production (the good thing was, almost no one used it, so it didn't matter).
Most members and the product owner agreed it was better to remove all unused features, but no one didn't want to spend their time cleaning such a mess. So we continued to develop with all unnecessary features, paying attention not to break something implemented long ago, and no one knows why. I left the team and don't know how it goes now.
They is ambiguous, the business or the dev team? If it is the latter, it would apply.
Yeah, you're right. I misunderstood a little that the YAGNI principle can apply to both programming and product management. It was not the devs implementing something unnecessary, but the management wanted unnecessary features at the time.
Some of the things I have done are used by millions. Doesn't make me proud one bit because I was paid to build other people's ideas, not mine.
Pretty much nobody cares about the things that I've done/written out of love. It's no doubt sad and sometimes makes me slightly bitter but there's plenty of objectively worse stuff out there
They told me it would be a waste of time, as there were commercial products that did it that were 100-200K.
I built it anyway as a rogue product. It was only 5K of assembler. It started getting passed around at work, and then the salesmen picked it up and made copies to give their customers. It made the sale easier because the customer didn't have to go buy one of the commercial ones. And it being ridiculously tiny just made it a no-brainer.
Data I/O finally made it an official product.
This can happen even if the sales people does not mean to sell vapor.
At least in my experience, they seldom have the domain or program knowledge to pick up on nuances in the client's question, leading them to think they correctly answer "yes our program supports that" while in fact the program does not support exactly that.
As a dev I'm not often involved in sales meetings, but every time I have been in a sales meeting I've averted some form of vapor.
The sad part is that most of the times the client is fine with us not having the exact functionality they ask for, but understandably get upset when they only find out about this post-sale.
Engineering teams often have a disparaging view of the sales teams, but usually the sales team is just selling what is needed to get the sale. Sometimes this is 'misplaced', but in my experience of enterprise software it's more often the case that a client has a genuine requirement and the engineering team thinks 'feature x' is close enough, but the client disagrees (and the client will obviously be right about what their requirement is, and if feature x is close enough is just a matter of opinion).
I guess you mean that as "the client thinks they're obviously right", as in my experience they're surprisingly often wrong about what their requirements truly are. Sometimes spectacularly so.
Most of the time this is because the decision is being taken too high up in the organization, so they don't actually know what their employees actually do or need. If not that, then it's not uncommon to see X-Y problems creep into requirements.
Requirements are ultimately customer/user requirements/wants, not universal truths.
I (and several others) found that it doesn't always work. There's a gap between "I'd hypothetically use it" and "I will actually use it". It's often the case that, when asked if they'd use a certain feature, potential customers often say "yes" but when the time comes around to actually using the feature/product, no one suddenly cares. I've seen several articles describing this interesting phenomenon, but I can't find the links.
Specifically building something half way that everyone is sure is important but when I talk to the customer the use case really is more expansive / only useful if this is a much larger thing.
The whole thing is leading up to “Why can we do X here too?”
Like yeah I agree but unifying all that is 5x more work and not what anyone asked … they said no when I asked.
Result is nobody uses it, the question endlessly comes up.
- first customers of iterative release is a very small sample size and not always indicative for a larger market
- by building minimal versions, or selling products before they are build, you are always behind in development, causing lots of stress and presure on the dev team and increases the risk of releasing products that are unstable
That said, it should be recognized that there is a 'cost' to a feature aside from dev. - they can get in the way of other features.
I saw a tech writer's post where ALL the toolbars of Word were expanded. It took up almost the entire vertical space. His point was "you need really good tech writers to explain all this."
No, they needed some PMs to say No. There's an overall cost to the collection of all the features, and it's much more than the sum of each one. Maybe "The Tragedy of the Commons" explains it?
Uh, why? Both of these applications were and continue to be massively popular. Excel particularly empowers self-perceived non-programmers in a way few other programs ever have. What's your basis for asserting that packing these programs full of features was a bad idea? Because it clutters the screen when you turn all the toolbars on? That's a "Doctor it hurts when I poke my eye" -> "Then stop doing that!" situation, not a real argument against lots of features. Virtually nobody understands or uses all of Excel or Word, but so what? Nobody needs to understand more than a tiny fraction of these programs to start getting real utility out of them, evidenced by their massive popularity. The barrier to entry is low, but these programs continue to provide more possibilities as user skill develops. Would the lives of excel pros using those esoteric features really be better if those features were removed and the now dis-empowered excel pros were made to each individually plead their case to programmers, begging for the implementation of functionality axed from Excel?
Wrong, MS fanboy. There's a whole industry of word processing and spreadsheet apps out there that sell themselves as "easy to use." One guess what they're comparing themselves to.
> What's your basis for asserting that packing these programs full of features was a bad idea?
When you state an opinion, you don't need to provide a link. It's an opinion. Yours is different. There we go.
> Would the lives of excel pros using those esoteric features really be better...
They would piece together the functions out of, e.g. exporting to CSV, or writing a Macro, or something. But everyone else who's not a pro wouldn't have to see that feature and feel they OUGHT to understand it. It doesn't mean the functionality is gone; it just means you have to work for it.
There's a discipline in meeting constraints. I'm not in any way a Google fanboy, but Docs and Sheets have the right combination of things you really need, and none of the things you don't. So do lots of other products.
Even though Word has, supposedly, everything you could ever need, it's still not adequate for writing a book, and I use Vellum for that (with Google Docs as the first draft).
Oh fuck off. I haven't owned a copy of Windows since Windows 98.
> I'm not in any way a Google fanboy,
I never insinuated anything of the sort, but when you come out swinging with the insults I guess this is the kind of conversation you're expecting?
> There's a whole industry of word processing and spreadsheet apps out there that sell themselves as "easy to use." One guess what they're comparing themselves to.
They're comparing themselves to the office suite that hundreds of millions of people at least have successfully learned how to use. Millions of naive school children and experienced typists alike have learned how to do what they need done in MS Word. And for decades, Microsoft Excel has been the backbone of innumerable businesses, from mom and pop to fortune 500. Both of these programs are incredible popular successes no matter what you think of Microsoft. (I happen to hate this company, despite your obnoxious presumptions.)
Aside to other commenters, can somebody recommend a kill file extension for hacker news?
Holy based
OK, rather than me providing a link, just do a DDG search of "ms word crashes."
The problem with having a zillion features is that in unusual cases, they don't work. You can't possibly test every combination of features in every version, in every weird case. My editor warned me against using Word, because she's had countless clients whose files have gotten corrupted, irretrievably.
If we try to be charitable and assume your interlocutor knows this perfectly well, what could he/she possibly mean? Easy, they're asking what gave you that opinion. Answer that instead of being so adversarial.
> But everyone else who's not a pro wouldn't have to see that feature and feel they OUGHT to understand it.
You're generalizing from your own feelings. Can you imagine that lots of people actually don't get this feeling?
Everyone uses a different final 20%, so you reduce your market share quite dramatically by not shipping a fully mature product in a fully mature market (which is what word processors and spreadsheets are).
1. https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...