Evolution and Devolution
I. |
What causes code to change in the ways that it does? Let us invent something and see. Energy is stuff that makes for change. Let us say that when code is energized, that it causes change. What kind of change? There are two kinds of changes: evolutionary and devolutionary. Evolutionary changes are for the better and devolutionary changes are for the worse. When code has evolved as far as it can, then it is mature. When code has devolved too far, then it falls into disuse. In both cases, the code no longer gets energized and nothing changes. Now, what things can put energy into code and make it be energized? Those things will be any activity associated with code changes: inspections, tests, user feedback, etc. From these, energy gets put into the code and the code may then throw off light, yield information for making changes. If you want to promote code evolution and avoid code devolution, then this notion of energizing code can be useful. You can ask yourself whether your code is mature or not. If it is not, then the question is where and how to invest your energy, so as to yield light. |
II. |
Why should writing tests help anything if the code already works? Why can I get a prototype up-and-running quickly, and it works fine, but then breaks down? These are questions I ask myself. It is not enough that something be so; I wonder why it is so and whether it could be otherwise. Lately, I have been working on a project that is a utility library. Normally, I write utility code as I need it, and when it breaks, I fix it. But then I thought: If this code is going to be used by other people, then I had better make explicit tests, even though it already works. What I found was that as I wrote the tests, the code evolved. How to explain this? Assume there is some "what" that is making this happen. OK, what is testing doing that is causing the code to evolve? "Energy" came to mind as the "what" that causes change. Picture the code glowing, it pulses light, the light cools and fades, and see now the code is changed. The energy notion does help explain why prototypes stop working. As a prototype gets used, it gets energized such that the user sees their way to further use. Eventually use goes beyond what is supported. Perhaps changes will get made to support further use, though those changes will often be hacks (i.e. devolution). So now it makes more sense why things like tests would be worthwhile. They energize the code in a staged way that promotes evolution and maturity before the code gets to the end-user. I would go so far as to say that tests may energize code before it even gets tested. How so? You anticipate it being tested. What really is getting energized here is you. |