
Customers do not ask for software complexity - runningmike
https://nocomplexity.com/do-not-ask-for-software-complexity/
======
MattGaiser
They ask for a laundry list of features for all manner of custom scenarios
(including those which have never happened or cannot happen).

They want it quickly so there is no time to plan.

They want it cheaply so there are no resources to test.

They want it according to the drawing they prepared which you then later need
to find places to stuff any extra features they ask for later.

They quickly get tired of answering clarifying questions about it and ask
developers to "just figure it out." They also don't really care about
reliability, or at least that doesn't come up much in discussions.

They insist up and down that their use case is unique and that the way they do
things cannot be modified.

They have immensely complex business rules they never wrote down and can't
agree on the details of as when the process was done by humans, the answer was
up to the human.

So they may not ask for complexity, but that is the end outcome of everything
they do ask for.

~~~
LaundroMat
I once had a retail client wishing for an "in-store Google Maps" that would
guide customers to the products they are looking for. "So if I'm looking for
pasta, the app should show me on what aisle to find it. That shouldn't be too
difficult, should it?", he asked.

I asked him how the location of products is stored now. "Is there a system, a
database that keeps track of where in the store, on what shelves, product is
stocked? Something the app could use so it knows where your pasta can be
found?"

He didn't understand the question. So I asked him how workers who stock the
shelves know where to put what products. There must be a system that gives the
workers that information, right?

"Oh no", he said, "there is no system. They know through experience and gut-
feeling."

~~~
jiveturkey
and what's wrong with that? the client is asking for an ML solution. or, more
basic, a stock person still has to stock the shelves, so they can scan as they
stock. or customers themselves can report inventory locations. just tell the
customer a random (at first) location for pasta. when you sense they've gotten
there, prompt them whether it was there or not. amortized over time, this is
an immeasurable fraction of customers that would have to do the inventory
work.

i get it, you're trying to give an example of an impossible request, of which
there are many, but this just isn't one of those.

~~~
MattGaiser
>just tell the customer a random (at first) location for pasta. when you sense
they've gotten there, prompt them whether it was there or not.

Pissing off an enormous number of customers in the process. You will run out
of customers at the store willing to use such a useless app before the thing
learns where the pasta is.

Your stock person idea makes sense if they keep the shelves stable, but "gut
feeling" organizations tells me that things can shift around over time.

~~~
jiveturkey
enormous??? once you've located an item (say a low single digits of customers
per item), the next <uncountable> number of customers now get to use that
data. the number of annoyed customers will be in the "epsilon" fraction --
uncountably low.

and you can give an incentive to customers. give them a 10% discount on their
total order when they checkout, if they've reported the correct location of an
item. don't tell them about it until they checkout, to avoid gaming.

there's many more ideas here, i don't need to iterate through them all. i'm
impressed by the lack of creativity on this subject.

> things can shift around over time.

not just that, but products come and go. it should be obvious that this is an
ongoing task when stocking, not a one time inventory location task.

------
nogabebop23
>> Make a simple conceptual model.

simple, simple - ok I get it.

>> This model should cover all aspects, so also the key business aspects.

a simple model that covers _all_ business aspects?

This is where the complexity comes from. Your all-encompassing "simple model"
is likely a high-level abstraction that is not implementable.

Software systems that model complex domains by definition are complex or
incomplete or, and this is what we should avoid, both.

This post is either naive or intentionally glosses over why we end up with
complexity. All good software starts will the ideal of a clear & simple
integrity; the only software that keeps it is likely not used.

~~~
adrianmonk
> _This is where the complexity comes from._

It's definitely a major source of complexity. But also there's nothing
stopping you from adding in unnecessary complexity on top of that. Part of the
trick is to know which is which.

~~~
gmueckl
I've produced the cleanest solutions when I had the luxury of having the
problem domain spelled out in detail and locked in place. I could design a
system to cover those aspects without second-guessing myself needlessly about
future extensibility and other things. If the specs are fluid, all design
confidence flies out the window and the resulting system is over-engineered to
cover eventualities.

~~~
flukus
> If the specs are fluid, all design confidence flies out the window and the
> resulting system is over-engineered to cover eventualities.

