Hacker News Reader

As an example I offer up a review of an Open Source Word-Alternative back in the early 2000's.

The reviewer liked the product enough, but slated the fact it didn't have a word counter. Now, I for one, have never cared about the number-of-words in a document. But, it turns out, journalists tasked with writing a 2000 word review _really_ care.

With great popularity comes great variability, and more "corner cases" matter.

Incidentally the solution is not fewer features, but better UI. Notice thats a very old screenshot of Word. Whereas Word to day looks very different, has the same (or greater) feature set, and a much more streamlined interface. The much-hated-on ribbon bar is actually a better interface than endlessly-deep menus and a million toolbars.

How can you claim a user interface is 'better' while in the same sentence referring to the fact that most people hate it? People don't know what's good for them?

I'll have my Word with endlessly-deep menus, combined with discoverable keyboard shortcut and Ctrl-shift-p please!

I suspect people hated the ribbon when it was introduced because it was an unexpected change, forcing users to learn something new when they just wanted to be doing actual work.

I don't think most people hate it any more.

The problem with the ribbon is that discoverability is extremely slow. If I'm looking for a piece of functionality, it's much faster to read through text menus looking for related words than to inspect a similar number of unfamiliar icons to figure out if they are related. Its keyboard usability is also not as consistent (e.g. alt+f, o to open a file from almost anywhere in the app)

Once you know where everything is and what the icons mean, it's probably better than nested menus for use with the mouse. Since that describes most of the person-hours in the software, this is an improvement on average. New users and those who lean heavily on the keyboard still aren't going to like it, though.

I still hate it - it takes attention, and I want to give the app as little attention as possible, so I can concentrate on what I'm writing, not the process of typing.

double click it

That is twice the work

What was a good way to temporarily hide all the toolbars at the top until I toggled it again back before the ribbon?

Im surprised my passion with witch im hating it hasn’t ceased a bit though it’s only when I use Word and I forget about it when I close it. Some things don’t make sense to me still, it feels dumbed down and more inefficient.

Since this is turning into an anecdote collection: I was sceptical of the ribbon UI initially, to say the least, but it works pretty well for me.

I still hate it, because it's a unicorn UX that doesn't follow any pattern that other software uses, and IMO is not an improvement in any way over the other standard options (normal menus). There's no special problem that Word faces that other word processors do not, so there's no reason for a screwy and impossible to decipher unless you've already memorized it UI.

So I hated the ribbon when it was introduced mostly for Excel. Because I did maybe 6-8 spreadsheets a year, but I had been doing that for at least a decade. It took a long time to build new muscle memory for the location of the small bits I use. Now? It doesn’t bother me, but at the rate I use it, it took years to get there.

I still haven’t gotten there. Drives me crazy any time I have to use an Office app. It’s rare enough that I cannot ever get work done.

> I don't think most people hate it any more.

Still hate it. Most apps did not follow Microsoft’s lead and add a ribbon to their app.

I think most people were just used to the old UI and resistant to change, so they complained about it. Yet, if you asked someone completely new to computing which UI they'd prefer, they would choose the ribbon.

If anything, placing the Styles menu front and center in the Home tab with live preview has made document formatting very discoverable. I used to receive so many Word docs with manually adjusted fonts and line spacing. Not so much after the ribbon was introduced.

> Yet, if you asked someone completely new to computing which UI they'd prefer, they would choose the ribbon.

How do you know that? This seems like a made up thing I’ve seen it stated by multiple people and it’s probably not true. If you take someone new to computing and show them the old idioms of UI and they’d likely prefer it since it makes way more sense.

Yes to be fair to Word, his screenshots were taken when all the optional buttons turned on.

Not all users know what they want, unfortunately.

It's not only a very old screenshot, it's also a screenshot you'd never get by default, you'd have to manually activate all these toolbars.

>> Incidentally the solution is not fewer features, but better UI.

I completely agree in principle. The problem is IMHO that the best UX is almost no UI.

