Make it work first, then make it better
Sometimes, worse is better. As strange as it may look, having something that is not perfect may be better than spending the time to make it perfect. This happens in many areas, and its the main reason perfectionists never get any work done. If the expectation is for perfection, then it is really hard to complete anything, because most of what we do is imperfect by necessity.
In software, however, there is an extra dimension to this problem. Because, the closer to perfection we get in a software application (in terms of features) the more code needs to be written and maintained. More code also means more bugs, which have the power to move us even further away from perfection.
Given the complexity of writing perfect software, it is just better to admit that we can’t write perfect programs. Instead, a more attainable goal is to write the minimum necessary to satisfy our requirements, while maintaining a good control of the overall design.
Writing as few code as possible has several advantages that contribute to the quality of the resulting programs:
It is easier to test: every extra line of code is a new place where errors may be hiding. Why increasing that chance? Just write as few lines as you can and avoid potential problems.
Avoid unnecessary repetitions: a guiding principle of programming is the DRY method: Don’t Repeat Yourself. While trying to write as few code as possible you will see more opportunities to avoid unnecessary repetitions.
Performance: usually, less code leads to better performance. This is particularly true for modern software, where one of the main limitations is processor cache size (as opposed to main memory size). Small programs that solve the problem without requiring huge class libraries may have a big advantage in the performance arena.
It is not always easy to write small programs though. Remember the old saying: “I wrote a large book because I didn’t have the time to make it small”… The same apply to programs. It is sometimes easier to copy and paste previous code, or code that was mindlessly taken from some other project or from the web. It is harder to think about the overall problem and adapt the code to your situation.
What about making it fast? Well, it turns out that making programs fast is more a matter of design than of good programming skills. It is futile to change a program to yield better performance if the structure of the program is not created with this in mind. And once you get the big picture of the software design, getting small improvements in speed is not that interesting. There are exceptions to this rule; for example, video games can use small speed gains to give much improved user experience.
So, you see that writing small programs has a lot of virtues. And, despite this, it is a difficult task, because it requires a lot of thinking in advance. Developers are most of the time pressed to think less and finish more lines of code. But it pays the time to look for good solutions before you enter code into your preferred IDE.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