IMO that achieves the worst of both worlds. If the specs are fluid you have to
be able to iterate quickly, dive in, modify code and deploy. Any time code
gets over-engineered to elegantly handle future changes it just slows down
those changes. You need to accept or even embrace that the requirements will
change, not to try and preempt the changes.

For 90% of the corporate web apps I've seen a simple CGI site would have been
the correct solution, able to change quickly with no layers upon layers of
dependencies.

~~~
gmueckl
Your approach works when you are around to accomodate changes easily. With
more red tape in the process (worst case, code developed externally), the
incentives to overengineer the the initial solution grow. As you point out,
this is bad. But that's how I see things play out.

------
awillen
Enterprise software PM here: this is wrong. Customers absolutely ask for
complexity. They may not say "give me a complex piece of software" but they
sure do provide an onerous list of requirements, plus they need you to meet
their security/PCI/HIPAA/whatever other standards. Then over time their needs
change and they need the software to change (or worse, they need to be able to
make changes to the software themselves, so you have to build in flexibility).

This is like saying customers don't ask for wheels and a motor, they just ask
for a car that is capable of driving.

~~~
readhn
No, they dont ask for complexity. They do want it to be simple but solve
complex problems. There is a difference.

There is a beauty in creating simple solutions for complex problems. Not many
are able to do that. And that is the way it is , always was, and always will
be.

~~~
stupidcar
Many complex problems do not have simple solutions. This is a fundamental
principle of computer science.

------
Icathian
Customers, in my experience, want to have their cake and eat it too.

Nobody wants complex, cumbersome tools, but they do want every iota of
flexibility they can imagine delivered in unrealistic timeframes for
vanishingly small budgets. Complex, kludgy software is usually the result of
customers prioritizing fast and cheap over good, and being given exactly what
they asked for.

~~~
kevindong
> Nobody wants complex, cumbersome tools, but they do want every iota of
> flexibility they can imagine

Wanting virtually unlimited flexibility inherently already dooms a project to
be complex. That's before talking about timeframes and budgets.

~~~
Icathian
I agree in general, but I do think there are occasional counter-examples that
stand as proof that you can have real flexibility and power without building a
mudball. fork/exec, map/reduce, etc. These are foundational for a reason.

Mostly though, yeah, you pretty much nailed it.

~~~
enitihas
fork/exec create a huge amount of complexity, and it's possible the
NTCreateProcess API is a better API, even with it's tens of arguments. You
have to keep n things in your head while doing fork(), like what happens to
signals or threads.

------
vimax
What world are you living in that customers don't ask for software complexity?
I've spent so much time shooting down poorly thought out ideas, explaining why
it is just too complex and not what they need.

------
crazygringo
> _Building simple open software solutions means you should at least: Make a
> simple conceptual model. This model should cover all aspects, so also the
> key business aspects._

Well there's the rub right there.

The model can be simple or it can cover all aspects.

It can virtually never do both, because all the aspects the software is needed
for is always complex.

In fact, the aspects are so _fiendishly_ complicated that we usually can't
even understand them entirely in advance, let alone simplify them.

This is why agile has become so popular: it eschews "cover all aspects",
acknowledging the impossibility of this, and aims for complexity to evolve
gradually as it is demonstrably needed, rather than up-front.

~~~
davidjnelson
I would call that “good agile”, a case where it actually helps by breaking
things down into smaller, fully complete, fully productionized pieces.

------
franciscop
This seems a fairly empty article. Sure, simplicity is better than complexity,
no one will deny that at face value. Customers might not ask for software
complexity, but also most of them won't pay for software simplicity, not even
implicitly from what I've seen.

General customers care about software that solves their problem and it's
cheap. The later is debatable. Complexity and maintainability is very, very
low in he priority list of secondary attributes that customers want. Higher up
are things like: it's delivered on time, made by someone they trust, doesn't
break often, etc.

------
rcfox
I thought that "Out of the Tar Pit" (Moseley & Marks, 2006) classified
complexity excellently:

> Essential Complexity is inherent in, and the essence of, the problem (as
> seen by the users).