Microsoft UI is IMHO essentially industrial automation. Select you data, then push a button (or menu item, or ribbon) to cause something to happen to your data. Apple attempts to encourage more direct interaction with data. The best example is pinch zoom. Remember when maps used navigation buttons to pan and zoom? Direct touch manipulation is better. This is very hard to do with a large feature set though.

One solution is hot-keys, but they do require learning and are limited in number. Context dependent hot keys can also be confusing.

In solvespace we have almost no UI and hot keys are critical to productivity. We avoid context dependence partly by having consistency. The constraint solver is always present, from 2d sketching to building an assembly, so those function keys are universal.

UX is hard, but also distinct from UI.

Also wouldn't most devs much rather fix bugs in an existing app than add features?

Piling more chairs on top of each other to get features out the door can be demoralizing. You know it's going to collapse under its weight eventually, and you're just speeding the company along to The Big Expensive Rewrite.

But fixing bugs? An actual chance to make things better? That is satisfying.

> Also wouldn't most devs much rather fix bugs in an existing app than add features?

No, for a few reasons: 1) it's often tedious work 2) often the bug has been around a long time and nobody's really noticed or cared, so how important could it be? 3) organizations rarely reward this work.

I quite like fixing bugs. It's a different mental challenge to truly understand what is going wrong, often something that's really subtle.

While individual fixes are often unnoticed, the overall effect is profound. Users are happier, support staff are more confident, and programmers are able to build the next layer on a firm foundation.

I agree bug fixing my code is more enjoyable to bug fixing other people's code, and I agree that most programmers resist the former and hate the latter.

But for me, bug-fixing foreign code, is one of the truest tests of skill.

I love bug-fixing other people's code for some reason. I often get nerd-sniped by another team in our slack talking about some bug they've encountered in their project(s). I kind of wish that could be my full-time job. I suppose that's what some fields of consulting are.

It's only tedious work if what you enjoy is cranking out another CRUD feature.

Personally I prefer the thinking, reasoning, tracking down, supposed 'tedium' that comes with bug fixing.

At essentially every company I've worked at the devs were asking for more time to fix bugs, improve performance, etc.

Sure, bugs are boring, but most of the time the new features aren't terribly exciting either.

Definitely not true. From a career optimization standpoint , every single major tech company’s leveling guideline that I’ve seen (including mine) has a criteria of “scope” and “impact”. No one ever got promoted for fixing bugs.

Even when it’s time for your next job, you can’t very well put on your resume “I fixed bugs for a year” and expect to standout.

Then there is answering behavioral questions at the interview where you have to talk about accomplishments.

On the other hand, I can’t pretend to know what most developers on the enterprise dev side go through at interviews. Even though that’s where I worked most of my career until 2020, I targeted small companies who were looking for “adult supervision”.

Developers have managers that tell them what to do. Developers can at most decide whether to accept a job in a maintenance or in a development team. Sometimes they just accept the first decent job, especially the first one out of school.

And managers care about their career and the size of their team is a proxy for their degree of success. If a company has 100 developers to create new software and 10 to bug fix, they want to be in the development team. If it's 100 to bug fix and 10 to build, it's the other way around.

The fallacy here is that it’s somehow necessary to divide into feature and bug fixing teams.

It's not necessary but I saw big companies with different budgets for development, (manual) testing, maintenance, operations. The team for testing is definitely separated from the development one, different managers, goals, etc. Operations more like so. Maintenance and bug fixing could be done by the same people but there is always tension at management level about whether to prioritize new features or fix problems. There are different internal customers behind those requests and turf wars are fought every now and then. Different teams and different budgets solve part of that problem but of course the fixes of some bugs can become new features on their own and more turf wars follow.

Haven’t met a single developer who doesn’t prefer feature development to bug fixing.

(Assuming you do this professionally) that doesn't sound great for the make up of your team.

I think I like bug fixing/performance fixing/'design' (as in db, infrastructure, code structure, refactoring - not UI) most. I don't mind new feature work, mainly because it typically involves some if the latter I suppose. I really don't like total greenfield work though, where you have to faff about with all the initial config of stuff (which assuming you don't start a new project every day you haven't done for ages) - especially anything to do with JS where you also have to work out how to do it without their 'helpful' cli tool, or how to combine a slightly different 19 tools & frameworks than the example you found.

