| | | Why Learning Assembly Language Is Still a Good Ideaby Randall Hyde, author of Write Great Code (No Starch) 05/06/2004 |
The world is full of case studies outlining software engineering disasters. Almost every programmer has had to work on a project involving "less than stellar" source code that was difficult to read and maintain. On rare occasion, some programmers get the opportunity to work on a well-designed system, an awe-inspiring piece of craftsmanship that usually produces the exclamation, "This is truly great code!" Clearly, professional software engineers should strive to achieve this level of greatness in all their code. But the real question is, "What makes code great?" Simply "meeting specifications" is not how one writes great code. True, in today's software environment, some might actually believe that simply meeting the specifications sets an application apart, as many development projects fail to meet their basic design goals. However, in other areas greatness is rarely defined by doing the expected and succeeding; greatness is defined by going above and beyond what is expected. Software engineers should expect no less from great software--it should go above and beyond the standard conventions for software development. Efficiency Is the KeyBecause greatness is a multifaceted attribute, a short article such as this one cannot begin to describe all the possible components of a great piece of software. Instead, this article will describe one component of writing great code that has been neglected in recent years as computer systems have increased in capacity and power: efficiency.Anyone who has been around the computer industry for a decade or more is well aware of this phenomenon: machines are getting exponentially more powerful per unit cost, yet users do not perceive this improvement in the applications that they purchase. For example, while word processors are clearly faster today than they were 21 years ago, they aren't 16,384 times faster as Moore's Law  would suggest. Part of the problem, of course, is that some of the additional processing power has been employed to support new features (such as a bitmapped display), but a large part of the reason software users aren't seeing an increase in speed is because many of today's programmers don't take the time to write efficient software, or they simply don't know how to write fast software.Outrageous software development schedules that don't give programmers enough time to develop efficient code is certainly a problem, but many of today's programmers have grown up with fast CPUs, whose speed has made up for poor coding habits and, as such, many of these programmers have never had to learn how to write fast code. Related ReadingWrite Great Code Vol I Understanding the Machine
By Randall Hyde|
Unfortunately, when software performance is less than optimal, these programmers generally don't know how to correct the problems with their software. They'll often spout things like "The 90-10 rule," or "I'll just use a profiler to correct the performance problems," but the truth is they don't really know how to improve the performance of their underperforming applications. It's all well and good to say, "I'll just find a better algorithm!" However, finding and deploying that algorithm, if one actually exists, is another matter.Most of the time you can achieve very good performance boosts by simply improving the implementation of an existing algorithm. A computer scientist may argue that a constant improvement in performance isn't as good as, say, going from an algorithm with O(n^2) performance to one with O(n lg n) performance, but the truth is that most of the time a constant factor of two or three times improvement, applied throughout a piece of software, can make the difference between a practical application and one that is simply too slow to comfortably use. And it is exactly this type of optimization with which most modern programmers...