> Accidental Complexity is all the rest — complexity with which the
> development team would not have to deal in the ideal world (e.g. complexity
> arising from performance issues and from suboptimal language and
> infrastructure).

> ...

> For example — according to the terminology we shall use in this paper —
> bits, bytes, transistors, electricity and computers themselves are not in
> any way essential (because they have nothing to do with the users’ problem).

\---

You can't reduce essential complexity without sacrificing your ability to
solve the problem. (Of course, this isn't to say it's never a valid way to
meet a deadline.)

Reducing accidental complexity is a noble cause though, but as an engineer, it
can be difficult. It sometimes precludes using shiny new technology, or even
making it yourself. Maybe the user's problem can be solved with an off-the-
shelf solution. Or maybe you don't need a full website and database because a
spreadsheet will suffice.

------
jwilliams
In my experience this is untrue -- I've worked with many business processes
that are very complex, and software hasn't even got involved yet.

More generally, the issue is that customers often do not understand which
requirements lead to complexity, and which ones don't. If the software
development relationship is transactional (and in Enterprise it usually is),
then this leads to unmanaged complexity.

A lot of software (and processes) fail to have an "escape hatch" where
exceptions are kicked out for manual intervention. Putting this in and then
managing to the intervention rate is a decent way to manage complexity.

------
Reedx
_You listen to all your fans and they always say "You should add this" or "You
should add that."

They never say "Take this out, take that out." They say "add more, add more!"

There's an old saying that I love about design, it's about Japanese gardening
actually, that "Your garden is not complete until there is nothing else that
you can remove."_ -Will Wright

~~~
james_s_tayler
If it were up to me I would remove my entire garden.

------
robbrown451
"Complexity" is more-or-less a pejorative, so of course they don't say they
want that.

Ask them if they want "sophistication" instead. It can often mean the same
thing as complexity.

I'd like, for instance, my dictation software (such as dictating text messages
on my phone) to get it right. I don't want to constantly have to edit it when
it makes what you might call "dumb mistakes." (my current biggest gripe,
Android constantly inserts the word "oh" at random places while I am
dictating, for no apparent reason)

When I ask it for directions, I don't want it to give me directions that are
dangerous to follow (they finally corrected the one that told me I should
cross 4 lanes of traffic on a busy interstate -- 280 south from 101 to Alemany
in San Francisco -- to get from entrance to exit in 800 feet, when there is
another exit I can take that is safe and takes about the same time to get to
my destination).

To do it right, it needs sophistication in the extreme. You can also call that
complexity. But I want it, thanks.

------
ralph84
Of course customers don’t say “I want complex software.” They say “I want
software that works well for my use case.” Except their use case is slightly
different than any other customer’s use case. You only have to have a few
customers like that before things start getting complex.

------
DiabloD3
I don't ask for software complexity, but I also want to be able to tell it
what I want it to do with absolute authority.

There will never be a happy medium.

------
devchix
What is the point of this article? "We want more complexity!" said no one
ever. People want ease of use, that attribute alone makes any software
complex. I once attended a presentation about downtime management. Take-away:
planned downtime is better than unplanned downtime. There should be an
adjective to describe these obvious trifles that somehow get spun into
articles and zen-like slides bullets. GOOPed, maybe; "I love the clean and
refreshed feeling I get after a bath." Because the rest of us don't love
feeling clean and refreshed, and need to be told.

------
iamleppert
People who think that anything and everything can be made simple, I've found,
are ignorant. Certain things are complex for a reason. The complexity
represents a certain individual or team's journey toward a working solution.

All of the projects I've been on that insist on going on that journey again
end up with a different, yet subtly more or less complex solution. There are
rare exceptions, but it's rather foolish to think that, given two roughly
equal teams or individuals a better result would be obtained.

------
PeterStuer
In my experience a business analyst talks to a business manager and they come
up with a simple 'sunny day' as-if story. This gets handed of to a developer
who notices information gaps and inconsistencies. After some initial back and
forthing the dev is told to go talk directly to the people actually doing the
work and inevitably discovers the management is completely clueless about how
their business is actually operating.

