12 ms·

Customers do not ask for software complexity

109 points by runningmike 6y ago

DiabloD3 6y ago
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.
vimax 6y ago
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.
Icathian 6y ago
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.
- orblivion 6y ago
  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.
  - Icathian 6y ago
    I specialize in building internal analytics tools and apps, so my experiences are mostly with a single client or a small team running a business functional area.
- kevindong 6y ago
  > 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 6y ago
    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 6y ago
      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.
fizixer 6y ago
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.
nogabebop23 6y ago
>> 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 6y ago
  > 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 6y ago
    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 6y ago
      > 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.
ralph84 6y ago
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.
Reedx 6y ago
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 6y ago
  If it were up to me I would remove my entire garden.
themodelplumber 6y ago
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.
deleted 6y ago
[deleted]
MattGaiser 6y ago
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.
- jimktrains2 6y ago
  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.
  - MattGaiser 6y ago
    I've done this too and it was great as so many things are usually left out of the spec while priority goes to things which are rarely or never actually done.
  - iluvblender 6y ago
    I can attest to this. As a Technical Director supporting artists the tools I create for them are more effective when I study their process thoroughly and also get my hands dirty. Then design and implement the tool and it becomes my job to manage the complexity. Designing for change is something I keep in mind as well.
  - throwaway936482 6y ago
    Yep. This should be step 1 to n of designing software for end users. Understand what the users problems and needs actually are by watching them do their actual job rather than working from a description of what a manager three levels up thinks their job is.
stickfigure 6y ago
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.
- aaron-lebo 6y ago
  What's nonsensical about it? I feel like you are pretty much agreeing with them. Nobody really wants a complex tax code, either. If politics wasn't a game of compromise and design by committee, people would find something else to invest their time in other than hacking the tax code. Why do people love Steve Jobs, the mercurial guy he was? It's because he truly cared about user experience and there was that part of him that was obsessed with making things intuitive, which he mostly succeeded at. Nobody is like, I want this shit to be so complex, but they do want to have more and more functionality and want to be empowered. The problem is that people without a software background (and a lot that do without taste/experience/or a real concern for the user) have a hard time imagining how all of these little features add up into a big ball of mud. Rails became wildly popular because DHH understood the importance of good defaults with the ability to dig deeper if the user wanted. I can't get over the fact that I've discovered simple but powerful and obvious things like Bob Nystrom's Pratt parsing, and with a lot of time and care been able to pare more programs than I cant count from 1,000 to 300 lines, and so on. When you get down to it, apis can be as simple as a function and as complicated as a program, and we are bad, not as users, but as programmers at crafting monstrous interfaces at the low levels which echo throughout the codebase, because nobody (maybe business requirements) says ENOUGH like a Jobs. I bet you we've got dozens, hundreds of programs that are 10x, 100x bigger in raw size that they need to be. The user a lot of times doesn't know what they want or need until they see it, so it comes down to us, the designers to empathize and guide the user. You can have fast, cheap, robust, and flexible, and therefore "good", but you have to really care.
crazygringo 6y ago
> 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 6y ago
  I would call that “good agile”, a case where it actually helps by breaking things down into smaller, fully complete, fully productionized pieces.
franciscop 6y ago
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.
lerpapoo 6y ago
the software that makes you the most money is the one which no one asked for and the one that everyone used
hindsightbias 6y ago
Whomever wrote this, how about a CV of your software projects?
deleted 6y ago
[deleted]
ClownWorms 6y ago
Customers ask for all sorts of stupid crap that adds up to complexity. Why as a software developer would I have an issue with that? Every stupid thing they ask for is more money in my pocket.
rcfox 6y ago
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.
csours 6y ago
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 6y ago
  my first step for now is to ask questions about it, why do they want it, what other cases are there etcetera.
awillen 6y ago
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 6y ago
  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.
  - Supermancho 6y ago
    > And that is the way it is , always was, and always will be. Your statements are handwaving about magic solutions. "Always" is a long time. You would have historical examples, with requirements, to illustrate if your sentiments were true.
  - stupidcar 6y ago
    Many complex problems do not have simple solutions. This is a fundamental principle of computer science.
  - Ididntdothis 6y ago
    Dream on. Most business processes are convoluted and complex. You can only provide simple solutions if the customer works with you to also change their own processes. Some do, many don’t.
  - loa_in_ 6y ago
    Only if you mean "solution easy to understand by particular audience because it's tailed towards that particular audience" by "simple solution"
nenadg 6y ago
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.
jwilliams 6y ago
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.
dathinab 6y ago
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.)
robbrown451 6y ago
"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.
egypturnash 6y ago
"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 6y ago
  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 6y ago
    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.
