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
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.
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.
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.
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.)
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.
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.
You're right, systemd does fail in this.
And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.
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).
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.
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.
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.
Personally I prefer the thinking, reasoning, tracking down, supposed 'tedium' that comes with bug fixing.
Sure, bugs are boring, but most of the time the new features aren't terribly exciting either.
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.
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!"
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. :)
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 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.
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”.
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.
> the punchline is that they're all using a different 20%.
You could try creating different products.
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.
I'll have my Word with endlessly-deep menus, combined with discoverable keyboard shortcut and Ctrl-shift-p please!
I don't think most people hate it any more.
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.
Still hate it. Most apps did not follow Microsoft’s lead and add a ribbon to their app.
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.
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.
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.
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.
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.
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.
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).
Fun fact: a single Jira Issue page could download up to 100 MB of data. Not joking. Hope they fixed it in time.
Anyway no one uses an alternative to MS Word / Office 365 because the alternative has fewer features.
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)
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.
> The thing is, we can usefully flip this concept on its head! What if more developers developed a sense for the “maximum” number of things a product should do — and stopped there?
I'm sorry, but the author misunderstands entirely the reason for feature creep. It generally has nothing whatsoever to do with "fun" or developers "wanting to develop" or marketers "wanting to stuff to market".
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's the old quote about how 80% of the people only use 20% of the features -- but then the punchline is that they're all using a different 20%.
That screenshot of all the Word toolbars? Guess what. There are different user segments that actually use each one of those toolbars. Yup.
So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish. If you're a business and you want to make money and you'll profitably sell to more customers if you can build in a new feature, then you do it.
Why would any company restrict itself to an arbitrary "maximum" and leave money on the table...?