Here's another good example: what is the correct way to order multiple adjectives in English? If you are a native speaker, you probably don't have any idea, you just know that you say "an old big brown cardboard fridge box", rather than "a cardboard brown fridge old big box". The order is very specific and any deviation is obviously incorrect. Try it for yourself!

But any ESL student can tell you the order is quantity, opinion, size, age, shape, color, origin, material, purpose. We'd had to reverse-engineer the rules, and then teach it to newcomers.

Then it must be "big old brown cardboard fridge box".

Incidentally that’s exactly how I would have worded the sentence as a native speaker. But only because “big ol’” is a common phrase by itself

To me, also a native speaker (UK if it makes a difference), “big old” implies size alone(fairly large) rather than age, while “old big” would definitely mean old and large

I often use this as an example of an "unknown known" for most English speakers. We know how to order these things, but we don't know about the specific rules that govern their ordering and that we have (implicitly) mastered that.

As a native speaker I had no idea there was a proper order.

This is spot on and a terrific analogy.

There is human behavior and human beings' mental models of that behavior.

Your advice generalizes: As an engineer or scientist, never trust the models. At least not wholesale. They're simplified and inadequate, and the inadequacy is invisible to those using them.

Thanks, and good point about the generalization.

Reminds me of this recent post on the Grammarphobia blog: https://www.grammarphobia.com/blog/2020/02/adjectives-comple...

> We wish we could tell you that there’s a predictable pattern here—that certain types of adjectives can always be complemented by both participles and infinitives, while other types are always restricted to one or the other.

> Unfortunately, no clear pattern emerges. Different adjectives simply act differently in different contexts.

In other words, sometimes there isn’t a rule, even after intensive analysis. There’s just a bunch of individual one-off decisions that each happen to work to solve their problem, without representing a coherent policy.

Oof, boy is that true in software requirements as well. Good point.

Seems like that's why startups with a founder that is solving their own problem are more successful than ones doing otherwise.

That doesn’t make sense to me as a reply to the comment above. Such startups should then be useful only for the founder. The GP’s point is to build and get feedback from the users to revise it continuously. That’s how you know you’re solving the problem for someone who seems to have the problem.

The idea is that the founder was once, or still is, the "user". They know the problem because they had the problem, recognized that software could solve the problem, and started a company to make that software a reality.

Because the founder is a user, the founder knows what the solution should look like, and can guide development in the right direction. There's a tighter feedback loop when the user is inside your organization, and is managing the product itself

> the only way to really discover the requirements is to build the thing.

I totally get what you're saying here and in an ideal world, this would be it.

Unfortunately, we don't live in that world, projects have budgets and need to be delivered within a given interval.

They touch other aspects of the business and are interlinked with marketing, support, legal, financing and so on.

I think it's our job as software engineers to figure out the requirements. One issue we have in our industry is that we do a sub par job of educating people regarding how software works and giving them alternatives instead of binary yes/no answers.

I would say most developers (and I'm generalizing here) lack the communication/social skills to do so.

The key here is to strike a balance between features, budgets and deliverables.

That's way the most appropriate way to develop software is to actually create it piece by piece with the client side-by-side.

Unfortunately, there is such software development platform in which software can be 'sculpted' as if it was a statue, with the client being able to oversee what the software would do at every moment.

In practical terms, here is how software development should go:

1) open an empty canvas (for example in your browser). 2) ask the client what they want. They will say, for example, they want to see a bunch of posts and comments below them. 3) create a list of posts, on the spot. 4) create the ability to add comments below each spot. 5) ask the client 'is this ok?' 6) he/she may say no, so delete the above and restart. 7) otherwise, proceed with the next question 'what else do you want?'.

In the back end, the development mechanism shall create the databases and code needed to handle the tasks in the front end.

After all, the only 4 things we want a computer to do are these: create/search/modify/delete information.

This was essentially the story of how we built a successful software company at cPanel. Our customers would describe things like “I want a button that does this” or “a script that does that” and we had to make many assumptions about what they really wanted. Finally after determine we were spending massive amounts of time on unused features, we developed everything as a workable “beta” feature. The ones that we got a ton of praise or complaints on kept getting developed. The ones with silence stayed the same.

This was before heat map software and click tracking which can do a great job of augmenting customer feedback.

The key part that we found out is that if you take this approach, you have to couple it with high quality software support. We hired and trained folks who knew the entirety of our business and tech (Linux, DNS, HTTP, hosting, etc). Our tech support reps were paid much more highly than others in the industry but it gave us more benefits than just being able to support customers when beta software was ship to prod, it also gave us a training ground for future software engineers, QA folks, SysAdmins, and Product Managers.

What I think a lot of people forget is that software is one piece of the puzzle in solving a problem, it’s absolutely not the whole solution. If you design a process based around connecting with customers on a regular basis and having feedback flow throughout your company, you won’t have to “make perfect features”.

I’ve only worked with a small number of companies since that have understood this. Most I’ve worked with have created communication silos and sit in rooms trying to dream up the perfect set of requirements.

A marketing person would add this: you invent first what people then want. In other words, the way to create the requirement for something is to build it, not merely to discover existing requirements.

The "build it and they will come" hints at that; it's saying that if you build something, people will see the value and then convince themselves they needed it all along.

"Build it and they will come" is a line from a movie about ghosts playing baseball (or the main character hallucinating), not advice applicable to building products.

"Build a better mousetrap and the world will beat a path to your door" then. That's one my mother used to use a lot.

Obviously a lot of products are built by people who never ask anyone what their requirements are. Often those are the most successful products. Steve Jobs being the apogee of that approach to product design.

The line has long since been co-opted for that usage.

FIY in Software Engineering this is defined as a formal process with clients or Product Managers called 'Requirement Elicitation'.

Perhaps in some cases it approaches the linguists' approach, but the Requirement Elicitation I have actually witnessed looks more like a group of stakeholders in a room, writing on a whiteboard or something similar. Better is to make an MTP (minimum testable product), and put it in front of the user and have them tell you all the ways it's wrong.