How Fast Does Water Freeze?

Recently there have been some comments on Facebook and elsewhere explaining why hot water freezes more rapidly than cold water. Since hot water does not freeze more rapidly than cold water, these comments allow us to think about the nature of heat, and the use of a scientific theory. 

Heat and temperature are related but different phenomena. Heat refers to the quantity of energy of a particular kind in a lump of matter of a particular size. Temperature talks about the distribution of heat in a lump of matter regardless of size. That is, a large cup of coffee may have the same temperature as a small cup of coffee, but the large cup has more heat than the small one.  

In my high school physics class, our teacher explained that the amount of heat generated by an engine was a constant – regardless of where the heat went. One of the students asked, “Then how come drag racers put wide tires on the back? Wouldn’t the heat be the same whether the tires were large or small?” The class was stumped for a moment. The answer is that since the amount of heat is the same, distributing it through a broad tire would cause less of a rise in temperature than distributing it through a small tire. Since the total amount of heat was the same, putting it into a larger volume of matter would cause less of a temperature change – the bigger tire wouldn’t melt.

The same argument applies to the freezing phenomenon. The classic conundrum states that if you put a cup of hot water next to a cup of cold water in a freezer, they both freeze at the same time. This means that the hot water froze faster than the cold water.

This is an example of a flawed theory. A scientific theory offers an explanation of an observed phenomenon that can be disproved. In the case of the freezing water, the idea that the hot water freezes more quickly can be disproved simply by placing the hot water in the freezer, and seeing how long it takes to freeze; then putting the cold water in the freezer, and seeing how long it takes to freeze. While the hot water is cooling, at some point it will have the same temperature as the cold water. From that point, the question is how rapidly will two identical amounts of water, at the same temperature, take to freeze. The water’s history doesn’t matter. When the hot water and the cold water are in the same freezer, the hot water warms up the cold water while the freezer removes heat from all its contents.

A theory that cannot be disproved is not a scientific theory. The theory of evolution, like the theory of gravity, explains an observed set of phenomena and allows for predictions that can be either validated or disproved. Dismissing “a mere theory” because it is only a theory is fine. Dismissing a scientific theory as “a mere theory” is thoughtless.

Parables for Architects: Untangling Requirements

The business user comes to you and says, “I need you to transport something from Poland to New York.”

You ask, what is it?  

“It’s worth $30,000,000.”  

Can you tell me anything more about it?

“It is a form of carbon.”

Thanks for that. Are there any other constraints?

“I need it in New York within six months.”

So now you have enough information to begin … what? Nothing, in fact. If the client wants you to transport $30M of coal, you’ll need five cargo ships. If the client wants you to transport $30M of diamonds, you’ll need a bonded courier with a briefcase.

The business user describes what they feel are the most relevant aspects of the problem they want IT to help solve. The business user does not know what decisions IT actually has to make on the way to delivering the solution.

You, the IT architect, perform a complex role. You need to understand the comparative value of the pieces of your organization’s IT infrastructure. You need to understand the IT elements of the business problem the user has to solve. You need to translate the business requirement into the most fit-for-purpose technological solution. You need to flesh out the technical requirement, understand the user’s priorities, and you need to nail down the missing requirements. User input is crucial, but it is generally not sufficient. Users should not understand technology trade-offs. IT architects must understand technology trade-offs.

An IT architect that only knows one technological capability will add no value. Like a clock that’s stopped, this IT-architect-in-utero has only one answer to every question. An effective IT architect must evaluate technology alternatives based on experience and fact. An IT architect must go beyond lore, bias, or taste.

If the business customer has decided to deploy only one IT technology, they will not need an IT architect – there is no problem to solve. The advantage of this simplification is that it saves time and cost. The only disadvantage to this strategy is that all IT infrastructures are not the same. Misaligning the technology and the business gives the users a brittle and ineffective infrastructure. You, the IT architect, know that you don’t cut meat with scissors.

Even if the user does not ask, you, the IT architect, must develop a solution that meets the functional and non-functional requirements the user relies on. Users do not understand the difference between 99.9% availability and 99.9999% availability. They may ask for six-nines, but they may not realize that the cost of the solution may be an order of magnitude greater than the cost of the three-nines alternative. They may not understand the implications of rapid problem determination, or ease of migration, or resiliency, or fast failover. You, the IT architect, must use your mental checklist of systems and network management requirements to complete the user’s requirements before your job is done.

