I'm Almost Always Wrong (The First Time)
When I write a chunk of code, it is wrong. I know it is wrong, even as I am writing it. But there's nothing I can do about it. I don't, and can't know how it is wrong when I am writing it. I can only know that I am writing wrong code. I am not phased in the least.
As professionals, we are expected to write code with a certain quality of maintainability so that our code can be easily changed in the future. This is expected because of how often code does need to change, often in unexpected ways. We cannot predict all the ways the code needs to change. The future is inherently unpredictable. We must write our code in a way that makes changes as straightforward as possible.
I don't worry about writing wrong code. I write it in a way that I can make right later. I design seams in places that seem most likely to change. I know them by the uncertainty that lives in them. I abstract and encapsulate that uncertainty behind methods and classes and interfaces so that later, when I need to change everything, I have a place to do it without needing to start from scratch.
Because I almost always write the wrong code the first time, I rely on coming back around later and refactoring. Sometimes, this refactoring happens before anyone else even sees the code. I've tossed out and replaced whole implementations because they didn't fit with what the code needed to do. I didn't lose anything, though, because I learned from what I did, and I could preserve the parts that were more correct.
My wrongness is not a personal failing, but a reality of being a human working in a complex and dynamic domain. I am not alone. Every developer shares these characteristics. If they did not, we would never have a need for version 2 of anything. We must not shy away from the wrongness because that is the path to (more) right answer.
The biggest danger we face is when we are expected to be perfect the first time around. If we can never go back and fix the wrongness we discover, the wrongness will accrete until the system is more wrong than right. We will constantly be fighting to change a system like that, and it will never really be able to fully adapt to the changing demands on it. A persistent technical debt hangs over the project.
It isn't always straightforward to justify fixing the wrongness if externally it seems to "work." If the code does at least what it promises to do, it isn't broken. We must resist this line of thinking. Just as bad things eventually happen if we never change the oil in our car, bad things can happen to the code if we don't take the time to fix them.
As professionals, we are expected to write code with a certain quality of maintainability so that our code can be easily changed in the future. This is expected because of how often code does need to change, often in unexpected ways. We cannot predict all the ways the code needs to change. The future is inherently unpredictable. We must write our code in a way that makes changes as straightforward as possible.
I don't worry about writing wrong code. I write it in a way that I can make right later. I design seams in places that seem most likely to change. I know them by the uncertainty that lives in them. I abstract and encapsulate that uncertainty behind methods and classes and interfaces so that later, when I need to change everything, I have a place to do it without needing to start from scratch.
Because I almost always write the wrong code the first time, I rely on coming back around later and refactoring. Sometimes, this refactoring happens before anyone else even sees the code. I've tossed out and replaced whole implementations because they didn't fit with what the code needed to do. I didn't lose anything, though, because I learned from what I did, and I could preserve the parts that were more correct.
My wrongness is not a personal failing, but a reality of being a human working in a complex and dynamic domain. I am not alone. Every developer shares these characteristics. If they did not, we would never have a need for version 2 of anything. We must not shy away from the wrongness because that is the path to (more) right answer.
The biggest danger we face is when we are expected to be perfect the first time around. If we can never go back and fix the wrongness we discover, the wrongness will accrete until the system is more wrong than right. We will constantly be fighting to change a system like that, and it will never really be able to fully adapt to the changing demands on it. A persistent technical debt hangs over the project.
It isn't always straightforward to justify fixing the wrongness if externally it seems to "work." If the code does at least what it promises to do, it isn't broken. We must resist this line of thinking. Just as bad things eventually happen if we never change the oil in our car, bad things can happen to the code if we don't take the time to fix them.
Comments
Post a Comment