Another group (that I'll call Hackers), on the other hand, made their goal to write the smallest, tightest, most efficient code possible. This group may prototype 3 different methods to see how each performs, promoting the champion and discarding those that didn't survive the brutal testing. Some members of this group would even make a game of rewriting another Hacker's code to see how much better they could make it as they squeezed every byte to make the code fit into (what would now be considered a tiny amount of) RAM and encouraged it to perform faster.
So, we have two opposite perspectives: create more code and create better code. Even though it may not appear so prima facie, these two views are as diametrically opposed as essentialism and existentialism. If my experience is any basis for judgement, and I believe it is, then more code is always going to be more difficult to maintain in the long term.
Smaller code means fewer things can break. Tighter code (better isolation/encapsulation) means breaks are easier to find and fix. Faster code means...well, we all know that faster code is better. In contrast to the smaller, tighter, faster mantra is the view that LOC's are the only reliable measure of productivity. Such a view, that LOC's are a measure of productivity, is another symptom of GSD Syndrome and, thankfully, (again based on my experience) one that is going the way of the dinosaur.
The view still persists, however. The difference between then and now is that now it's not the financial geniuses that push it as a measure of productivity, but rather KLOCers themselves who throw code at a problem (which generally breaks Robert's Rule #15 and Robert's Rule #20). Whereas some developers have the goal to put less code in production than was in the previous version, others seek only to solve their problem in the fastest way possible, which is a road that leads to ruin. Instead, seek first to understand the problem you are trying to solve. Ask yourself
- what factors have created an environment that gives rise to the problem
- what code is already in place to mitigate this type of situation
- can we make the code smaller, tighter, or faster to fix this problem
No comments:
Post a Comment