I often spend my weekends in different sport centers as a parent supporter. As someone who had the opportunity to be part of a very positive and committed team in my youth I want my kids to experience the same thing. Coaches and trainers and other people in the club who take active roles are the biggest contributors and parents help out occasionally with some tasks.
Today it was my turn to be the secretary for a match. When I was a kid I don’t think we even had a secretary, just the referee and maybe some children turning numbers on the score board – a physical board made of plastic. But these days scores should be reported digitally in real-time with in a web application to a central system and anyone, anywhere are able to see the results on their mobile phone.
As secretary you need to be alert and focus on what happens on the court and follow each signal from the referee. The game is fast and missing a goal for one team will not make you popular.
I do not want to make any big mistakes so I feel a small tension but this should be fine by me – I know the rules of the game and I am working with computers for a living.
I have prepared at home and made sure I am able to login and I have searched and found the match to administer.
Before I enter the secretary table by the midline of the court I speak with someone from the audience who just got some information about a bug in the secretary application.
“When you register a goal – don’t use the button for goal… If you do – three goals will be registered. Use this other button instead…”.
That sounds strange. But at least I have a workaround so that should work.
After entering the secretary table next to the midline of the court, connecting to Internet and double-checking the numbers of each teams players I am ready for the game to start.
The match starts in a high tempo. One goal and right after that, one more goal. But when I register the third goal the systems does not respond.
I probably just have to wait a few seconds… Before the system has updated the second goal, a fourth goal is made… I need to remember which player scored this time and must not forget who scored the third one…
The system still does not respond.
I try to reload the application page in the web browser. This has worked before when the match clock was bugging…
The application comes to live again. But only the first goal is registered. The second one is lost! I cannot work with this application! I will be an epic failure as secretary…
I signal to the referee to stop the match and everyone at the court has to wait for me to pick up some paper and a pencil. There will be no real-time registration today. I’ll just do the bare minimum – write the scores and penalties. Registration in the application will have to wait until the match is finished.
At half-time, some people from the audience ask me why the real-time score does not show up their phones. I say something about the crappy application that does not work and I am silently thinking – “How hard can it be to build a working application?”.
After the match is finished, I get home and sit down by my computer to put the scores from my papers into the application. The system is still slow and it takes me about 15 minutes to do the registration. When I am almost done I hit one more bug which adds 20 extra goals to one of the teams which I manually have to remove before the registration is completed. WTF!!!
This is beyond bad. This is useless! I need see what is happening here. Opening up the web developer tools in my browser to see what is sent to and from the server…
There is some kind of API and after some googling I understand it is some internal Laravel Livewire API. I cannot say I understand all the details but there are definitely symptoms of bad design here. And bad design makes for systems that are hard to maintain and contain more bugs…
Norwegian(?) and English combined
Norwegian (?) words are combined with English. Why would anyone choose this naming convention these days? This is how we did things 20 years ago when we thought foreign developers or testers would never touch our code bases. And even then – we would choose one language or the other.
Non-consistent naming style
All combinations of snake_casing (separation by ‘_’) camelCasing (separation by first letter of each word in upper case) and no separation at all are all represented in the same API call.
Examples:
"add_event_omgang": 1,
"add_event_time": null,
"add_event_lag_id": null,
"add_event_spiller_id": null,
"elapsedMinutesPreviousPeriods": 0,
"liveRegStatus": "velgHendelse",
"totalSeconds": 76,
"newimage": "" In theory – naming and being consistent with naming is not important as computers do not care. But every developer knows that naming is one of the hardest and most important things when building software.
Strange API
The (Laravel Livewire?) API does not look like anything I would want to integrate with. This may be fine if it is an internal API managed by a special framework (i.e Laravel Livewire for both server and client) but I would be surprised if a vendor using this technology is also able to provide an API for the same functionality since there is no clear separation between client and server side.
Ok. I’ll admit I may be more critical than usually as I really got frustrated today. But this experience also made me thinking if it is possible to look at some simple characteristics like this of a system to say if it is easier or harder to maintain?
As API first* is the the best way to do development at scale that I know – I would probably say that a system like this means the company providing it will have a hard time to extend the product and allow external integrations.
Would love to hear your thoughts on this!
(*) API first – the API is the first interface of the system and any other interfaces must be built on top of the API.
letsbuildapis.org 
Leave a comment