A Note on Essential Complexity

I feel like this article over-complicates things by using a strange definition of “essential complexity”: That if a user says that something is necessary, than that is essential complexity. Personally I never assume that the user has distilled a problem down to its essence. Regardless, my process looks a lot like what the author recommends: Question assumptions, propose alternatives, eliminate work, etc.

This is addressed in the second half of the article

> Strictly following Moseley and Marks’s definition, the fact that we can get the user (or the customer, or the product owner) to accept a change of requirements, implies that the removed complexity wasn’t essential in the first place.

Let me editorialize that:

> Strictly following Mosley and Marks’s different definition because it’s strange and I can easily poke holes in it…

Again, I’m not sure why it was necessary to “strictly follow” that bizarre definition of essential complexity, one that seems to define anything a user says as “essential”.

Essential complexity is what program must model based on user needs. Modelling is done for the end user. That's why author mentioned "user says". It's not like "user understands how to describe what they need" rather "we model what user needs". Users will often ask for impossible or contradicting features and can't understand that without our help. I agree that average user will need a lot of help and work to define what they need/want.

Practical example of my abstract description.

User does not want cdn-cached, region-distributed, lambda-backed resizing and validating image services, usage of the latest image compressing formats with fallback for the older browsers with performance dashboats of speed of loading. User wants to see their profile photo on profile page. Showing that photo is an essential complexity as it comes from the end user needs.