[HN Gopher] Don't build useless features
___________________________________________________________________
Don't build useless features
Author : staccatomeasure
Score : 94 points
Date : 2022-04-17 12:43 UTC (10 hours ago)
(HTM) web link (staysaasy.com)
(TXT) w3m dump (staysaasy.com)
| zach_garwood wrote:
| There's nothing more disheartening than spending a great deal of
| time and effort building something that absolutely no one uses or
| even wants.
| danjac wrote:
| I've lost count of the times I have built something that nobody
| used or wanted, or failed for reasons outside of the
| development work itself. While it can be disheartening, you can
| still take pride in doing a good job, you (hopefully) got paid
| for building it, and you learned some things and maybe wrote
| some useful code in the meantime that could be re-used
| somewhere else.
| ilrwbwrkhv wrote:
| What's even worse is that any successful company often keeps
| making the same kind of unnecessary products again and again.
| Old project learnings are missing so often.
| beebeepka wrote:
| That's rather hyperbolic in at least several ways. Doesn't most
| of what we humans do fall into this category?
|
| 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
| zach_garwood wrote:
| Hey, sure, if you're making art, making something to foster a
| talent, or just making something because you personally want
| to see it exist, that feels really good and motivating! But
| if it's your job to build tools and products to make people's
| lives easier, and they don't, it's really difficult to feel
| good about that. It's not that a million people use it that
| makes it feel good (although that can certainly be a point of
| pride), it's the fact that you contributed something useful
| to society, whether it was you're idea or not, or perhaps
| helping others make thier ideas a reality is motivating.
| There are no doubt more objectively worse things that could
| happen in your career, but I doubt anyone sincerely wants
| waste their time and skill on some hair-brained product their
| project manager cooked up to pad their resume.
| beebeepka wrote:
| I understand the sentiment but it's somewhat ironic saying
| this on a site like this. Ads, tracking, military. Plenty
| of them around here
| WalterBright wrote:
| On the other hand, when I worked at Data I/O I proposed building
| a VT52 terminal emulator that ran on an IBM PC. With an RS-232
| cable, it could then talk to any device that expected a terminal
| (like Data I/O's devices), and transfer files back and forth.
|
| 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.
| zabzonk wrote:
| I did the the same thing, for VT100 rather than VT52 support,
| with built-in support for the KERMIT file transfer protocol on
| CP/M (Z80 assembler), BBC Micro (6502 assembler) and IBM PC (C
| and a bit of assembler). It was possibly a bit of a waste of
| time, as the Polytechnic I was working at had lots of physical
| terminals anyway, but I enjoyed doing it!
| jbverschoor wrote:
| Ahh.. like "App Uninstaller" in raycast. Makes totally 0 sense
| jollybean wrote:
| Sometimes you don't know for sure but a feature will help you
| find out.
|
| 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.
| twic wrote:
| 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.
| simonw wrote:
| 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.
| TameAntelope wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| Jasper_ wrote:
| 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 wrote:
| 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.
| burlesona wrote:
| 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.
| lloydatkinson wrote:
| 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.
| NicoJuicy wrote:
| 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 wrote:
| 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.
| x0x0 wrote:
| 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.
| acwan93 wrote:
| My dad always said it succinctly: software no one uses is a piece
| of shit. Build things that someone can immediately use.
| toshk wrote:
| Few problem with this approach:
|
| - 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
| AlbertCory wrote:
| Poster child for useless features: MS Word & Excel. Someone,
| sometime, asked for each feature, and they dutifully put it in.
|
| 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?
| robonerd wrote:
| > _[MS Word & Excel] needed some PMs to say No._
|
| 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?
| AlbertCory wrote:
| > The barrier to entry is low
|
| 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).
| medstrom wrote:
| > When you state an opinion, you don't need to provide a
| link. It's an opinion. Yours is different. There we go.
|
| 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?
| robonerd wrote:
| > _Wrong, MS fanboy._
|
| 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?
| shrimp_emoji wrote:
| > _Oh fuck off. I haven 't owned a copy of Windows since
| Windows 98._
|
| Holy based
| UIUC_06 wrote:
| Hundreds of millions, no _billions_ of people have eaten
| at McDonalds. Arguments from popularity don 't get very
| far.
|
| 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.
| dcminter wrote:
| I mean, I'm no fan of Microsoft, but these are _incredibly_
| successful products. You can 't really cite them as commercial
| arguments against delivering all the features!
| compiler-guy wrote:
| Strangely, this is not true. Joel Spoelsky has a great post
| about this from many years ago [1], but the bottom line is that
| the 80/20 rule doesn't mean that you can implement 80% of the
| features and sell only 20% fewer copies.
|
| 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...
| burlesona wrote:
| I would recommend against selling ahead of the Dev team. Sales is
| not research, and if you have effective sales people you will
| find that they can and will unintentionally sell vapor that
| cannot be delivered. Customers don't generally buy features and
| specs, they buy hopes and feelings. It's not the sales team's
| fault, but it's easy to successfully sell hopes and feelings and
| then still not know what the dev team is supposed to be building.
| Closi wrote:
| On the flipside, sales teams are probably the closest people in
| the business to what customers think they want.
|
| 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).
| magicalhippo wrote:
| > the client will obviously be right about what their
| requirement is
|
| 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.
| Closi wrote:
| I mean that the customer/client will be right about what
| _they want_ the requirement to be.
|
| Requirements are ultimately customer/user
| requirements/wants, not universal truths.
| magicalhippo wrote:
| > [If] you have effective sales people you will find that they
| can and will unintentionally sell vapor that cannot be
| delivered.
|
| 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.
| acwan93 wrote:
| Is this why some orgs have "sales engineers?" People who can
| pick up the nuances of a client's question whether a company
| can actually do feature X?
| karmakaze wrote:
| I got in 'trouble' a few times by giving alpha copies of a
| product in development to the sales engineers and when the
| customer saw particular new features wanted them and not
| any version without it. The trouble was caused when these
| events happened around release dates which back in the day
| of golden-mastered shrink-wrap software was a big deal to
| get right. Unfortunately as soon as the golden-master was
| declared, I and other devs had the capacity and creativity
| to do something truly remarkable that wasn't on the roadmap
| for the past 2 quarters.
| iratewizard wrote:
| I'm getting really tired of people spamming their uninteresting
| blogs on HN.
| [deleted]
| kgeist wrote:
| >Don't launch a product until you've put a prototype in front of
| a few customers and gotten feedback. Make sure that they say that
| they'll find value in it - key questions include things like "how
| would you use this feature?"
|
| 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.
| 2dvisio wrote:
| Indeed the article mentions digging deeper into that, how are
| you going to use it? Who would benefit most? Other
| colleagues/divisions/department that are going to benefit from
| "feature"? How do you accomplish something like this now?
| kazinator wrote:
| Here is a recipe for a useless feature:
|
| - 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.
| kolmogorov wrote:
| This sounds like Facebook rooms, too.
| kristiandupont wrote:
| The Huddle thing has me completely perplexed -- I am glad that
| I am apparently not the only one :-)
|
| 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?
| phamilton wrote:
| I'm pretty sure it's just a knockoff of discord voice
| channels.
|
| 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.
| Trasmatta wrote:
| > 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.
| phamilton wrote:
| It's only a 2 hour block and if you are heads down on
| something you just tell your team that and stay out.
| Nobody is enforcing anything, it's just a bit of team
| culture building which is difficult when everyone is
| remote.
| hamasho wrote:
| YAGNI is such a great principle. I can't emphasize this enough.
|
| 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.
| KerrAvon wrote:
| Maybe I'm missing some context but YAGNI wouldn't seem to apply
| here because if you think you're building sales as a service,
| you do need that stuff. What you encountered sounds like a
| traditional lack of product management focus and/or solid
| engineering leadership.
| hamasho wrote:
| > What you encountered sounds like a traditional lack of
| product management focus
|
| 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.
| rileymat2 wrote:
| > The project started to solve the company's internal problem
| for the sales department, but they also wanted it as a
| complete SaaS.
|
| They is ambiguous, the business or the dev team? If it is the
| latter, it would apply.
| duxup wrote:
| This is one of my biggest frustrations.
|
| 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.
___________________________________________________________________
(page generated 2022-04-17 23:01 UTC)