Don't build useless features(staysaasy.com)
staysaasy.com
Don't build useless features
https://staysaasy.com/product/2022/04/16/battlefield-product-management-dont-build-useless-features.html
64 comments
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
At some point there was automated tests, but their failures are now ignored or have been turned off.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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?
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?
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.
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.
> 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.
Oh god this is my nightmare. I can't imagine trying to get any focused work done like this.
We do this but with a perpetual Zoom meeting. It works for us. But i think my team is strange. We build software to do some vital business task, which is used by people actually responsible for that task. There are four developers and two users. All six of us are on the chat.
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.
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.
We did that for an hour daily for a while. It fixed the "schedule 15min meetings for 5min conversations" problem that we had before, since most of the conversations can wait, and everybody can hear about the topic and participate as they like.
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
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
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.
But a group call isn't formal; it's just something anyone can start, which results in a call object being visible as a message in a certain channel, that people can freely join and leave. The call UI can be minimized into a little floater that can be put into the corner of the screen and you can configure the mic to be muted by default.
This sounds like Facebook rooms, too.
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.
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.
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.
> 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.
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.
> 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.
They is ambiguous, the business or the dev team? If it is the latter, it would apply.
There's nothing more disheartening than spending a great deal of time and effort building something that absolutely no one uses or even wants.
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.
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
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
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.
I understand the sentiment but it's somewhat ironic saying this on a site like this. Ads, tracking, military. Plenty of them around here
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.
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.
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.
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!
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.
> [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.
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.
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?
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.
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).
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).
> 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.
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.
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.
Requirements are ultimately customer/user requirements/wants, not universal truths.
>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.
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.
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?
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.
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.
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
- 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
My dad always said it succinctly: software no one uses is a piece of shit. Build things that someone can immediately use.
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.
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'm getting really tired of people spamming their uninteresting blogs on HN.
The CEO (at a small or medium sized company) should push back on these “demand” features. Sales will always ask for the moon, but they should sell what is not what the customer thinks they want. Have them send that info to marketing,
I have seen companies slowly morph into defacto temp agencies by allowing salesmen to sell whatever they want.
You often don’t know if the feature you are building is worth building or not. You might have a strong feeling either way but you don’t really know. You will only know after the feature has been exposed to customers. So adding a feature is a business risk. However taking risks is what running a business is all about. You make the best guess possible and try it out in the market place. And then you learn from feedback.
Ahh.. like "App Uninstaller" in raycast. Makes totally 0 sense
[deleted]
[deleted]
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?
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?
> [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?
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?
> 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).
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).
> 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?
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?
> Oh fuck off. I haven't owned a copy of Windows since Windows 98.
Holy based
Holy based
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.
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.
> 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?
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?
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...
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...
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!
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.