Everything is complex, but not everything is complicated

I decided to write an article in reaction to this “rant” tweet by Dan:

I personnaly share the rant and after a while, I thought it is worth writing about my personnal experience.

When I arrived at my first job, it was just after my high school.

I had done some python during high scool, as student project and as personnal project, so I had read python zen principles, especially:

# ..
3. Simple is better than complex.
4. Complex is better than complicated.
# ..

Back at the time I was pretty much rookie for everything related to communication especailly how to market your and discuss with your client.

I learned the hard way that it is never a good idea to market anything as “simple” !

There is multiple reason to that:

  • things are never simple, especially in computer science: when they look so, it is because people have done a great job to hide complexity via good abstraction
  • when you market something as simple, you devaluate yourself: after all, your are an exeprt. It took you time to learn what you may fond “simple”
  • moreover, you put yourself in a fix mindset situation where you now have to succeed, and if that is not the case, you have to hack a dirty solution: this is bad cause you will never learn what was not so simple after all

Things are not simple

Let’s look at it why an example:

Client: You just need to fetch and display the user list. Simple ?

Lets focus on the first part of that: fetch the user list.

That is business point of view. That is the final value to the user, really high level, low technicity.

In practique, that means that smartphone of the client will get some electrical signal after some while when some touch captors while handle some press then change some pixel accordingly. That the actual physical phenomenon happening.

And in between, … a sea of complexity !

Application level

Somewhere in some language the app while do some call to retrive the user list.

Lets say, you will do an HTTP GET https://superpoduct.com/users?filter=* to the REST Endpoint users.

Only in that there is a lot of complexity:

  • What is http? a protocol! What are the rules of this protocol?
  • In particular what is GET and why use it to fetch (and not something else like POST)? Some other api POST everytimes, like GraphQL! Is it good or bad, when and why?
  • How to specify the format we want to have, the external context parameters like the language/encoding of the results?
  • What can fail? What will you receive if that fail? Lets say, status 401, 403?
  • What does this mean? Are the status good practices? Are you really sure you can’t get something else, like a 503 or a 429 ?
  • You will probably probably need to authenticate yourself? How? Session, server generated token or JWT? How secure are they? What are the pro and cons of JWT compared to session?
  • You are using HTTPS! How does this works? What can be the flaws? Server side? Client side? How to verify that everything backend devs did is secure? Is there a chance that security can affect availability, on lower end device? What the impact? Is it super secure and if not what are the attack vector?
  • If you get the result using rest, how can you being sure that backend devs, when changing the api, won’t break the app.

It is already super complex, isn’t it ?

Network/Infrastructure level

  • You did look for superproduct.com? How internet it knows which server it is?
  • Are they only one server? Afterall, superproduct is really well known! How are the load balancing done? Is it resistant to failure (if a datacenter burn)? Is it consistant: what if every other calls, I’m logged out because I logged in on server A and I’m hitting server B?
  • Even if the internet figure out the destination B? What the itinerary A -> x1 -> x2 -> x3 -> B? What if the information is supposed to pass by a route x2 but due to strike, the route x2 has super high traffic jam? What are the alternative itinerary? How to diagnose from A and what to do?

Todo

Handle errors in functional way
Breaking the circular deps (part 1)