Programming is like working in a minefield! An explosion can happen at any moment. Never take chances. Always be careful.
Programming by coincidence is relying on luck and accidental successes.
But, how do we program by coincidence?
Image that we are working on a programming project. We add some code, run it. It seems to be working. Then we add more code. Still it’s working. Suddenly, after several days/weeks, the program stops working. We spend hours to see what went wrong. But we couldn’t figure anything.
Why? Because, we didn't know why it worked in the first place!
Sometimes, we rely on coincidences. Here are some examples:
Accidents of Implementation
This happens because of the way the code is currently being written. Suppose we call a routing with some data. The routine responds in a particular way. But the author didn’t indent for the routine to work that way. It can happen either due to code, or due to the routine itself. When the routine is fixed, our code might break.
Accidents of Context
We sometimes rely on the context in which we are currently working. We tend to think in such a way that this is for that particular context only. Accidents of context happens while relying on a thing that isn't guaranteed
Implicit Assumptions
We assume things. Assumptions are always poorly documented. It may vary from developer to developer.
How can we avoid these problems?
Simple...
Don’t program by coincidence
- summary of Programming by Coincidence, from The Pragmatic Programmer: from Journeyman to Master
Programming by coincidence is relying on luck and accidental successes.
But, how do we program by coincidence?
Image that we are working on a programming project. We add some code, run it. It seems to be working. Then we add more code. Still it’s working. Suddenly, after several days/weeks, the program stops working. We spend hours to see what went wrong. But we couldn’t figure anything.
Why? Because, we didn't know why it worked in the first place!
Sometimes, we rely on coincidences. Here are some examples:
Accidents of Implementation
This happens because of the way the code is currently being written. Suppose we call a routing with some data. The routine responds in a particular way. But the author didn’t indent for the routine to work that way. It can happen either due to code, or due to the routine itself. When the routine is fixed, our code might break.
Accidents of Context
We sometimes rely on the context in which we are currently working. We tend to think in such a way that this is for that particular context only. Accidents of context happens while relying on a thing that isn't guaranteed
Implicit Assumptions
We assume things. Assumptions are always poorly documented. It may vary from developer to developer.
How can we avoid these problems?
Simple...
Don’t program by coincidence
- summary of Programming by Coincidence, from The Pragmatic Programmer: from Journeyman to Master
No comments:
Post a Comment