Lifelong Learning

Lateral Thinking

Many of Edward De Bono's ideas are a natural fit with the customer-focused, consultative approach.

Check out lateral thinking (as opposed to linear, or vertical thinking).

Glossary of Important Performance Terms

I have found in discussing performance issues that terminology gets in the way. We get into "definitional arguments", or semantic debates that waste a lot of time. It helps to arrive at mutual agreement on the basic terms. They essentially boil down to three terms (and their variants) that are related by an important law (Little's Law).

If you find yourself in definitional argument while discussing performance, the following should help.The three important terms are: Arrival rate, visit time, and concurrency level. Related concepts to arrival rate are departure rate and throughput - but they're essentially the same quantity. Think time is closely related to inter-arrival time (inverse of arrival rate) - but from the client point of view. The following half a dozen terms define the different meanings of the three fundamental terms related in Little's Law.

• Arrival Rate: The rate at which users arrive in a system. This essentially self-defining term causes a great deal of confusion when discussing testing because of the ambiguity of who it is that is arriving. In a physical system, arrival rate is simply determined by observing customer arrivals at the physical site with a stop watch. You can sit outside the bank for an hour and observe people entering and count them. For a load test, confusion may arise because some people want to count actual physical threads. In a test harness that equates a user with one thread (like Grinder), the rate of thread creation could be the arrival rate, or not. It depends on what the thread is actually doing. Most test harnesses use thread pooling. RPT (Rational Performance Tester) uses about 15 threads to model up to several thousand users - so counting thread creation rate means nothing. Trying to be too smart at deciphering the meaning of arrival rate will be counter productive. The best interpretation of arrival rate, in the context of a simulated user behavior, is the rate at which sessions are created.

• Departure rate: The rate at which users depart a system. Similar confusion arises when we go from physical systems to simulated systems. At a bank you can observe customers exiting the bank and count them in a given time interval. In a simulated system, a good definition is the rate at which sessions are completed. In a stable system (at the steady state) arrival rate must be equal to departure rate, since users cannot be created or destroyed (unless people in the bank are killed by tellers or a lot of babies are delivered while mom's are in line cashing checks!). Arrival rate is not equal to departure rate during ramp up and ramp down times in a simulated test.

• Concurrency level: Number of users in the system at the same time. Again for a physical system, this is clear. Number of people in the bank. Some are queued waiting for a teller, some are siting waiting for a manager, some are at the manager's desk, some are the teller's window. Some are in the vault checking their box. Some are just lounging around reading bank literature. In a simulated system that implements the notion of a session, concurrency is the number of sessions in progress at the same time. In a system that does not implement the session concept (requests only), it is the number of requests in progress at the same time. Attempting more precise definitions of concurrency can lead to confusion. For example, defining concurrency as the number of users (threads, or processes) using the CPU at the same time, would lead average concurrency less than 1.0, in a single CPU system. The average concurrency rate for a single CPU system is the CPU utilization. In most systems a CPU utilization of 0.70 means the CPU is quite busy. Another way to read this is that: in a single CPU system, a concurrency rate of 0.70 is quite high. In a 4-CPU system, a concurrency rate of 2.80 is quite good. This is interpreting "active" to mean, "using the CPU". This is not a very useful interpretation of concurrency, although quite precise. Since most concurrency is simulated concurrency, the number of concurrent sessions in progress is a more meaningful measure. At some level, it may be useful to define concurrency to mean, "number of active threads", but that may not map well to the user experience, since it is masked by thread pooling, as discussed previously.

• Active Users vs. Total Users: concurrency discussions can get ambiguous when different people have different definitions for what "active" means. For a web site discussion, the least ambiguous definition of "active users" is the number of sessions in progress at the same time, i.e. the same as the concurrency definition. The notion of "active users" arises if we want to be more precise at stating if users are actually using system resources while they're in the system. This notion is potentially ambiguous and can lead to confusion. From the point of view of a load testing tool, like RPT or LoadRunner, active users, concurrent users, or concurrent sessions all mean the same thing: number of sessions that have a request being processed. For RPT specifically, a distinction is made between active users and total users. Total users is the total number of sessions that we request from the tool (100, 200, 500, etc.). At any point in time the number of concurrent sessions is referred to as "active users". As a function of time, active users starts out at 0, then you see it ramp up to a maximum, then it falls off back down to 0. The actual peak value may not reach the total simulated users. So you can simulate 500 users, but observe maximum concurrency of about 20. That just means that users depart, or sessions complete, faster than users are accumulating. I.e. it depends on average session duration. So a distinction is made between number of users in the tool, and number of users in the SUT (system under test). Once that is clarified, it becomes clear, in the context of RPT, to talk about "active vs. total users".

• Session duration: On average, the length of time a session is active. In a stable system, the concurrency (number of concurrent sessions) is equal to arrival rate times the average session duration. So if we have an arrival rate of 50 sessions per minute, a session duration of 10 minutes, will cause a build-up of 500 concurrent sessions.

• Think Time: Time elapsed between the receipt of a reply from a server and the generation of a new request. Several things to note about this definition: 1) it is a client-side time interval. It may, or may not affect the server greatly. It is not accurate to speak of think times when discussing the flow from the server's point of view. "Think" is something that the client does between requests. 2) The server sees gaps in the inter-arrival times, so "think time" is taken care of by the definition of arrival rate (inter-arrival time). A great deal of unnecessary confusion can be avoided by understanding this simple point: think time is a client side thing. 3) In a slow network link, the total network turnaround time (request travel to server and reply travel to client) may dominate inter-arrival time and mask even long think times. In very fast network links, think time may dominate inter-arrival time. But the main thing to keep in mind is that "think time" is meaningless on the server side.

• Throughput: The most confusing term of all (followed by Think Time). The most general interpretation is units of work completed per unit of time. This is also the reason behind the confusion - no standard definition for what the unit of work used. You will find OLTP folks talking about TPS (transactions per second), without bothering to define what a transaction is. Or typically, a transaction is well defined within a given application, and people in the community of that application know, or have a tacit agreement, or a sense, of what a transaction is. Transactions also come in all sorts of sizes, and "weights". There are many light transactions and many heavy transactions. Some financial institutions talk about "revenue throughput" - dollars per hour. You also find people talking about "hits per second", or "page views per second". Requests per second and visits per second are not unusual. Telecom people like to talk about connections per second. TPS, or transactions per second is the least meaningful, unless you define what a transaction is. I find the least confusing use of throughput is the one that is in alignment with your definition of arrival rate. If you talk about arrival rate in terms of sessions per second, and departure rate in session completions per second, and you equate that with visits per second, then that is your throughput. If, on average, you visit 40 pages per session, then page views per second is 40 times visits per second. Knowing that a page on average may contain 50 elements, then hits per second is 50 times page views per second. If you are consistent in using an arrival rate in sessions per unit time, and session duration in the same units of time, then you can easily apply Little's Law and stay clear in what you're talking about in terms of the three important metrics (arrival rate, session duration, and concurrency).

History of the Paragraph

A stunning fact I just stumbled upon: "There was no standard method for organizing writing into manageable pieces until the middle of the 1800s." I have always assumed that the paragraph was a "natural" unit of composition!

The following is excerpted from A Writer's Guide to Powerful Paragraphs: "The idea of using individual units of thought as the organizing method for writing can be attributed to Alexandar Bain (1818-1903)".

Bain introduced the modern paragraph in 1866. He believed that the paragraph, which he defined as a single unit of thought, provided writers with a way to both break down large ideas into a series of smaller ideas and to make sure that each smaller idea got the attention it deserved. Bain stressed the importance of using a topic sentence in each paragraph to properly develop and define the idea covered in the paragraph. As a signal to the reader that "a new idea begins here", Bain used an indentation at the beginning of each paragraph.

The power of simple ideas!

Now contrast that with our field - software development. What is the unit of composition in software? A class?, an object?, a function? a script? a service? a method? an aspect? Depends on who you ask! We're still debating the fundamental units of our composition!

No wonder software is still at the craft stage! We still haven't found our paragraph!

On Definitions, Semantics, and Pedantry

It often happens in meetings, particularly reviews of architecture, design, or system documentation, that we encounter what can be described as "definitional ambiguity" discussions.

Presenters often assume that everyone is on board with their use of terms - even though they may have used them in new and different ways. Even if that were true, it is useful in these situations to try to see the presentation from the eyes of "fresh meat" - someone who will be subjected to the material - and the conceptual payload - for the first time. Discussions about semantics, conceptual clarity, and the need to separate the operating concepts from implementation details are necessary to disambiguate and to "get on the same page". This "extraction of concepts" also reduces the sheer size of the necessary presentation. Most systems, no matter how complex, have few concepts - but excruciating amounts of detail.

Although there are several viewpoints for looking at this situation (definitional ambiguities/concept extraction), a rudimentary one is purely linguistic - almost literally an English 101 topic. As a matter of fact, after a recent meeting where we had one of those situations, I went straight to my English 101 text from college (one of very few texts I have kept from my college days from decades ago - Writing Prose - Techniques and Purposes), and looked up two topics pertinent to the discussion: Definition and Pedantry. If you don't want to get the book (which is an excellent resource on English expository writing), here is my short version paraphrased. But with my version, you get an infusion of my opinions - which I am not going to be shy about. This is a blog not a scientific treatise.

Before I dive too deeply, let me state my position clearly: Words matter. Speaking and writing with precision is vital - particularly for engineers, architects, scientists, and managers (we are all a mixture of all four in varying degrees - regardless of corporate hat or box). Ignore words at the peril of being misunderstood, and spiraling into conceptual ambiguity, conceptual clutter, and confusion..

The other side of the coin of precision speaking is pedantry - an excessive precision out of proportion to what the context requires. It is intellectually right to not to tell more than a subject contains of significance. You need to be as precise as the subject demands, no more. You'll often hear engineers dismiss concerns about precise definitions as "semantics". They are really worried about pedantry, not semantics. Semantics is not a bad thing. Semantics is a concern with the meaning of words, and sentences. You do want people to be concerned with your semantics, the meaning of your words. If you don't, then you're saying that you don't care about meaning, and being understood. If that is your position, you will be rewarded by being not understood at best, or misunderstood, which is worse. Pedantry, on the other hand, is excess in that direction, and is not a good thing. So we want to embrace semantics, but reject pedantry. Distinguishing between semantics and pedantry, and being precise about the difference, is not pedantry! Pedantry can also degenerate into sophistry.

So we do want to be a bit more precise about our words. Say what we mean, and mean what we say (in the technology part of the discussion - the political part is another matter!). In order to do that we need to pay attention to Freshman 101 basics about writing definitions. It is always healthy to go to the basics. No matter how smart, educated, or experienced you are - getting back to the basics should give you the humility you need to be understood.

So how do we achieve conceptual clarity, and precision of expression? Parts of the answer are simpler than others. The simpler part first: the mechanics of definitional writing, which is outlined below. The harder part is the conceptual clarity part, which involves thinking clearly and precisely. That is a bit harder to achieve, and will take many more articles to summarize. The natural context for that topic will be within a discussion of simplicity and simplification, as the crux of simplification is conceptual clarity. So lets get back to the mechanical part of removing "definitional ambiguity": defining with precision,

The meaning of definition: the effort to distinguish an entity from all other things for the purpose of being able recognize it, or in some way understand it. To define "apple" for instance, is to find some means of isolating "apple" from all other things, especially all those things that superficially resemble it, like quinces or pomegranates. We must show that "apple" refers to a combination of features possessed by no other thing. But to find this combination of distinguishing features is not always easy. A complicating factor is the kind of definition we're seeking: are we concerned with apple as a word, or with apple as a thing? If the definition is to focus on the thing, the word itself is not important, you can call it "apple", "pomme, "apfel", or even call it "foo". This kind of definition is concerned with the analysis of the thing, with its constituent parts, their nature, function, and purpose.

Anyone who has done object oriented analysis, design, or programming would, or should, be familiar with this kind of stating definitions. Sadly, many software designers who claim be object-oriented have very little patience with this kind of analysis. You will see that reflected in their design and their code. They cannot distinguish their apples from their oranges! I have attended presentations on "apples", that, towards the end of the meeting started talking about "orange juice". The First Law of Traceability says, "you can't produce orange juice out of apples". In other words, your orange juice must be traceable to your oranges.

The other kind of definition stresses the word, or word-thing relationship. This kind of definition calls our attention to how a word has been used in the past, or explains what words mean. We have to deal with concepts that are not "apples" - i.e., don't have physical existence: liberty, happiness, democracy, loan, contract, agreement, model, view, controller, etc.). Abstraction, classification, concept hierarchies, and concept networks should be bread-and-butter for OO designers. Sadly, again, many, have no clue what the concepts their program implements are, or they create classes that are not really concepts, but are just some kind of a named blob. If you can't articulate the one concept that a class embodies, then you are not doing object-oriented anything. OO programs are nothing but a set of interrelated concepts - essentially nothing more than the manipulations of metaphors. A program is useful only to the extent that its concepts correspond to concepts grounded in the reality the program is attempting to simulate. But enough about conceptualization - back to the business of crafting definitions. But it should be becoming clearer that conceptualization is the heart of the matter, and articulation of the operating concepts is merely the linguistic definitional aspect.

Methods of definition.

We can define by analysis - this is the dictionary type of definition - you define the thing by analyzing it. A car is a vehicle that consists of an engine, a drive train, ... You list the thing's constituents - features, attributes (in UML), or fields (in a programming language) - and just "characteristics" in simple expository English.

We can define by synthesis. You can think of that type of definition as a "relational" definition. Instead of listing what the attributes of the thing are, you list how it relates to other things or words. For example to define "Blue", you say "blue is the color of the sky on a cloudless day". You can point at a blue object (if one is handy) - but that method obviously has its limitations.

We can define something negatively, by what it is not. Bertrand Russell defined electricity by saying, "Electricity is not a thing; it is a way in which things behave. When we have told how things behave when they are electrified, we have told all there is to tell". Definitions, particularly negative definitions, must distinguish the thing-to-be-defined from something resembling it.

We can define by example. This is more an aid, than another method of defining. An excellent way to define something is to give an example of it. It could be that an example is sufficient. But not in all cases.

Related to defining by example is defining by synonym. This method has the advantage of being the briefest method of definition. Dictionaries define words by listing synonyms of the word-to-be-defined. This method, however, runs the risk of misleading - for no two words mean exactly the same thing.

Types of definition

1. Consensual Definition. The writer means by the word what most others in the culture mean.

2. Stipulative Definition. The writer wants to assign to a word a meaning in some way different from that which it commonly has. When the stipulative definition is not related to the consensual, public, common meaning, the writer must supply his specialized different meaning. Otherwise he risks becoming like Humpty Dumpty when he told Alice that when, "I use a word, it means just what I choose it to mean - neither more nor less". If the stipulative meaning is too idiosyncratic, the writer ceases to communicate. The writer cannot depart too far from commonly accepted meanings.

Writing good definitions depends upon a thorough knowledge of one's subject, a rudimentary acquaintance with logic, common sense, and good manners.

I will close by repeating, "words are important". Don't dismiss an argument about definitions, or about concepts, as "semantics". The alternative is conceptual clutter and muddle headedness.

This topic ties in directly with "concepts", "conceptualizing", and attempts at simplicity and simplification. Concepts are vitally important in simplicity and simplification. But that is another topic for another day. Edward DeBono has some great ideas about "concept extraction", that will have to be the subject of a future blog.