>There are two types of baby outfits. The first is targeted at people buying gifts. It's irresistible on the rack. It has no fewer than 18 buttons. At least 3 people are needed to get a screaming baby into it. It's worn once, so you can send a photo to the gifter, then discarded.
>Other baby outfits are meant for parents. They’re marked "Easy On, Easy Off" or some such, and they really mean it. Zippers aren't easy enough so they fasten using MAGNETS. A busy parent (i.e. a parent) can change an outfit in 5 seconds, one handed, before rushing to work.
>The point is, some products are sold directly to the end user, and are forced to prioritize usability. Other products are sold to an intermediary whose concerns are typically different from the user's needs. Such products don't HAVE to end up as unusable garbage, but usually do.
Really though, where does the last button hole go? You count buttons - 10. You count holes - 10. You put the buttons in the holes - one is no longer 10.
As a parent who remembers all to vividly dressing uncooperative baby I've often wondered if designers of baby clothes have even seen live baby in person or are they just going off by random pictures on the internet.
I have a four month old and was inspired to buy one outfit with magnets because of this tweet. It works fairly well, but is no better than a single zipper outfit and is much more expensive.
Because businesses, in order to match compliance rules for their business types, size of business etc. often have lots of rules and processes in place about buying things like software, thus it becomes really beneficial for a manager if they can buy all related functionality that is needed by their business (especially functionality that is required by law) in one place.
Furthermore considering that some things will often be very complicated to do because of legal burdens it makes sense that one piece of software for doing invoicing handles all your invoicing needs across all markets you operate in. And suddenly when that happens it might be that you get a more complicated piece of software than if you bought 10 different pieces of software each supporting the standard needed for a particular market.
> Because checking off features matter more than usability when a manager is the one buying it instead of the person using it
As someone that buys a lot of enterprise software and runs a lot of software tenders (particularly for enterprise ERP and WMS) - I would say picking software which matches user/organisational requirements is actually the most important thing (which is checking off the right features).
Absolutely this is more important than usability, which comes secondary to meeting the requirements (what good is usability if I can't get it to do what I want?).
Most botched software tenders I have seen happened because the company purchasing the software wasn't clear on their requirements (i.e. the features they needed) and then bought a software which did not match what they required and then need to somehow just 'make it work'.
Big ticklists of generic features aren't useful though, but ultimately if you are purchasing an ERP and need to be able to put stock into bins within it, and it doesn't have this feature but it is really usable and built with really great architecture, it's still not going to work.
This plus I think legal requirements between various countries. Lots of logic to meet each country's requirements.
Then each customer wants their own specific crazy workflow in the product after they "rent" the software. An endless circle of bloat increasing. Just look at SAP (and Oracle).
My experience is that the manager seldom knows enough to judge usability - vs. merely not giving a crap. Especially not usability when in production - on well-loaded servers, via the lower-end workstations and network connections given to the day-to-day workers, etc.
And generally the most important feature for a manager to check off is the one never mentioned (at least on the customer-organization end) - "How does the Shiny Newness, Dog & Pony Show, and Buzzword Parade offered by this software make me feel about myself?"
It's easy to say this (and it's part of the problem) but it ignores why software built in-house is often just as bad, or worse. The article addresses this, pretty early on in fact.
> why software built in-house is often just as bad, or worse
In my experience this is largely due to PoC (or otherwise “temporary”) tools getting used long-term without refactoring, and growing further PoC features over time that compound the problem.
This also affects production services, if management let (or demand!) PoC code gets released before it is really ready.
And not just the managers, but in some industries(i.e. healthcare) it's also government and insurance requirements demanding constant changes and configurability.
Another consideration a lot of people don't really have is that enterprise software needs to answer a ton of other requirements that Joe Rando's Cloud App doesn't really care about.
Employers in the US can face consequences if they use software that doesn't have accessibility features, thus not complying with the ADA.[1] Clients of theirs can also sue.[2]
Some countries have multilingual requirements[3], not to mention the markets an enterprise loses out on by not having translations in dozens of other languages.
Enterprise software often has to be built and sold with the idea of scalability ingrained. Flexibility in scale here is where you get a lot of sales, e.g.: "WidgetSys can scale to support 1 million concurrent users". Some customers legitimately need that. This can also help deal with demand spikes, such as tax season, school registration "season", etc.
Some places have strict compliance requirements that don't make sense for most businesses. Most businesses probably don't care about FIPS-140-2, but some do because of who their customers are. Because of this, many pieces of enterprise software require incredibly fine-grained control over audit data.
Some require the ability to connect to LDAP, AD, and OAuth sources (sometimes all three at the same place).
Just this list represents features that can impact "bloat" but a "lean" app often doesn't have. This can get a business in trouble.
Now, the next question is obviously: Doesn't it make sense to have a user-specific build of the software. For example, if I don't need AD/LDAP access, can't I just get an OAuth only version? This doesn't work for a few reasons but let's assume it could. Now you have X versions * Y features worth of SKUs for your software.
It's also worth noting that while a lot of this stuff is huge on disk (relatively speaking) it often doesn't actually need to load and run all of that code. A lot of well-designed enterprise software is designed to essentially enable/disable functionality in a modular way because of it. They also tend to have many SKUs but segment it out along lines that make sense, e.g.: SQL Server Express edition is pared down SQL Server Standard missing a bunch of these features.
An easy way to look at this from the American perspective is to preface every feature tick box with "will the company be sued if we don't support ..." -- at least that's been my experience.
>Other baby outfits are meant for parents. They’re marked "Easy On, Easy Off" or some such, and they really mean it. Zippers aren't easy enough so they fasten using MAGNETS. A busy parent (i.e. a parent) can change an outfit in 5 seconds, one handed, before rushing to work.
>The point is, some products are sold directly to the end user, and are forced to prioritize usability. Other products are sold to an intermediary whose concerns are typically different from the user's needs. Such products don't HAVE to end up as unusable garbage, but usually do.
https://twitter.com/random_walker/status/1182635589604171776