Nice to meet you. I enjoy nothing more than figuring out a really tricky bug. I like the puzzle.

I also enjoy the detective work, especially for performance issues. I find I don’t like actually addressing the problems once I solve the mystery, however…

Does this count as meeting? :)

>> But fixing bugs? An actual chance to make things better? That is satisfying.

I don't think fixing bugs is the only satisfying thing. Sometimes, the need for new features arises only after users use your product for some time.

For example, PriceTable lets users generate professional-looking estimates quickly. After about a year of using our product, some customers said, "we use it everyday and have sent thousands of estimates to our clients. Is there a way to run reports to gain sales analytics insights?" So we added that feature too. And I found it satisfying. :)

It depends. A lot of devs, from my observations, take no satisfaction in the "last 10%". They stay for a project during the fun, risk-free green field development phase and then peace out.

These engineers never really learn from their own mistakes or the mistakes of others. They just jump from one startup to another. "What we need here is another microservice!"

> So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish

I disagree, I think the Unix philosiphy solves the problem. You build simple tools that do one thing, and do that one thing well, but you make it easy for the tools to work together and then you can have pieces that do one simple thing while still serving needs.

When new needs come up that aren't addressed by current tools you simply put together another simple tool that does that.

That's also how Word solved the problem with the toolbars. It hid the functionality using the ribbon and added plugins. Unix is a monster in terms of features if you look at it as a whole. It's just modular so it can solve all problems.

I don't think this adequately addresses the counterexample of the Word toolbars. Sure, there's Excel, but what if I want the tabular data to live in my Word document? Now the Microsoft engineers are building a whole secondary table editing system into a word processor...

This is one of the things that motivated the creation of OLE and COM, so that you could embed an entire Excel spreadsheet into a Word document.

If everything is modular, you can copy any feature between the various parts of your office applications. You've got a plugin doing one thing, and a host whose one thing is bundling all of those one things together.

This could just call Excel with COM

The unix philsophy might make sense for command line apps — though even there if you look at any manpage you find that they usually do more then one thing, including things you could easily do by piping the output to another command — but what does it mean in the context of a word processor? You want another app to count the number of words in a document, for example?

Have you looked at the help of some of these so-called simple tools? Pages and pages of options that you can configure. Not so simple.

Could this explain why the average person doesn't directly use linux?

It would be a start.

That just moves the complexity somewhere else (writing shell scripts, for instance). Not a real solution.

Not true.

Let's say you take a mega-program, break it into 100 programs.

Each now becomes more stable, due to simplicity. Yes, it really does.

But my point is, when you use those individual things, you use a random allotment of 3 or 4 of them. Not all 100.

Thus, the stringing-together bit is far, far less complex.

> Thus, the stringing-together bit is far, far less complex.

This is the statement I disagree with the most.

The problem is that combining different programs, that aren't strictly written to interoperate in a specific way, gives you an order of magnitude increase in the complexity. Sure, running find and grep together is common enough, but how about running {obscure_command_rarely_used} through {other_command} through {other_other_command}. There are always corner cases that can crop up, and even before we get to corner cases, just understanding how to fit the pieces together correctly is not so simple.

One cohesive program designed to all work together sometimes just makes more sense, especially when we're talking about complicated, high level actions, as opposed to the more common low-level actions of unix commands. (Or well, maybe high level and low level is the wrong way to put it - maybe the lower abstraction stuff in Word vs. the higher abstraction stuff that Unix tools deal with.)

> One cohesive program designed to all work together sometimes just makes more sense

Yes, your example of find|grep is perfect for this. Sometimes (not often) I have a situation where a simple pipe combination doesn’t work and I have to fall back to awk, which would be the single cohesive (and more complicated ) program.

