Build and Fix
Team. As noted in the last weblog posting, engineers build products and, when they do not work as expected, fix them. A common and often criticized metric for coding productivity is the number of lines of instructions (LOC) produced by an engineer in a given period. The primary reason that this is an unreliable measure for production rate is the ease at which it can be inflated. Consider a frugal manager who decides that he will pay his engineers at a rate of a penny per line of code on top of a very modest salary. In fact, he invests a portion of his departmental budget in a line counting program, because he is so certain that this is the best way of motivating his staff's performance. At the end of the first months when drafting the paychecks, he discovered that he owes his college intern over ten billion dollars for a simple controlled-break report which was the students only work assignment. He asks if he can see the source for the program and finds the following method at the top of the intern's program:
void livingLikeAZuckerberg( int x ) {
if ( false ) x++;
...repeated for over a 100 billion pages
if (false ) x++;
return;
}
While this an extreme example, it shows why lines of code is a poor measure of performance. Measuring error rate works well. However, the bottom line of software engineering is that it is a business. The bottom line of business is the total cost versus revenue, profit. One product might have thirty errors addressed in the first year of production at a total cost of two hundred and fifty thousand dollars. Another might have fifty errors remedied in the first six months of production requiring seventy-five thousand dollars. So error rate does not fully quantify cost and the goal of any business is reducing cost and increasing income.
Note that being free of errors is synonymous with the notion of producing a working software system which requires very little, if any, fixing. This is a state of high productivity. Since managerial concerns usually center around cost with person-hours being a major cost in engineering, consider measuring the cost of building versus fixing effort as a metric. For enhancements which fall in the grey area between building and fixing, they can be added into both the numerator and denominator of the measure.
It should also be added that using the forethought activities found in more formal and rigorous software life-cycle processes plus documenting are essential techniques for reducing fixing time.
Synonyms for Computing
Computing, although an ancient practice, is a rather new formal discipline in terms of using automated processors. We are still discovering new characteristics of this discipline and inventing terms for describing them. Consider familiar concepts such as the notion of "one"-ness. How many different ways are there for describing it. Let us count a few: first (1), once (2), single (3), unitary (4), and etc. Consider "two" with couple, double, pair, second, twain, twice, and etc. The concepts of "one" and "two" are very commonplace.
But, what about "concern". Of course, computing students would say that concerns are aspects, functions, procedures, modules, methods, subroutines, and the "like". Yet, these are only behavioral concerns. The notion of a concern is much more abstract. It literally means anything which one must consider when building a system. And, the well-partitioning of these "considerations" is quite important when building software.
Certainly, thesaurus.com or an old Roget's thesaurus will provide one with numerous synonyms for the word "concern". However, each one which we utilize when discussing software limits the number available for other topic contexts and can muddle understand. For instance, a modern work on separation of concerns would likely not use the word "aspect" for signifying a "characteristic" of a software system other than a concern which occurs before, during, or after a method.
What's the solution for our limited vocabulary? Seeing that modern languages stem from older forms of other languages, maybe we should simply consider adopting equivalent terms from other modern languages when writing and discussing computing. Based on BabelFish and Google Translate, the following terms are the non-English equivalents of concern in a few of the world languages that are short an memorable:
affaire, asunto, sak, sprawa, umur, & vec
For readability, we only used translations that are written using English alphabetic characters. Bear with us for a moment while we experiment with using the above terms as synonyms for "concern" in the following paragraph which discusses CABOOSE and its page concerns. The terms have been pluralized using the English custom of adding an "s".
Page Asuntos
If it has not already been emphasized, CABOOSE provides a better and simpler mechanism for partitioning of concerns than other open-source model-view-controller systems. Affaire separation is a fundamental in CABOOSE. As has also been said, a concern is not necessarily "behavioral" such as a function, method, or procedure. After designing a markup-based storyboard presentation of a working system. Each dynamic portion of a given web document stencil, page vec, can be directly mapped with a sak handler. The placeholder for the textual representation of this concern with be a stencil replacement variable. If a given page sprawa does not render properly, the portion of code which requires inspection is localized. One is not left tracing the definition and uses of variables throughout a large codebase in search of the lines of code which generated this segment of the page. The directory.xml file provides a listing of all of the page umur and their handlers in the system.
Given that the translation of these terms is "concern", hopefully this increased the read-ability and quality of this paragraph versus the constant repetition of the word "concern". If your mother-tongue was not included in this list of synonyms, please do not be offended.
This should be enough for now. Enjoy this day. La.-La.
No comments:
Post a Comment