At this point one of two things happen. Management on both sides double down
and a system is build that on the very first contact with the users is shot
down into a never ending dead spiral of change requests and extensions before
it is eventually abandoned and replaced by a next clean slate attempt . Or,
more rarely, the as-if document gets ditched and the system is reconsidered
and the project gets amended to actually deliver something that can support
the real business operations.

------
egypturnash
"Customers and end-users never ask for software that is complex."

They do if they are expert users of very complicated toolkits. Look into any
art toolkit, for instance. 2D or 3D, as they age they add on more features.
Some of these features come from the dev team experimenting, some come from
cloning good ideas in the competition, some come from user requests. There's a
pretty steep learning cliff for Photoshop or Maya or Procreate or Blender.
There are a lot of settings in these things because there are a lot of ways
people use these things. And a lot of tools in these toolkits, many of which
have their own particular settings.

Power tools that let you do fundamentally complicated things have a level of
inherent complexity.

~~~
tonyedgecombe
It's more of a struggle with those sort of products. I've had feature requests
that I implemented because they sounded interesting but it turned out almost
no one used them.

I'm willing to bet tools like Photoshop are riddled with those as once you
have added a feature it's almost impossible to remove it.

~~~
egypturnash
Oh yeah, for sure, you've got thirty years of history and SOMEONE relies on
every single tool added over that as a crucial part of their regular workflow.

------
dathinab
True people want a solution which "just magically works out of the box".

A solution which can do all the needed thinks but is to complex => worthless.

A solution which is so simple that it can't do what the user wants to do as
this would be to complex => worthless.

Finding the right way to do thinks so that it simple _and_ can do what users
want it to do => really hard.

Example why it's hard?