This trivially becomes very fragile. Each of those 100 programs now doesn't just do stuff, but is held to a contract. A contract that it's well possible nobody intended to provide, but yet organically happened anyway.

And so you find that a small change somewhere like deprecating an option, fixing a typo, or adding extra data to the output makes the integration explode horribly in a confusing fashion.

There's also that plain text is a horrible serialization mechanism. Every program has to deal with parsing text that's mostly made for human consumption and deal with things like imprecise boundaries and arbitrary limitations per tool and per system.

Eg, /etc/passwd is a nice simple format, until you consider that somebody might want to use a ":" in a field, or to add more fields, or to store multiple lines of data. And all those quirks are specific for that particular file and may be handled subtly differently by other parts of the system.

And internationalization is an extra bit of fun, which ensures random bizarre bugs that use ',' instead of '.' as the decimal separator, or just emit text in some language that isn't English.

The object model of PowerShell is in my opinion really great for, at least, mitigating the text munging issue. The others are still there though.

Indeed, I think PowerShell deserves a lot of credit for taking a new look at this idea and doing it better.

If this was true, non-technical people would be stringing these together instead of using products that were created with the end user in mind

Figuring out which of the 100 I use and how to get them to work together is much more complicated than finding the feature in an omnibus program that already does exactly what I want.

Customers don’t want to glue things together they want whatever solves their problem efficiently.

Integration and ease of use are features in themselves.

The best of both worlds would be building things that is modular from the developers perspective but integrated from the perspective of the user. Few will pull that off though, and when they do the modular systems become complex and expensive bespoke setups (Typical of e.g SAP, Oracle).

You build simple tools that do one thing, and do that one thing well

You're right, systemd does fail in this.

Does it? If you mean 'all things under the systemd umbrella' then sure, but if you think in terms of systemd (core), systemd-networkd, systemd-homed, etc. isn't it pretty much as 'one thing'(s) as it could reasonably be?

And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.

It's not the only cause but empire building[1] is a very real phenomenon. Maximum viable features is a very interesting concept but it's just that, a concept, nobody says you have to stick to it, it can just be a tool in your toolbox to limit scope creep. One thing I don't have too many of is tools to limit scope.

> the punchline is that they're all using a different 20%.

You could try creating different products.

1. https://www.investopedia.com/terms/e/empirebuilding.asp

The problem is that each additional features imposes costs on those users who don't need it. An example would be JIRA. JIRA is designed to have every feature possible. But as a cost it is hellishly slow and is hard to find anything in.

Each additional 20% of the features you support cuts the UI and technical effort that can be put into the other 20%s of features.

The end result is the standard big corporate apps that feel heavy weight despite doing what feels like a pretty simple thing.

It makes sense for companies to do it. Because the cost is born by the consumers.

>"But as a cost it is hellishly slow and is hard to find anything in"

There are examples to the contrary. CAD products I think are way more complex than this JIRA abomination but are not slow at all. And for what it worth I went from knowing nothing to producing complete design of a relatively complex piece of equipment (main assembly, all individual parts etc in a form accepted by factory) in less than a month using Solidworks. This says something about quality of this piece of software. Out of fun when I had nothing to do I tried to repeat the design in FreeCAD - never fucking again.

So I think the problem is not the amount of features (the more the better). It is just very hard to design proper ergonomic GUI and workflow.

This definitely applies to autocad though! A lot of the better products are perhaps a reaction to the bloat of older products.

> JIRA is designed to have every feature possible.

If only that were true. There are several long-requested features that they refuse to implement on "agile purity" grounds (such as the ability to split a story while also distributing points, so you can mark it as partially complete in a sprint, or at least leave behind completed subtasks in the old sprint).

Counterpoint is IntelliJ, a pleasure to use, more feature than Eclipse.

> But as a cost it is hellishly slow and is hard to find anything in.

Fun fact: a single Jira Issue page could download up to 100 MB of data. Not joking. Hope they fixed it in time.

Yep came here to say this. The article is incorrect in the diagnostic and thus the prescription

I liked some of the takes on building Minimum Lovable Product (MLP) instead. Retaining the focus on why people would want to use it, and with your vision for the product central.

