- In the Beginning, There Were Bits
- Structured Programming
- The Next Level Up: Functions and Procedures
- Classes: Beyond Structured Programming
- Conclusion: Abstraction Costs and Benefits
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusion: Abstraction Costs and Benefits
In many software maintenance projects, the cost of the additional performance of low levels of abstraction is far higher than the cost of the computer cycles that would be required to run the program.
As a maintenance programmer, your time is extremely expensive. The time of your users is even more expensive (since there are usually more of them than there are of you), so correctness of the program is key. If users lose work or time waiting for your software to be corrected, that easily represents lots of money.
Higher levels of abstraction lead to improved maintenance, simply because there's less code. The less code, the less you have to read to understand it. Certainly there are limits to this, and I'd rather have 50 lines of clear code than 10 lines of total obscurity. In general, however, by using higher levels of abstraction, you get improved maintainability.
Of course, there's a downside to these higher levels of abstraction: performance. The more flexible a program is, the harder it is to optimize. As a maintainer, you'll have to find the balance that works best. The old dictum of C.A.R. Hoare that "Premature optimization is the root of all evil" is particularly applicable to abstraction. Choose your levels appropriately, and optimize those parts that can't be made to function at the level of abstraction you choose. The payoff is in programming time, both in development and maintenance, and that makes users happy. Which is the goal, after all, right?