Some corporations deploy a configuration management system or CMDB to help track the infrastructure pieces they have; some even put together a service catalog listing groups of those services. A few have service catalogs that actually speak to users in user terms, but none have a robust, automated alternative to you, a knowledgeable and experienced IT architect. You build that mental checklist during your professional career. When you take on a new project, you will re-evaluate that checklist to identify obsolete capabilities and remove them, and learn new capabilities to add them. That is why you chose to become an IT architect: the job is self-renewing, the job demands your continuous awareness, clear thinking, reasoned analysis, and communications skills. No other industry in human history has the richness and continuously evolving knowledge base that IT offers. You are surfing the wave of the future. You, the IT architect, know that you don’t use five cargo ships to move a handful of diamonds.

Time to Prune those Processes

Anyone who has worked in IT for five years or more knows the truth of the statement: “If you automate a mess, you get an automated mess.” What can we do, and what should we do, about these productivity-sapping kludges? This discussion offers a few short-term actions and some useful longer-term approaches to get some of that productivity back.

One common automation shortcut is to transplant a paper-based process into an exact copy on web screens. The screens look just like the original paper forms, and the process reproduces the exact steps that people used.

The rationale for this relies on the “ease-of-use” and “proven design” fallacies. The business automated the process because it was inefficient, or overly burdensome, or got in the way of needed changes in other business activities. “Ease of use” in this case really means “no learning curve,” which is supposed to reassure the business area that none of their people will have to learn anything new or different. It presumes that the original system was easy to use. Often it was not.

“Proven design” in this case means, “we don’t want to do any business process analysis.” The savings in design and analysis will shorten the front-end of the implementation process, but by not making the design explicit, those well-worn processes remain obscure. This is a problem because unless the implementation team accurately describes the process, the translation from hard copy to soft-copy will create defects. How could that be? In manual processes, users learn to avoid many options they should not take. In computerized processes, the software must handle every possible decision a user could make. The implementation team does not understand that tribal lore the users follow. The implementers must guess what to do in every undocumented case.

That is, the implementation team ends up doing business process analysis under the worst possible conditions:

•          They do not have the skills to do the job
•          They do not have the time to do the job
•          They do not have the tools or procedures to do the job
•          They do not have formal access to user experts to help with the job, and
•          They are not evaluated on how well they do the job

Another way to state this is to observe that every system has an architecture. The only question is, does the implementation team know what it is before they begin? The default architecture is inconsistent and incomplete.

Rushing to get from the old (paper-based) process to the new (automated) process on time, the IT organization abandons its core competence, which is to make complex processes clear. Fixing a kludge like this means first identifying and removing gross process inefficiencies, then second streamlining inputs and outputs.

One easy way to find and fix inefficiencies is to measure the elapsed time that process steps take, and use that measurement to extract any activities that are not adding value to the underlying business activity. For instance, some organizations automate approval processes, replacing a physical form with an e-mail link to an approval web page. Look at how long each approver spends on each request over a few weeks. If you find that a person always approves a certain type of request, and does so within 30 seconds, you can conclude that they are not adding any value to the process. They probably got approval rights because they wanted to be aware of requests. The solution is to replace the “action” link with an “informational” link – and not hold up the process by waiting for that rubber stamp.

Streamlining inputs and outputs can save lots of processing time and complexity. Some paper processes produced intermediate reports to measure a team’s workload. Automating these reports and – what is worse – evaluating a team based on that measurement, locks in the original inefficiencies. Every output should have a natural “consumer” who needs that information to do some other job. The other job may be in-line, meaning it waits for the output before it can start, or it may be cyclical, meaning that at some future time the other job starts using a collection of those outputs. Users regard the in-line type (sometimes called “straight-through processing”) as the real application. They may overlook the cyclical type because they do not usually do that part of the work, such as aggregating financial results, auditing, or quality assurance.

By giving the supervisor a measure of the activity, rather than a copy of the results, the process lets the supervisor focus on the business value of the activity rather than the sheer mass of the activity. This moves towards that oft-sought alignment between the IT organization and the business. If the business gets its job done with little extra activity, few procedural glitches, and optimal efficiency, the IT systems that support it are by definition aligned.

It is now spring 2013, a good time to consider pruning those processes.