Tuesday, August 05, 2014
It doesn't have to be one piece to be monolithic
I'm still chugging away on “Project: Sippy-Cup” where, for the past few weeks, I've been hurrying up and waiting as we run through IOT with a few other companies.
The problem I've had with running tests here at the Ft. Lauderdale Office of The Corporation has been just the sheer number of moving parts required to test anything. “Project: Sippy-Cup” talks to component T, which talks to two other components, E and SM. SM talks to a few more components, and so on, and so on. It's difficult to stub these out because then time is wasted debugging the “fake” components and before you know it, you've written pretty much a duplicate component that is just as buggy as the component you are trying to fake, but with different bugs. So I try to use actual components whenever possible.
Only today I found out that the instance of component SM, for whatever reason, is refusing to talk to component T, which I'm using to test “Project: Sippy-Cup.” I've always attempted to use existing SM instances so I don't have to fire one up (when I first started, we didn't have our own SM component; it seems that in the few years I've been here, one has been written—fancy that!) and I've been afraid that something like this would crop up. So now I have to configure the SM component so that the T component is happy so that I can test “Project: Sippy-Cup.”
My complaints about this reached fellow cow-orker B, who wrote the following in email:
There's a word for software that requires every last piece of every last server to be running in order to test any part of it:
Monolithic.
B has a point. It doesn't have to be one piece to be monolithic.
