November 15, 2014object oriented software engineering speghetti blurred lines
Today I had another terrifying, tear swallowing pull request moment. It involved clearly abstracted pieces of our system being clearly and purposefully coupled. If this doesn’t bring you to your knees let me try and illustrate why this is so bad.
You are the kind of developer that pardon my french, “gets shit done.” Because you are such a doer, you connect the first input with the desired output. You repeat this with a different input and output a few times. Then you have two inputs that have the same desired outcome so you hook that up. Then maybe you depend on that output as the input to something else you need to decide on. This keeps going on taking whatever input is needed for the job and producing the desired outcome on the system. Eventually this happens.
Quick homework, look at the system we’ve produced and figure out what action caused what, and what state the system is in, and what will happen if you change a piece.
Now imagine instead of just “making it happen” you built your system as small, well tested tools that adhere to standard interfaces that can be moved around easily and used with each other fluidly. You’d have something closer to this.
Now where do you draw the lines between your tools? How do you create the interfaces? Aren’t the lines just imaginary?
These are questions that may cause you to dismiss the need, but think about the lego. Are there other ways lego could have made bricks fit together in a consistent fashion? Would the building blocks have been just as successful? Yes the lines are imaginary, and no it really doesn’t make so much of a difference where you draw them. The important thing is that they are consistent and you stick with them, even if it means rethinking a minor detail in a feature, because if you don’t, well…