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.
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.
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.
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.
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.
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.
>> 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.
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.
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.
> 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.
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.
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.
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.
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
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.
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'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.
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.
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.
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.
Really good point. I think this is why it’s easier to develop useful software if you are someone who ends up being a user of the software since you have the same problems. You automatically have all the needed empathy.
Same here. Unfortunately there are a lot of middlemen who want to get in between and filter that information. It’s a constant battle to be allowed to stay in touch with the actual users. It doesn’t help that a lot of devs don’t really want to interact with users feeding the stereotype that developers need to be told what to do.
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."
Make an app that texts a contractor those questions and lets them drop a pin on a map. Then bill 250,000 a year for the contractor and call it software as a service.
As as art project, someone made a camera that, when you snap the shutter, prints out a text description instead of an image. Under the hood, the camera actually submitted the image to Mechanical Turk.
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.
What you're describing would be a nonstarter in retail in my experience. They care too much about customer experience to amortize the cost of a bad experience. Typically, step 1 is capturing data via added company process about the thing you're gonna automate. A lot more boring than what you describe.
no, that's exactly what i described. a paid existing employee collecting location data while stocking.
i actually do think that customer-finding is a good approach, but it's up to the client to decide isn't it. the comment i'm replying to was about impossible requests by clueless clients, not about bad but possible implementations.
even if the idea is in fact bad, which again i dispute, it's always good to give a client an alternative that stinks, so that the idea you want them to accept seems "obviously" good. i forget what this technique is called.
EDIT: after an hour of searching, I believe it's called a "duck". based on the legend of Battle Chess, but of course the technique has existed long, long before Battle Chess.
>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.
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.
In other words, nobody has an idea how it will work.
ML doesn't generate essential data for you, or solve problems which you cannot reasonably describe a solution for.
Most modern supermarket chains are organized in such a way that location data should be available (or at least calculable). To assert that there is no "system" to a store's layout and that employees know through "experience and gut-feeling" means that this retailer was not conforming to industry norms or was just not a very large retailer. All supermarkets have some sort of product taxonomy, categories and subcategories, that influence the macro-placement of a product within the store. This discipline is known as "space planning", where large categories are placed within the foot print of a store's layout. Within the category placement, stores use "planograms", which are shelf-by-shelf layouts of which products go where, how many facings they have, how much footage is designated to the sub-category, etc. While its true that workers for the most part know the locations of items by experience, this experience is informed by their ever growing knowledge/intuition of this taxonomy. (Usually, products are organized by aisle in the backroom when the delivery comes in; workers are simply taking groups of products that have already been organized out to the floor). The planograms themselves are usually stored in a database, and this data could be cross-referenced with other common data sources (product, pricing, etc.) to determine store location.
You forgot about the manufacturers who pay for specific product placement. Sometimes the store workers will only have a vague idea because the supplier has been given full responsibility for shelf layout.
This usually only applies to certain categories and depends on the pricing model of the supermarket (and the supplier/purchaser power dynamics that depend mostly on the size of the retailer). Soda, chips, crackers and cookies are the most prominent categories that have any significant amount of placement power, and that's mostly because the big players use a direct store delivery model that helps alleviate labor costs at the store level.
Apparently, you are not familiar with Trader Joes. Some (all?) of their stores regularly rearrange the entire store. My assumption has been that they are hoping for you to serendipitously discover new products/categories and purchase them. The produce section generally seems to remain fixed.
Slightly offtopic of this discussion but I am wondering if you (or anyone) knows why Home Depot does not set up every single store the same, identical way? Sometimes stores are mirror images of each other and sometimes electrical is in the front and sometimes its in the back.
It seems so inefficient. I can sort of understand having the garden center on either side of the building depending on the lot but the inside of the store being different from location to location is baffling to me.
Wouldn't the entire ecosystem from people who stock shelves, to customers to store managers benefit from an identical layout in every store nationwide?
I'm picking on home depot here but the same question could be asked of any big box store.
I feel your frustration with Home Depot in particular - I live right in between two stores with wildly different layouts, and it drives me bonkers. One store seems to have the "traditional" layout, that I can successfully navigate off of general muscle memory from stores past. The other has departments placed so differently that I end up walking to where something "should" be, register I'm in the weird store, and open up the minimap in the app to find where I actually need to go.
From what I can tell, it's based mostly on optimizing to the local foot traffic. The one that throws me off seems to be more consumer focused. It's in a suburban area and has a _lot_ more internal space dedicated to home decor (lighting, curtains, flooring, etc). Then every other department seems to be rejiggered like Tetris blocks to fit within the remaining space.
The store with the more intuitive/familiar layout has mostly the same product assortment, but far less space dedicated to displays and "consultation" style areas (the consumer oriented store has an entire section carved out for custom curtains, complete with an associate consultation counter).
I can tell you that most major retailers (target, walmart, etc) most definitely have a system. It not only specifies which aisle to put things on, but exactly which shelf, and how much space is allocated for that product. I can't remember what they're called, but they're required for every product sold in those stores. When I worked at Walmart in college, we were issued these plans weekly. Obviously this is probably not the case with smaller retailers.
I don't know how long ago "once" is, or how big this client was, but every modern large grocery company is pretty data-driven, especially about where products are placed. Lots of places have robots crawling the aisles in real time updating stocking information and taking video/images of product presentation on the shelves. They are presented as "cleanup robots" and they put googly eyes on them and a name tag or whatever. I even once asked several employees about them, and they just shrugged and said "yeah it's the cleaning robot." But it's a column 6 ft high it's not a roomba. It has a clearly visible array of cameras on each side, and who knows what other sensors.
This is true but generally only for grocery and a handful of the big box retailers.
The merchandising information is typically well known along with product taxonomy, but the mapping of this relative information to a physical layout isn't always cleanly implemented or available.
A typical scenario is sku 85111 is grouped in a product hierarchy (family > sub category > subdepartment > department or the retailer equivalent) and that sku is assigned to a planogram or set of planograms associated with a display fixture (which sometimes have a hierarchy of their own (e.g. peg > shelf > section > aisle) with mixed relative distancing. There's generally a departmental divide between who manages product and merchandising information.
Many of these robots to my knowledge use the products or special tags as unique identifiers as opposed to an indoor-positioning system that ties back to an exact product location. So it's frequently easy to say that a product is in aisle 20 section 2 shelf 1 it's not easy to say from your current location go down 8 aisle and up half an aisle, look on your left.
Your replies are a mixture of "This sounds false - large supermarkets would have this data" and "This is just an ML use case" and i think both miss the point.
Work backwards from the customer need. If they truly need this system, and are willing to pay for it, then it sounds like what you need to build is:
* A database for product taxonimies/locations
* An internal tool to make it easy and quick for staff to go through and log the locations of products to build out the data model
* The actual maps UI and display tech.
The thing is, this might not even be that much work. It's all a factor of how many "categories" the store expects customers to be able to search for. If the granularity level is "pasta", you can probably get away with 100 entries, and 1 days of grunt work for a staff member to log the location in the store where "pasta" and "coffee" and "condiments" etc are.
This story is not a good example of a difficult customer or a difficult technical problem.
Seems like a perfectly good request. Stores have an incentive in providing this information, as they currently have to pay employees to provide this information directly to customers. When I was a retail employee (Kmart, in the 80s) it took a long time to learn this information, and it wasted a lot of my time. (as often as not, I had to ask someone else for the first few months)
I wasted a 3-4 minutes of a Safeway employee's time in this way the last time I was there a few days ago (I couldn't find birthday candles).
Theoretically, the solution you described would probably save a ton of money overall. I have no doubt it will exist in the not-so-distant future.
Yes when using the word "waste" I am comparing it to being automated, which it most certainly can. Just as we might consider it a waste to have an elevator operator, when that task has been automated for nearly a century. At one time it was just accepted as a cost of running a tall building.
You're still missing the point. There is a point where the systemic rigidity enforced to make automation feasible is far more expensive than the value it actually produces by existing.
I.e. In order to replace those store employees, you have to build all your buildings the same way, stock them in a certain way, hire maintainers to input tracking data, hire auditors to ensure customers aren't tampering with the store.... So on and so forth.
It'd be a great way to protest though. Every customer goes out of their way to disorganize the store until they hire locals.
Of course the economics has to justify it. And they will. Everything you say could be applied to just about everything that has been automated in the past. I mean, it sounds like someone arguing "but librarians can do this or that that Google can't do." And yet, most of the time, when we need information, we can find it a whole lot more quickly than going to a library and asking someone for help getting us what we need.
In this case, there will still be store employees if the system fails to identify what a customer wants. But that will be the exception, and asking for help finding things will be like, today, someone asking for directions at a gas station. Most of the time, you can just say "where are the birthday candles?" to your phone and it will tell you, and it will have been far less effort for both the store and the customer vs. having to go find and employee. (and yes, I'm counting development time, entry time, and all that, averaged out)
For a typical Safeway or Home Depot or Target, there are already tons of benefits to keeping track of their inventory and where it goes on shelves. It's already almost certainly in a database somewhere. They need this so they don't have to spend so much time training employees, for one thing.
I guess all I can say is, come back in 5 years. I'd bet big money you will see this, whether in Google maps or in the various apps by retailers. (I mean, even 10 years ago their was an app that did this on some level: https://mashable.com/2010/11/22/aisle411/ )
Yes. It seems like a fairly obvious idea and I have no doubt it will become more and more widespread and built into general purpose apps (such as maps)
"Oh no", he said, "there is no system. They know through experience and gut-feeling."
Let me guess, this person is under 30. Not to be that old angry, ageist person, but that combination of ignorance, arrogance and complete dismissal of the entire history of humans beforehand is pretty annoying at this point.
Aside from an interactive map being overkill, are you sure you weren't complicating things here too? It seems like you were expecting some sort of system integration, but the customer wanted to just email an excel spreadsheet when there were updates, if they'd even thought of that.
Maybe the workflow could be reversed. First let the workers put the product wherever they feel like; then get the information into the application. From user perspective, the easiest way would be to take a photo of the shelf using their smartphone. (Either the worker is required to take the photo after putting a product on the shelf, or you would have another worker periodically walking through the shop, making photos. I assume the products do not change their places often.) The picture would be analyzed, possibly additional questions asked. The image recognition could be helped by a database that would know which products are typically placed next to which ones.
Okay, I assume the client's next question would be: "Why does it take 10 years and 10 million dollars?"
That's the job, it's a huge job taken a whole and to do that job, a variety of systems have arisen; object orientation, functional programming, agile process, etc, etc. All of these tools for helping to decrease complexity. And professions are generally studying at least some of these to "up their chops", so to speak.
The thing is, I think the GP was responding to the OP's headline "customers do not ask for software complexity". And the thing is, of course customers ask for a variety things that imply complexity. And, unlike what the OP's discussion, the particular soft approaches that been partly, however much, successful in preventing customer demands from spiraling into unmanageable complex have been ways of dealing with discreet, defined, parts of the development process. The problem with the OP, the article, is that it's a panacea, a vague and general call to make complexity unnecessary with either only a vague explanation of how to do this or an explanation hidden under several layers of rhetoric. "But designing simple software solutions is not simple and requires good principles along with solid experience." I could substitute "supply chains" or "aerospace solutions" and have something plausible sound though I know little about these. Which is to say I don't see OP offering things to make my job (or my former job) easier.
> And the thing is, of course customers ask for a variety things that imply complexity.
That's a claim one could make. If you're going to make it, you need to be ready to defend it. "A implies B" is typically not the case in the sense of "gravity causes objects to fall towards the ground".
Nobody's questioning whether it's "the job". The point of contention is whether the job can always be done without writing complex software. And the answer is no.
It sounds to me that the list of things make the software difficult to make, not complex. We add a lot of complexity by the technical choices we make. See accidental complexity vs essential complexity.
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).
An internal project budget is to prevent other teams from just endlessly requesting features from the internal developers, i.e. they cannot treat the internal development team as free. It also prevents them from hoarding the developers.
Most of the time the billing is just budget shuffling.
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.
These 2 things can and do both exist - they both represent a pretty worst-case outcome respectively for users and for IT teams. I feel I’ve worked at both these places.
I don't disagree. I don't really know anyone working for tech companies, particularly startups. But outside of tech, everyone I know (in various sectors) has the same stories about their IT dept. So I think that this tendency to over engineer and deliver nothing is more than an isolated anecdotical experience.
Think about the great lengths that good technology companies go to to get decent productivity. They have to work very hard to get it - companies that don't understand it won't.
What you have is incredibly common in non-technology companies. Good engineers are now very hard to recruit and expensive. Unless your company values them enormously, your engineers are going to generally be pretty mediocre[1]. On top of that, your company isn't going to understand engineering projects - when you need to invest in infrastructure, tooling and technical debt.
These factors together multiply up over time until everything grinds to a halt.
[1] An aside - in my experience of organisations like this and also mediocre engineering organisations, there is usually one guy who knows his stuff, and is holding it all together. Some of it is like Brent in the Phoenix project, but some of it is that the rest of the people are just rubbish.
Out of curiosity, are there any common themes on why that person (ie Brent) sticks around? Part of me wants to say that if a company is so disfunctional that one engineer (or a handful of engineers) prop it up, it deserves to fall over
There's a few options. The easiest to understand and the least likely is that they like being the big fish in the small pond. They enjoy being in demand from everyone around them.
More commonly it's a lack of ambition and a comfort with where they are. They're happy with their environment, they don't want to to risk the change and they don't see why they would. They may have only worked in that sort of place (or only in that one place), and haven't seen how much greener the grass might be elsewhere.
So why not outsource important stuff? Freelancers and dev houses have the needed expertise. They'd be head over heels since it's a large bank and would probably pay well. Many big organizations can surely afford hiring people with the know-how even at $100/hr if it boosts productivity and gets things done.
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?
> 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.
The business analyst can help with translation, but at the end of the day for questions such as, "is the expiration date exclusive or inclusive?" or "what time zone should be used and for which contracts?" he has to ask just like everyone else.
There are many questions only relevant to the digital domain.
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.
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.
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.
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.
Jobs famously ignored what customers asked for though.
Customers did not get direct input into what he built.
>
“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.”
Many devs don't even get input into the feature, yet alone the ability to ignore customer input when they believe it to be wrong.
Exactly! I worship at the altar of Steve. I've got a shrine in my house. That quote is kind of at the heart of what I wrote.
It's why I said:
> 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.
Users do not want complexity, they want to be empowered. There is a subtle but important difference there and it's easy to disguise the latter as the former.
Is that a quibble over semantics? It might be. But to call the post "nonsense" is just as much of a quibble, because there's real truth there, the success and adoption of the Mac etc is proof of it.
Apple is pretty unsuccessful at most _software_ that isn't a commodity. They're a hardware and marketing company at their core. All the actual value from software on their platform comes from 3rd party providers, whether that's apps or SaaS.
The easiest point to make on this is that Apple has botched all of their SaaS offerings not related to content. And their office applications are borderline unusable for anything aside from education or the content industry. Everyone adopts either Google Suite or Microsoft Office (or a combo) depending on their use case.
It's highly arguable that Apple "empowers" people with software given that everybody uses software on top of their platform not provided by Apple.
You're right. That may be a poor example given that their forte isn't software. I don't believe the process is very different, though.
To give another example: I don't think users really want Ruby's parser to be 10k lines of C or whatever, whether they directly know that or not. Nobody really wants to maintain that, nor do people really want to think about corner cases it causes. They do want a beautiful and expressive syntax, though, which can be achieved by cutting a few features. You can write an almost Ruby parser, or something better, in 500 lines and I'm not exaggerating.
If that's happening at the development level, then it's happening everywhere.
that quote is way more (personal) branding than operational imperative. yes, jobs trusted his intuition and had purposeful influence, but he had thousands of people around him that also performed and integrated market research in honing their products for good UX. it was never just one guy magically making perfect choices to the delight of the masses.
The buck has to stop somewhere. If Jobs did not drive the company that way, you could have 100k people under him doing that stuff and it wouldn't be readily apparent. I mean, look at the slow decline of the company after he left the first time, as they chased more and more options for users.
He's also notorious (any of his bios will show this) at direct and obsessive involvement in product and even store design.
apparently it needed saying--the parent post by @MattGaiser claimed customers, and even developers, at apple didn't get a direct say in product because of jobs. but that's clearly not the case. yes, jobs had great influence, but so did thousands of other stakeholders.
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.
Yes but those changes are going to be trivial compared to the arms race dynamic I described. The changes from political pressure are debated in one place, yearly by a small number of people, but the growth of anti-gaming regs are a defense against the innovations of 300 million filers.
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.
>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.)
> 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.
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?
But some people actually DID ask that the tax code be thousands of pages. For one, tax preparation firms. For another, anti-tax advocates. Both of them advance their goals directly as a result of the complexity of the tax code, regardless of the underlying rules.
(Anti-tax advocates would prefer taxes not to exist. But they want taxes that do exist to be painful, as a tactic to increase anti-tax sentiment.)
> 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.
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.
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.
> 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.
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.
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.
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.)
"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.
"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.
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.
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.
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.
140 comments
[ 1.5 ms ] story [ 363 ms ] threadThere will never be a happy medium.
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.
Wanting virtually unlimited flexibility inherently already dooms a project to be complex. That's before talking about timeframes and budgets.
Mostly though, yeah, you pretty much nailed it.
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.
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.
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.
I find the simple models are usually easier to implement, but are made simple by ignoring details that are actually important.
Of course choosing between a monolithic approach or modular approach (or microservices) is also very important at the beginning of the project.
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
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.
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 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 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.
i actually do think that customer-finding is a good approach, but it's up to the client to decide isn't it. the comment i'm replying to was about impossible requests by clueless clients, not about bad but possible implementations.
even if the idea is in fact bad, which again i dispute, it's always good to give a client an alternative that stinks, so that the idea you want them to accept seems "obviously" good. i forget what this technique is called.
EDIT: after an hour of searching, I believe it's called a "duck". based on the legend of Battle Chess, but of course the technique has existed long, long before Battle Chess.
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.
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.
In other words, nobody has an idea how it will work. ML doesn't generate essential data for you, or solve problems which you cannot reasonably describe a solution for.
It seems so inefficient. I can sort of understand having the garden center on either side of the building depending on the lot but the inside of the store being different from location to location is baffling to me.
Wouldn't the entire ecosystem from people who stock shelves, to customers to store managers benefit from an identical layout in every store nationwide?
I'm picking on home depot here but the same question could be asked of any big box store.
Perhaps they simply don't mind customers having to wander or ask though.
From what I can tell, it's based mostly on optimizing to the local foot traffic. The one that throws me off seems to be more consumer focused. It's in a suburban area and has a _lot_ more internal space dedicated to home decor (lighting, curtains, flooring, etc). Then every other department seems to be rejiggered like Tetris blocks to fit within the remaining space.
The store with the more intuitive/familiar layout has mostly the same product assortment, but far less space dedicated to displays and "consultation" style areas (the consumer oriented store has an entire section carved out for custom curtains, complete with an associate consultation counter).
Check out this image search, for "grocery data cleanup robot": https://www.google.com/search?q=grocery+data+cleanup+robot&r...
The merchandising information is typically well known along with product taxonomy, but the mapping of this relative information to a physical layout isn't always cleanly implemented or available.
A typical scenario is sku 85111 is grouped in a product hierarchy (family > sub category > subdepartment > department or the retailer equivalent) and that sku is assigned to a planogram or set of planograms associated with a display fixture (which sometimes have a hierarchy of their own (e.g. peg > shelf > section > aisle) with mixed relative distancing. There's generally a departmental divide between who manages product and merchandising information.
Many of these robots to my knowledge use the products or special tags as unique identifiers as opposed to an indoor-positioning system that ties back to an exact product location. So it's frequently easy to say that a product is in aisle 20 section 2 shelf 1 it's not easy to say from your current location go down 8 aisle and up half an aisle, look on your left.
Work backwards from the customer need. If they truly need this system, and are willing to pay for it, then it sounds like what you need to build is:
* A database for product taxonimies/locations * An internal tool to make it easy and quick for staff to go through and log the locations of products to build out the data model * The actual maps UI and display tech.
The thing is, this might not even be that much work. It's all a factor of how many "categories" the store expects customers to be able to search for. If the granularity level is "pasta", you can probably get away with 100 entries, and 1 days of grunt work for a staff member to log the location in the store where "pasta" and "coffee" and "condiments" etc are.
This story is not a good example of a difficult customer or a difficult technical problem.
I wasted a 3-4 minutes of a Safeway employee's time in this way the last time I was there a few days ago (I couldn't find birthday candles).
Theoretically, the solution you described would probably save a ton of money overall. I have no doubt it will exist in the not-so-distant future.
I.e. In order to replace those store employees, you have to build all your buildings the same way, stock them in a certain way, hire maintainers to input tracking data, hire auditors to ensure customers aren't tampering with the store.... So on and so forth.
It'd be a great way to protest though. Every customer goes out of their way to disorganize the store until they hire locals.
Of course the economics has to justify it. And they will. Everything you say could be applied to just about everything that has been automated in the past. I mean, it sounds like someone arguing "but librarians can do this or that that Google can't do." And yet, most of the time, when we need information, we can find it a whole lot more quickly than going to a library and asking someone for help getting us what we need.
In this case, there will still be store employees if the system fails to identify what a customer wants. But that will be the exception, and asking for help finding things will be like, today, someone asking for directions at a gas station. Most of the time, you can just say "where are the birthday candles?" to your phone and it will tell you, and it will have been far less effort for both the store and the customer vs. having to go find and employee. (and yes, I'm counting development time, entry time, and all that, averaged out)
For a typical Safeway or Home Depot or Target, there are already tons of benefits to keeping track of their inventory and where it goes on shelves. It's already almost certainly in a database somewhere. They need this so they don't have to spend so much time training employees, for one thing.
I guess all I can say is, come back in 5 years. I'd bet big money you will see this, whether in Google maps or in the various apps by retailers. (I mean, even 10 years ago their was an app that did this on some level: https://mashable.com/2010/11/22/aisle411/ )
Let me guess, this person is under 30. Not to be that old angry, ageist person, but that combination of ignorance, arrogance and complete dismissal of the entire history of humans beforehand is pretty annoying at this point.
Before software people managed pretty well!
Okay, I assume the client's next question would be: "Why does it take 10 years and 10 million dollars?"
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 work for a contractor that does government agency work so the longer we can't figure it out, the longer I get paid an absurd amount.
That's the job, it's a huge job taken a whole and to do that job, a variety of systems have arisen; object orientation, functional programming, agile process, etc, etc. All of these tools for helping to decrease complexity. And professions are generally studying at least some of these to "up their chops", so to speak.
The thing is, I think the GP was responding to the OP's headline "customers do not ask for software complexity". And the thing is, of course customers ask for a variety things that imply complexity. And, unlike what the OP's discussion, the particular soft approaches that been partly, however much, successful in preventing customer demands from spiraling into unmanageable complex have been ways of dealing with discreet, defined, parts of the development process. The problem with the OP, the article, is that it's a panacea, a vague and general call to make complexity unnecessary with either only a vague explanation of how to do this or an explanation hidden under several layers of rhetoric. "But designing simple software solutions is not simple and requires good principles along with solid experience." I could substitute "supply chains" or "aerospace solutions" and have something plausible sound though I know little about these. Which is to say I don't see OP offering things to make my job (or my former job) easier.
That's a claim one could make. If you're going to make it, you need to be ready to defend it. "A implies B" is typically not the case in the sense of "gravity causes objects to fall towards the ground".
Ps. Raising prices mostly helps
I have never heard of internal customers, I have heared of internal projects ;) . But then the cost are not discussed, deadlines are.
And it's still the mission of the product manager to coordinate features to build.
In case it's only 1 developer, he has to take the lead and say pro's and cons.
Most of the time the billing is just budget shuffling.
Budget shuffling or not. ( I didn't say work is perfect, but experienced people can make it more doable)
There is code that I literally prototyped myself in a week and that I am told would take years to rewrite by IT.
Its difficult to see all perspectives in organizations and operations as complex as this.
That's generally why management gets paid what it does. Although they're not any more immune to this exact problem...
What you have is incredibly common in non-technology companies. Good engineers are now very hard to recruit and expensive. Unless your company values them enormously, your engineers are going to generally be pretty mediocre[1]. On top of that, your company isn't going to understand engineering projects - when you need to invest in infrastructure, tooling and technical debt.
These factors together multiply up over time until everything grinds to a halt.
[1] An aside - in my experience of organisations like this and also mediocre engineering organisations, there is usually one guy who knows his stuff, and is holding it all together. Some of it is like Brent in the Phoenix project, but some of it is that the rest of the people are just rubbish.
More commonly it's a lack of ambition and a comfort with where they are. They're happy with their environment, they don't want to to risk the change and they don't see why they would. They may have only worked in that sort of place (or only in that one place), and haven't seen how much greener the grass might be elsewhere.
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?
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.
There are many questions only relevant to the digital domain.
That's just one more layer between you and the person doing the work.
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.
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.
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.
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.
Customers did not get direct input into what he built.
> “Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.”
Many devs don't even get input into the feature, yet alone the ability to ignore customer input when they believe it to be wrong.
It's why I said:
> 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.
Users do not want complexity, they want to be empowered. There is a subtle but important difference there and it's easy to disguise the latter as the former.
Is that a quibble over semantics? It might be. But to call the post "nonsense" is just as much of a quibble, because there's real truth there, the success and adoption of the Mac etc is proof of it.
The easiest point to make on this is that Apple has botched all of their SaaS offerings not related to content. And their office applications are borderline unusable for anything aside from education or the content industry. Everyone adopts either Google Suite or Microsoft Office (or a combo) depending on their use case.
It's highly arguable that Apple "empowers" people with software given that everybody uses software on top of their platform not provided by Apple.
To give another example: I don't think users really want Ruby's parser to be 10k lines of C or whatever, whether they directly know that or not. Nobody really wants to maintain that, nor do people really want to think about corner cases it causes. They do want a beautiful and expressive syntax, though, which can be achieved by cutting a few features. You can write an almost Ruby parser, or something better, in 500 lines and I'm not exaggerating.
If that's happening at the development level, then it's happening everywhere.
The buck has to stop somewhere. If Jobs did not drive the company that way, you could have 100k people under him doing that stuff and it wouldn't be readily apparent. I mean, look at the slow decline of the company after he left the first time, as they chased more and more options for users.
He's also notorious (any of his bios will show this) at direct and obsessive involvement in product and even store design.
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.
See Mayhew's Congress: The Electoral Connection, or literature on path dependency.
https://www.amazon.com/Congress-Electoral-Connection-David-M...
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.
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.)
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.
> 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?
(Anti-tax advocates would prefer taxes not to exist. But they want taxes that do exist to be painful, as a tactic to increase anti-tax sentiment.)
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.
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.
Why as a software developer would I have an issue with that? Every stupid thing they ask for is more money in my pocket.
> 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.
Well, it wouldn't have been very hard if you had told us at the start of the project...
This is like saying customers don't ask for wheels and a motor, they just ask for a car that is capable of driving.
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.
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.
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.
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.)
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.
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.
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.
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.