This past week I got into a small discussion about the importance of loosely coupled code. Specifically, I was looking at event handler code that did nothing more than change the size of another element on the screen. But the event handler code was in the controller which in the particular implementation we are using was the event handler portion of our Model in a MVVM architecture. The question becomes does this code belong in the view, or does it belong in the controller?
The question of where code belongs leads eventually to arguments for loosely coupled code. If I put code in my controller that is manipulating the view, then I either need to mock out my view in order to test my controller or I have to have an instance of my view available to test my controller. Having coded enough systems to know that both of those choices are problematic, I opt for placing the view specific code in the view. Another place where you might place this code would be in a View Specific event handler class. But that would only be for the purposes of clean separation. Something we might consider doing if the View were plain HTML. But in our particular case, the view is generated from code, so placing the handlers in that same code seems to be the most appropriate location for it.
But all of this leads to a larger question. Why should your code be loosely coupled at all?
There have been a number of things that have occurred over the last week that have prompted this particular post. And for anyone I work with, this is not an indictment of our work place so much as it is an indictment of our industry. PLEASE don’t take this personally.
Some of those reasons will show up in this article. But the question we need to examine today is why is it so hard to write bug free code. And I’m not even talking about perfection. Why is it that we miss the simple stuff? The stuff that once it is found, we think, “how could we have missed that?!”. I’m perfectly aware that all code has bugs some just haven’t been found yet. I’m also aware that no matter how hard I try, the stupid bugs always make their way past my desk.
Have you ever noticed how, when QA reports a “defect” developers tend to bristle? I first noticed this in myself a few years ago. Now that I’m functioning as a Scrum coach, I’m noticing it in others. Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial? I think so.
I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.
But first, why does this problem exist in the first place?
I’ve been working on a new project over the last weeks that involves getting TypeScript and Electron working together. Unfortunately, the amount of information available on how to do this correctly is pathetically none existent.
And then there is the whole setup of TypeScript in Node thing. This was mostly my not knowing my editor well. But while we are documenting how to get a TypeScript/Electron app setup, let’s cover that as well.
We’ve all been there. Either at the micro level or at the macro level. Business wants to know, “How much is this going to cost me?” And as software developers, we all know the answer is, “more than you were expecting.” We also know that whatever number we give will probably be wrong for a number of reasons. Chief among them is that no one really knows what they want until they see it.
And yet, there has to be some way of providing business what they need and still allowing for unknowns.
So what follows are a few tips on estimating that help you estimate software projects like a pro.