Today after having lunch, I went around articles queue in order to read one or two.While reading the Architecture-Breaking Bugs, a lot of articles I had read before came back to my mind.

The content of article was about flaws in the architecture which the engineers often overlooked then later on they turned out disasters. There was a link to another article which told the story of Airline 5 and how it crashed because only 1 bug at 1 line of code. Going through the articles remind me the principle “Don’t Assume It, Prove It” in book The Pragmactic Programmer.

Why? Because at the time I was reading those articles, I had finished basically a feature in my current project called “Migration Process”. The process was for migrating old workflow cases into new “Process Model Version” to avoid too many versions running in parallel (These are all concepts from a framework named Axon.ivy BPMN). My team had barely finished the implementation on Friday and had to show it to the Product Owner on next Monday. Honestly, the process was not thoroughly tested, and I was sitting there doing nothing about it. There were a lot of things to be tested, a lot of scenarios to tests, but I chose to test only several of them under the assumption the process would just work. Wishing thinking!

God damn it! I had to go back to do something about it.