back
134 comments
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.

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."

I disagree. I worked for a couple of big-six consulting firms, and my experience at the last one was that they could be pretty clueless and lazy about determining what the customer really needed.

I spent a goodly amount of time preparing a questionnaire about the client's business needs and purposes for doing ad-hoc database queries. None of the questions were leading or simply offered up a feature. They required some thought and would yield useful information.

The project manager was baffled by it. NO! he said, clearly flummoxed by this divergence from what apparently was his (and perhaps the firm's) lazy, half-assed approach: Look up all the available products for the customer's task, put all of the features they claim to offer in a big list with checkboxes next to them, and hand it to the client. This is exactly what I was told to do, in the rebuke I got for doing it right.

I referred to this as the grocery-list approach. Of COURSE the client is going to create an imaginary need for most of the features and check them off. Who wouldn't?

Another great example is "customizable UI." How many thousands of man-years of work have been wasted on this boondoggle?

That's the job.

A business software developer's job is to help the people you described overcome those problems.

Some have more money than others. Some are smarter than others. Some are better people than others. But ultimately, that's the job.

I have no sympathy for that view. I work for a large bank where getting anyone to write any line of code, even for non critical infrastructure, requires a huge amount of energy, frustration, and with anaemic results. Trivial things are overengineered to an absurd level. I estimate that it must take 3 hours of discussions, reports, chasing, conference calls for every minute of code written. And at the same time, while IT cannot deliver even the most trivial changes, they are trying to do everything they can to reduce the productivity of end users to a halt, preventing them from writing any line of code, using any sophisticated tool, locking down the platform, and basically perpetuating copy-pasting, email based processes forever.

There is code that I literally prototyped myself in a week and that I am told would take years to rewrite by IT.

I've had my best results when I shadow the people doing the work I'm building software to aid and even being trained and go through actually performing said task when possible. It's extremely enlightening to see how things actually happen.
> They quickly get tired of answering clarifying questions about it and ask developers to "just figure it out."

This one. I'm primarily familiar with the "internal customer" scenario, and so it becomes uncomfortable to have to go back and forth clarifying details that are crucial to the development of the solution but seem trivial or even entirely inconsequential to the 'customer'.

It highlights the size of the knowledge gap between 'customer', who's been doing their process for years and 'developer' who's just finished a project for a completely different aspect of the company and is therefore a blank slate as far as this new project.

Another poster mentioned sitting with the people that actually do the process. I can't see a good solution being possible without this - one way or another. That's the role of the Business Analyst isn't it? The translator between requester / user and developer.

I love it when I get the "just figure it out" because then my response is: So you want me to design the software for someone like me? Because that's exactly what I am going to do."

That usually gets them to rethink that one.

Some Agile here is also a good way out of these kinds of things. Quickly build something they can complain about, then fix it. Either they will start to take responsibility for their software (that is clearly theirs) or they will just keep burning money and that will put an end to it too.

However, who you are describing is actually a bad customer. So make sure you get PAID very regularly as you are on this death march and if you ever do not get paid, stop work immediately.

Indecision and abdication of responsibility are hallmarks of an incompetent customer.

There's not much to be done here except resort to office politics. Lean on throwing out their architecture and ideas when they say "just figure it out". Lack of direction from them is where you have to assert authority of your expertise - this is where they're giving up control. You essentially need to turn them into a source of simple problem explanation rather than having them give you ideas, unless they can produce code themselves. Determine if dealing with their technical misunderstandings is worth the time invested (few are actually interested in learning technology, but try not to assume).
That’s why communicating a ton and delivering small chunks of fully working functionality helps so much.
"just figure it out."

I always found they assigned the most junior and inexperienced person on their team to liaise with the developers.

Eventually I started putting a risk section in the proposal that covered stuff like this. What I found was the more they pushed back on the risks the more likely the risks would occur.

Dump them, those clients are not the ones you want :)

Ps. Raising prices mostly helps

Yup. This is how we end up w/ three motorcycles, a sofa, and goose duct taped together when we wish we could have just built a car.
>> 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.

> Your all-encompassing "simple model" is likely a high-level abstraction that is not implementable.

I find the simple models are usually easier to implement, but are made simple by ignoring details that are actually important.

The requirements should be seperated into "minimum in-out workflow or MVP", then slowly add features which are a balance between high priority and easy to implement (With a clear way of saying "No" to impracticle requirements). This is generally the "Agile" approach. However at some point its always better to have a complete architechture diagram and work from there.

Of course choosing between a monolithic approach or modular approach (or microservices) is also very important at the beginning of the project.

> 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.

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.

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.

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.

> 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.

Is this for a single client, or consumer software with lots of customers? When I use modern consumer software I feel like I'm dealing with a lot of what somebody else asked for.
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.
> 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.

I would call that “good agile”, a case where it actually helps by breaking things down into smaller, fully complete, fully productionized pieces.
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.

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.

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.

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

If it were up to me I would remove my entire garden.
"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.

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.
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.

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.
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.

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.

"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.

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.)

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.

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.

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.
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...

the software that makes you the most money is the one which no one asked for and the one that everyone used
In the same way that nature does not ask for human brain complexity.
Whomever wrote this, how about a CV of your software projects?
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.