Don’t Shoot the Developer!

In this article I write about definition of “simple”, and acknowledging ones limits.

I will start with a statement that in a world of software development companies nothing is easy, literally nothing.

The moment when a developer touches the keyboard is actually the last part of his job, and probably the easiest one.

When approaching the development of a platform with advanced synchronization features (such as for example messaging), I often hear that since our company has experience with such systems it should be easy to reproduce it into another product. I won’t even start the discussion about legal side of this statement, but I feel that since the programming/software development/coding (call it as you like) is perceived as “black magic” by some, then they won’t even try to understand the challenges behind building a virtual product. Their logic is simple here — you’ve done that once you can easily do it once more — this is both true and false at the same time.

I understand that C-level company members do not necessarily have to understand everything when it comes to programming, but this only applies as long as they don’t want to “expertise the experts”. I believe that the reason behind hiring someone to create a virtual product is not only for their writing skills.

What if the king goes where even he goes himself?

In a real world you subconsciously assume and perceive some occurrences/states, you do not actually think about all the “what if’s” behind simple tasks you do every day. Brewing a tea, walking down the stairs, opening door, turning on the light — you do it everyday don’t you? Easy? I wonder how long it took for engineers from Honda to “teach” Asimo to jump on one leg (hint — long{:target="_blank"})

Let me set the background for the story I would like to share with you in following part of this article:

We travel back in time to a period in which there are no 
smartphones, tablets, laptops, TVs, even electricity. 
The only way to send a message between two kingdoms 
far away from each other is through a messenger.

How would a process of sending a message in this period look like? Someone writes the message, the message is being transported by the messenger, the addressee receives and reads the message. From King’s perspective sounds pretty simple. Well not exactly, at least not when you were to program it.

The following bullet list is just a tip of the iceberg of problems that such “simple” task would require addressing. Therefore, let’s take a closer look at some of the challenges that “someone” will have to think of before commencing the message transport:

1. Differences — He needs to be sure that a different messenger will be able to deliver the message in similar way the other one is, even though the purpose of the message, and the message itself is different. (/applying the same solution to a seemingly similar product needs to be investigated beforehand. There are no two identical things in the universe, everything is different).
2. Availability — he needs to be sure that there is a messenger, and he is available (/no internet connection).
3. Unexpected occurrences — He needs to be sure that the messenger is healthy, knows the road or received proper map with directions (/application error, not specified, caused by the developer).
4. Means of transportation — He needs to be sure that he will have a horse that he can ride (/no server response).
5. Transportation problem — He needs to be sure that the horse is healthy (/server error).
6. Backup plan — If the message has to be delivered, it has to be delivered on time and with certain text, he also needs to make sure that if something happens there is a backup plan to deliver the message. No one would like to start a war due to unreceived/misinterpreted message right? (/message can be wrongly formatted during its way, i.e. server might change its content, someone can intercept the message, alter it and pass it to the addressee).
7. Limitations — He cannot assume that the addressee will be waiting for the message all the time. He should predict a situation that the King might want to go for a weeklong hunting, and won’t be available. What should the messenger do with the message then? Wait? Who will pay for his and horses accommodation and food? (/the addressee has the application in background, the application should not refresh in the background due to battery and internet connection limitations).
8. Timing — What if another message that was planned to arrive later than the original one arrived earlier? (/If we use websockets, but the addressee is not connected then he has to wait for a fallback, i.e. GCM has to assume that the addressee is not connected to the internet so there is a possibility that during that time he receives X number of messages that has to be synchronized after he connects back).
9. Timezone — What if there is a timezone difference/daylight savings between kingdoms and no one thought of it? (/when setting a time for a certain message, the developer has to take in consideration the timezone in which the user is operating, if he does not do that, then there is no point of reference for the message. What if the user changes the date and time of his device? What if he mix it with different timezone setting? Should the message arrive according to time setting or real time? Therefore what information does a raw 1PM gives you?).
10. Different types of messages — What if the King wants to send a present to a Princess from another kingdom? Let’s say the present is a really big painting of himself (yes, our King has a huge ego, not surprising considering his role). This obviously would not be possible for a messenger to transport on a horse. The messenger would have to use a coach that will give enough space to carry such present. The problem here is that this coach is slower, bigger, more vulnerable, and moreover — all the rules of a regular message applies for the coach travel as well. (/transfer of bigger files have to be processed by a another server that can handle it, so we have additional place in which something can go wrong, and makes the whole process more complex).

Ignorance is not bliss

Above examples are just a few that a person responsible for message transport would have to predict. There are much more cases I could outline, but I think that you are able to get my point by now — the definition of “simple” changes based on your role, no matter the task and its place in time.

The bottom line is that there has to be someone that will make sure that even a “simple” task will be successfully finished, because the difficulty of a task does not determine its importance.

So if a messenger tells you that sending a message to a village few km away will be difficult, please remember that he is an expert, and try to understand why, it will make both yours and his life easier.

Credits to Mateusz Zagórski from AppUnite for his help with the article.