The writer of that side "failed" because he use a font which is not simple to
read for people with eye problems. (Assuming his goal is that people read his
side. In which case it should be simple to read. Which it mostly is. Actually
it's better readable then many other sides. Except the font.)

------
themodelplumber
There seem to be a lot of different sentiments / topics built into the
article. On top of a big dose of emotion, there seems to be a question
presumed / begged right in the first sentence. I had to ask myself if somebody
_really_ asked for complexity, and if so, who? Maybe they meant something
other than what the author is thinking? Well--them's the risks of starting an
article that way.

This was pretty complex to sort out TBH. I'd say personally I don't mind
complexity as an outcome as long as the work environment is flexible and
allows for a winnowing-down or a reorganization of the product.

------
nenadg
Complexity is essential, without it we wouldn't know anything about anything.
Complexity is not an excuse for poor structure/performance/high price, but it
can be exactly that.

It's like there is some moral code of some devs out there not to use it for
their personal advantage. Others are doing it casually and exactly like that.

We should all fight it, and learn from it. There is no silver bullet, and we
probably don't have programming languages that good that we can struggle with
it with ease.

------
fizixer
If you think sticking to what the customer knowingly asks will lead to
elimination of complexity, I'm afraid you're going to have a bad time.

------
csours
Listen, I just want one button to filter out these records, it can't be that
hard!

Well, it wouldn't have been very hard if you had told us at the start of the
project...

~~~
tiku
my first step for now is to ask questions about it, why do they want it, what
other cases are there etcetera.

------
lerpapoo
the software that makes you the most money is the one which no one asked for
and the one that everyone used

------
asfarley
In the same way that nature does not ask for human brain complexity.

------
hindsightbias
Whomever wrote this, how about a CV of your software projects?

------
stickfigure
This is absolute nonsense. Customers ask for complexity, they just ask for it
indirectly.

The tax code is a perfect example. Nobody asked for thousands of pages of tax
code, but after you add up all the individual rules (each of which someone
asked for), you get thousands of pages. The business logic of any long-serving
application ends up like that, which is why we can't just replace all those
COBOL systems in a long weekend.

The hard part about software in the real world is not making software simple.
The hard part is pushing back on the real world to make _it_ simple enough to
model in software.

~~~
SilasX
My understanding is that the tax code complexity is (mostly) not from top-down
“let’s reward this”-style rules (ie what “customers” request), but of the
difficulty of defining “income” in a hyper-technically-precise way against
people heavily motivated to minimize it by that definition.

That is, “oh no, my tips are a gift, not income”. “Hey I didn’t get paid for
that job, I was just allowed to use the company car.”

That creates an arms race of ways to game it and more rules to say “no you
can’t do that either”.

But, more to the point, I’m not sure if such customer requests generate the
complexity even in the general case. JIRA, for example, has a ton of bloat,
very little of which is related to delivering good UX or features.

~~~
stickfigure
I don't quite understand your objection to the tax code example. In every
business domain there are real world constraints that cause people to want
business rules of ever increasing complexity. The IRS cares about the
definition of "income"; maybe your business cares about which ads get seen by
which users or how much you should charge for a cell phone plan. What seemed
simple at first is almost certainly incredibly complicated after 20+ years of
exposure to humans.

JIRA seems like another great example, actually. JIRA's key feature is that
any organization can customize workflows in whatever way they want. Is it slow
and bloated? Yes, all that customizability comes at a cost, even if you don't
use it. That customizability was driven by customer requests.

My organization uses Pivotal Tracker. It's fast and friendly. But it has
exactly one workflow and if you don't like it, tough. They aren't going to
sell a lot of licenses to Fortune 500s that way.

~~~
SilasX
>I don't quite understand your objection to the tax code example. In every
business domain there are real world constraints that cause people to want
business rules of ever increasing complexity. The IRS cares about the
definition of "income"; maybe your business cares about which ads get seen by
which users or how much you should charge for a cell phone plan. What seemed
simple at first is almost certainly incredibly complicated after 20+ years of
exposure to humans.

Because you were mapping (something like) "citizen-initiated policy requests
about what to reward/penalize" to "customer requests for software features".
To the extent that that mapping is valid, it is _not_ (I claim) the cause of
tax complexity. Rather, such complexity comes from the inherent difficulty of
operationalizing "income" against motivated parties, which (I claim) is more
closely analogous to "inherent domain complexity".

Now, to be sure, you can go back a level and frame "citizen desire to tax
income [without realizing the implied complexity]" as a "customer request with
inherent hidden complexity" \-- but still, you were claiming the source of tax
code complexity was from "desire to reward specific behaviors", which it
(still) isn't.

In short, "Let's reward electric cars" does very little for tax complexity
compared to, "oh crap, people can dodge virtually all their taxes by having
employers buy their personal needs".

>JIRA seems like another great example, actually. JIRA's key feature is that
any organization can customize workflows in whatever way they want. Is it slow
and bloated? Yes, all that customizability comes at a cost, even if you don't
use it. That customizability was driven by customer requests.

No. There is no inherent reason why being able to customize workflows comes at
the cost of e.g. a browser not being able to keep up with my typing speed or a
hundred trackers having to load every time. (There are a ton of other
unnecessary pains I've encountered unrelated to that but I'd need to check my
notes.)

~~~
stickfigure
> you were claiming the source of tax code complexity was from "desire to
> reward specific behaviors", which it (still) isn't.

Of course it is. The whole point I'm making is that the end result of a system
isn't what people asked for at the beginning. It's a result of countless small
decisions made by (often) countless people with a wide variety of motivations.
The definition of "income" is subjective. Short of a physics simulation,
humans are always part of the "inherent domain complexity".

I'm no fan of JIRA.... which is why I'm looking forward to your issue tracking
system with all of JIRA's flexibility and none of the performance issues. I
genuinely wish you the best of luck in this endeavor.

~~~
SilasX
Did you read my second and third paragraphs? I was agreeing that “asking to
tax income” is a case of “customer”-unrealized complexity and pointing out
that it still isn’t the kind of thing reasonably described as individual
rewards someone explicitly asked for.

> I’m no fan of JIRA.... which is why I'm looking forward to your issue
> tracking system with all of JIRA's flexibility and none of the performance
> issues. I genuinely wish you the best of luck in this endeavor.

Then it sounds like you’re walking back on your original claim that that
JIRA’s bloat and UX failures are an inherent result of asked-for things like
custom workflows?