https://news.ycombinator.com/item?id=30799083

Scope and feature creep has nothing to do with customers. It happens in all creative endeavors, most of which do not have anything like customers. It happens in art, music, hobby programming, event planning, etc etc. Everything.

If you sit down to try to write a program that no one will ever see but yourself, you will have to fight against feature creep. It comes from the creators themselves. It's basic human nature to find it easier to desire things than to restrain oneself.

> Why would any company restrict itself to an arbitrary "maximum" and leave money on the table...?

Because when there's too much options and features users are going to be overwhelmed.

Also, feature creep has nothing to do with developers wanting or not wanting, those are product decisions.

I saw that in the past with an ecommerce, we had a good portal, then stakeholders in corporate that need to justify their salary started shoving more and more stuff, now what was a simple search-find-pay has become interrupted and overwhelmed with features and information.

>Rather it has to do with segments of customers genuinely needing a given feature, and they won't buy the product unless it has the feature.

there is another reason feature creep happens for certain categories of products, which is regulation. If a law is passed mandating industry X needs to support Y that feature will be added for any product wanting to sell to the market that has mandated the feature.

any analysis that misses these kinds of real world scenarios is not that interesting.

I agree with you on your points but the quote even contradicts itself here.

Adding new features is fun and exciting but feature creep is bad?

What is feature creep if not new features? (Well new features + the idea that we're adding more features than we're thinking about their implementation and/or before the app does what it set out to do in the first place)

I've been exploring this concept a bit at my startup for our B2B offerings. Where I've landed is a robust set of feature toggles that Sales and Account Management configure. Within the confines of your Microsoft Word toolbars analogy; since the software we offer is similar to SaaS and delivered via a web browser this effectively means we can "hide" the toolbars that the client isn't interested in.

This is all pretty early days, but my hope is that we can iterate the core "have feature toggles" concept to the point where we have the ability to turn functionality and function accessibility on across many verticals. I hope that one day internally we can configure things a per-customer and per-user-persona basis. I also hope that one day we can expose some of those switches to admins and/or everyday users, possibly with paywalls or other strictures.

We'll see where it all lands :D

We've been doing this for 25 years in our desktop software. Every new feature is behind a checkbox on a "features" screen. This screen is in the program, so users can turn things on and off, but typically its set by one of our staff during the installation phase [1].

The upside is a clean interface which helps during training, support, and day to day use.

The primary downside is discoverability. Occasionally customer needs change and some assume "the software doesn't have that feature" rather than call us, or check online.

That's a problem best solved with good communication, but that can never be perfect.

[1] this is in the B2B space, and has a proper sales, install, support cycle.

It's not just about the users. As the software becomes more complex it's hard to change/iterate on, hard to find bugs/fix things, hard to reason about etc. And the difficulty seems to rise non-linearly.

How does that scale for enablement, training materials and documentation? Will be very confusing for users if the material shows things that are not in his UI.

tl;dr: giving users the ability to show / hide some features.

How about maximum viable product definitions for go to market? I've worked with PMs that have engineering build-build-and-rebuild delaying release until they feel it is "good enough", or what I think is really going on, "perfect". Then it gets into the hands of users who don't care about most of what the PM felt was important or necessary. In those cases (what I call "Steve Jobs syndrome) it would've been nice to say the product was limited to doing x, y, and z for the release.

I forgot to mention, the point is to limit the cost of the product before getting valuable feedback that ought to direct the future of the software. It's also not fun toiling away on a product the end users never use because it only made sense in the PM's mind.

(unsarcastically) I'd be pissed if a computer manufacturer placed an arbitrary limit on what I should be able to do with my computer.

Because they might get outcompeted by 5 different products that aren't 80% bloat?

"Bloat" means what exactly: Download size? Slowness to start? I suspect you really mean complexity of the interface, but with careful design its possible to hide the complexity and provide various easy entry modes.

Anyway no one uses an alternative to MS Word / Office 365 because the alternative has fewer features.