Bugs lie in uncertain code

Today after having lunch, I went around articles queue in order to read one or some. As 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, turned out disasters. There was a link to another article which told the story of Airline 5 and has it crashed because only 1 bug at 1 line of code. Going through the articles made me remind of “Clean code” of Uncle Bob, “Don’t Assume It, Prove It” of The Pragmactic Programmer.

Why? Because at the time I was reading the article, I had finished basically a feature in my current project, Migration Process. The process is for migrating old workflow cases into new Process Model Version to avoid too many versions running in parallel. My group was barely finished the process on Friday and had to show it to the Product Owner on next Monday. Honestly, the process was untested, and I was sitting there doing nothing. There were a lot of things to be tested, a lot of scenarios to tests, but I chose to test several of them under the assumption the process will work. HOPE!.

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


The Humble Dialog Box and Ivy Rich Dialogs

Today I’ve read The Humble Dialog Box of Micheal Feather and it is very interesting. The idea of the article is to develop in test-first manner the Model first, all actions, all interactions should be developed and tested against the mockable interface of the View. By doing this, it ends up all the logic are encapsulted in the Model (smart object) and the View provides methods for the Model to update. It is somehow an opposite way of MVC.

After reading the article, it make me start to questioning. The Ivy Framework, the one my company is using as a ground-up for all project, is stating that all Rich Dialogs are developed using MVC. Really? I start doubting from a long time ago if it is true. The Model of the RD is just a simple data structure while all the logic are put in the Logic part and they are tied together very strict. They are hard to test.

So what will I do? I think I should consider whole part of RD is just a View, the model of the RD should be developed first as POJO, then we will start to see the outcome.