iamleppert 6y ago
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 6y ago
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.
devchix 6y ago
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.
asfarley 6y ago
In the same way that nature does not ask for human brain complexity.

109 points by runningmike 6y ago

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.

vimax 6y ago

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.

Icathian 6y ago

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.

orblivion 6y ago
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.
- Icathian 6y ago
  I specialize in building internal analytics tools and apps, so my experiences are mostly with a single client or a small team running a business functional area.
kevindong 6y ago
> 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 6y ago
  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 6y ago
    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.

fizixer 6y ago

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.

nogabebop23 6y ago

>> 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 6y ago
> 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 6y ago
  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 6y ago
    > 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.

ralph84 6y ago

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.

Reedx 6y ago

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

themodelplumber 6y ago

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.

deleted 6y ago

[deleted]

MattGaiser 6y ago

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.

jimktrains2 6y ago
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.
- MattGaiser 6y ago
  I've done this too and it was great as so many things are usually left out of the spec while priority goes to things which are rarely or never actually done.
- iluvblender 6y ago
  I can attest to this. As a Technical Director supporting artists the tools I create for them are more effective when I study their process thoroughly and also get my hands dirty. Then design and implement the tool and it becomes my job to manage the complexity. Designing for change is something I keep in mind as well.
- throwaway936482 6y ago
  Yep. This should be step 1 to n of designing software for end users. Understand what the users problems and needs actually are by watching them do their actual job rather than working from a description of what a manager three levels up thinks their job is.

stickfigure 6y ago

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.

aaron-lebo 6y ago
What's nonsensical about it? I feel like you are pretty much agreeing with them. Nobody really wants a complex tax code, either. If politics wasn't a game of compromise and design by committee, people would find something else to invest their time in other than hacking the tax code. Why do people love Steve Jobs, the mercurial guy he was? It's because he truly cared about user experience and there was that part of him that was obsessed with making things intuitive, which he mostly succeeded at. Nobody is like, I want this shit to be so complex, but they do want to have more and more functionality and want to be empowered. The problem is that people without a software background (and a lot that do without taste/experience/or a real concern for the user) have a hard time imagining how all of these little features add up into a big ball of mud. Rails became wildly popular because DHH understood the importance of good defaults with the ability to dig deeper if the user wanted. I can't get over the fact that I've discovered simple but powerful and obvious things like Bob Nystrom's Pratt parsing, and with a lot of time and care been able to pare more programs than I cant count from 1,000 to 300 lines, and so on. When you get down to it, apis can be as simple as a function and as complicated as a program, and we are bad, not as users, but as programmers at crafting monstrous interfaces at the low levels which echo throughout the codebase, because nobody (maybe business requirements) says ENOUGH like a Jobs. I bet you we've got dozens, hundreds of programs that are 10x, 100x bigger in raw size that they need to be. The user a lot of times doesn't know what they want or need until they see it, so it comes down to us, the designers to empathize and guide the user. You can have fast, cheap, robust, and flexible, and therefore "good", but you have to really care.

crazygringo 6y ago

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

franciscop 6y ago

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.

lerpapoo 6y ago

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

hindsightbias 6y ago

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

deleted 6y ago

[deleted]

ClownWorms 6y ago

Customers ask for all sorts of stupid crap that adds up to complexity. Why as a software developer would I have an issue with that? Every stupid thing they ask for is more money in my pocket.

rcfox 6y ago

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.

csours 6y ago

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 6y ago
my first step for now is to ask questions about it, why do they want it, what other cases are there etcetera.

awillen 6y ago

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 6y ago
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.
- Supermancho 6y ago
  > And that is the way it is , always was, and always will be. Your statements are handwaving about magic solutions. "Always" is a long time. You would have historical examples, with requirements, to illustrate if your sentiments were true.
- stupidcar 6y ago
  Many complex problems do not have simple solutions. This is a fundamental principle of computer science.
- Ididntdothis 6y ago
  Dream on. Most business processes are convoluted and complex. You can only provide simple solutions if the customer works with you to also change their own processes. Some do, many don’t.
- loa_in_ 6y ago
  Only if you mean "solution easy to understand by particular audience because it's tailed towards that particular audience" by "simple solution"

nenadg 6y ago

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.

jwilliams 6y ago

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.

dathinab 6y ago

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

robbrown451 6y ago

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

egypturnash 6y ago

"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 6y ago
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 6y ago
  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.

iamleppert 6y ago

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 6y ago

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.

devchix 6y ago

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.

asfarley 6y ago

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