Afghanistan's Similarities to Vietnam

In the President's recent address to cadets at West Point and the world, he dismissed the comparisons of Afghanistan to Vietnam with simplistic rationale (see here for more reasonable comparison). Consider the following quote from page 209 of David Halberstam's The Best and the Brightest.

"What the president was learning, and learning to his displeasure (once again, the Bay of Pigs had been lesson one), was something that his successor Lyndon Johnson would also find out the hard way: that the capacity to control a policy involving the military is greatest before the policy is initiated, but once started, no matter how small the initial step, a policy has a life and a thrust of its own, it is an organic thing. More, its thrust and its drive may not be in any way akin to the desires of the President who initiated it. There is always the drive for more, more force, more tactics, wider latitudes for force."

In this quote the President was John Kennedy who started the Vietnam conflict and allowed it to get out of control. This quote describes exactly how the Afghanistan situation is like Vietnam. How can you expect those who believed you to be a rational man, to continue to follow along with this utter nonsense? Either you have been completely buffalo'd by the Military Industrial Complex or, as I have described previously, you have taken the twisted route to accomplish your social agenda. Either way, it confirms my belief our great ideals are impaired by our dysfunctional implementation of government. It is a sorry situation indeed.

Obama's War

I'm disappointed with Obama's decision. The goal is political expediency - just like Kennedy's mistake with Vietnam. I feel sorry for him and for the soldiers that are going to die or be maimed needlessly.

There's only one journalist who has been telling it like it really is and that's Michael Ware of CNN. He's not the polished kiss ass journalist that the rest of them are. He's very primitive looking - but he doesn't mince his words and in his opinion this is all about the conflict between Pakistan and India. And if you can't stop them from meddling in the Afghan affairs, there's never going to be any stability - and how long has the conflict between Pakistan and India been going on? Whoa! That's a very interesting history that goes back to the control of the region by Great Britain! When the British were considering withdrawal of their colonial control, they imposed a solution by dividing the country into parts for Muslims (Pakistan) and parts for the rest of the religions which were mostly Hindu (India). This is when the conflict began over Kashmir which didn't want to be in either country. This goes back to the end of WW II ... There are so many problems that currently exist that are the results of wars – WAR! what is it good for? ... absolutely nothing!

It is clear that Al Queda is inactive in Afghanistan. The Taliban and Al Queda are two completely separate entities. Our presence in Afghanistan does nothing to stabilize the region. The Taliban is going to come back again and again. The Afghans do not trust us or their own government. Have you seen the Frontline documentary called Obama's War? It's excellent. As an Afghan peasant points out in the documentary, how can we (Afghan peasants) beat the Taliban when you (US soldiers) can't beat them with all your weapons and I haven't even a sword? Afghan peasants are ignorant but they aren't stupid. They are not going to jeopardize their lives for us or their corrupt government. That's why I recommend seeing the Frontline documentary, the truth is right there coming from an Afghan peasant telling it like it is.

It's sad to see the mistakes of a previous administration (Kennedy) repeated in the Obama era. The Bush administration isn't even worthy of consideration - they were on par with Neanderthal-level mentality .. ala, let's go kick us some Al Queda butt! But Obama is smart and so are his people. Nevertheless, they have other goals and they aren't going to let this terrorist-Afghan thing get in the way of achieving these other goals - thus the political expediency. This lame move of putting in thirty thousand troops and at the same time announcing a withdrawal time table is only something to keep those who might vote against the health care bill placated. Shamefully it's the only way to accomplish goals in our impaired system; another example of our foreign policy being held hostage to the agenda of one of our political leaders. The world doesn't need another short term solution that leads to even bigger / worse long term problems.
We need to get our act together on the home front. We need to rebuild the infrastructure of our own country, not Afghanistan!

Afghanistan and Political Expediency

Dear Mr. President:

In a previous post I asked why it wasn't obvious that we need to leave Afghanistan ASAP. I know that the lens for your reality is completely different from mine. The problem here is that I suspect you are letting concerns for political expediency affect your decision. Kennedy did the same thing in Vietnam as clearly delineated by David Halberstam in "The Best and the Brightest." Please avoid being caught in the same trap. Cow towing to the military industrial complex or placating the hawks isn't worth the sacrifice you make to achieve your goals. It makes everything worse. You have the power to speak the truth to the Americans - let us have it. There is nothing to achieve in Afghanistan that is worth one single drop of American blood. Please do not sacrifice our country's integrity to achieve your goals.

Respectfully,

John Towell III

Leave Afghanistan ASAP

Mr. President:

Having never heard a Middle East scholar say anything encouraging about our chances of establishing order (much less democracy) in Afghanistan, I must wonder why our government doesn't listen to the scholars? An even better question, why don't we ever listen to the Afghan people? Doesn't President Obama watch those documentaries where Afghan peasants are interviewed? Mr. President listen to them - stop wasting lives and get out ASAP.

Respectfully,

Doktat

FUBARism: The Fed Should Stop Subsidizing Risk

In today's Wall Street Journal, Gasparino shows that the history of the Fed subsidizing risk-taking by Wall Street Financiers goes all the way back to the 80s. The "moral hazard" was created by the government. This behavior is not partisan - both parties are responsible. While most folks are angry at the greed and stupidity of Wall Street Financiers, the real responsibility lies in the fact that these same financiers knew the government would bail them out if / when they got into trouble with mortgage-backed securities. It's not socialism, it's not communism - I need a new 'ism'. How about FUBARism?

How is FUBARism defined? It's simple - FUBARism exists when you privatize the profit and socialize the risk. As my son says, "Heads we win, tails the government bails us out." What other name for this type of economic disaster is there? Please offer an alternative to FUBARism.

Struts 1.3.10 on Tomcat 6 Tutorial

I started working through Hightower's tutorial available as a free pdf from theserverside.com and am having a few problems. I will record fixes as I encounter problems. Note that Struts version 1.3.10 has changes whereas the Hightower tutorial, Jakarta-Struts Live, is for version 1.1. I am also working with Tomcat 6 (apache-tomcat-6.0.18) , ant (apache-ant-1.7.1) and Java 6 (jdk1.6.0_04) . The fixes I am describing are what I am getting to work on the above-described configuration. I am not saying that the tutorial is wrong for Struts version 1.1.

--------------
CHAPTER 1
--------------

On page 4 where he is discussing setting up on a Tomcat 5 server, note that Tomcat 6 has changed the previous directory structure $TOMCAT_HOME/common/lib/ to just $TOMCAT_HOME/lib/ ... there is no longer a common directory present.

On page 17 where we are writing our first action form, note that the class ActionError is no longer available in Struts 1.3.10 and one must use ActionMessage instead. So, in the code for the UserRegistrationForm class, comment out 'import org.apache.struts.action.ActionError;' and add 'import org.apache.struts.action.ActionMessage;' ... Also later on, swap out ActionError in the validate method with ActionMessage.
On page 20 where we are writing our first input view (jsp page), we ignore any of the changes to the web.xml file with regard to the additions. Also, still in #2 on that page, we do the directives in the jsp differently. Instead of
'<%@ taglib uri="/tags/struts-html" prefix="html"%>'
use the following namespaces for the uri, like this:
'<%@ taglib uri="http://struts.apache.org/tags-html" prefix="html"%>'
'<%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean"%>'
I spent a lot of time diddling around with this and from what I read in the google searches, a lot of other people have wasted time too. This is because the tld's are packaged in the struts-taglib-1.3.10.jar file which is in the lib directory in WEB-INF in the struts-blank app. The servlet api has now made it easy to find the tlds in the jar file provided they were packaged properly (see the Struts site for instructions for a proper configuration or look at the jar file in the distribution). Note that including taglib information in web.xml will result in the application not being able to find the tlds.

_________________________________________________________________
ON PAGE 27 UPDATE THE ACTION TO HANDLE FORM AND CANCEL BUTTONS
Since version 1.2.8 the 'cancellable="true"' statement must be placed in the action tag path="/userRegistration" in struts-config.xml. Otherwise, hitting the cancel button results in exception.

________________________________________________________________
MOVING ON TO USING DATABASE
As an FYI Hightower notes that, although he is using an HSQL database, "You
should be able to use any database that has a suitable JDBC driver." ... which should be true but in this example, the name of the table, USER, isn't going to work on an Oracle database because USER is a reserved word. Hence I changed the name of the table to STRUTSUSER since I was using an Oracle database.

On page 30 of the tutorial the code uses the method getDataSource which is not present on the Action class in version 1.3.10. I found a discussion at JavaRanch and will use a DAO which in turn will use JDBC to get a connection to the database. This is good for separation of concerns and is immediately valuable for unit testing the DAO independent of the rest of the application (always a good thing!). Nevetheless, this makes the datasource-relevant information, which was added to struts-config.xml, irrelevant and for me the entire Struts 1.X version somewhat dysfunctional and even more reason to use Struts 2.x version or, its evolved form (Spring... :). Having just coded the DAO and using raw JDBC for database manipulation, I am reminded of how easy Spring makes database manipulations because it saves you from TCFTC (Try-Catch-Finally-Try-Catch).

Oh, and yes, at this point forget about letting Struts handle any database connection pooling ...
________________________________________________________________
PAGE 32: EXCEPTION HANDLING
Now that we're not even using Struts to manage database connections, it's not going to see any sql exceptions either(we're catching sql exceptions in our DAO) so we need to find another way to worry about exception handling by Struts.

________________________________________________________________
PAGE 35: DISPLAY AN OBJECT WITH STRUTS TAGS

This works as described in the tutorial but remember to use the uri discussed above for the bean tag.

________________________________________________________________
PAGE 37: USING LOGIC TAGS TO ITERATE OVER USERS

As discussed above, the logic tags directive would look like this:
<%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic"%>

--------------------------------------
CHAPTER 2: TESTING STRUTS
--------------------------------------
Having suffered through the early versions of EJB I am reminded of one of the reasons why developers created their own lightweight frameworks, like Struts and Spring - to enable unit testing the POJOs (the domain-object model) without the container obstructing the tests. For those not familiar with the history of that era, I recommend Bruce Tate's "Don't Make Me Eat The Elephant Again."
________________________________________________________________
PAGE 59: Using StrutsTestCase (Mock Mode) Step-by-Step

I will be using strutstest-2.1.4.jar

KISS & Object-Oriented Programming

This piece examines the response to decentralizing reponsibility from the KISS (Keep It Simple Stupid) perspective. Decentralizing responsibility generally creates more objects and upon first examination most programmers fail to understand the advantage. This is because their education generally involved the solution of problems that rewarded their ability to create small cute programs and not the solution of problems rewarding their ability to create coherent and loosely-coupled classes containing methods responsible for doing only one thing. Upon refactoring their solutions to systems containing more objects, the typical response is to question how this leads to a simpler system. Their education did not prepare them for creating complex software systems composed of harmoniously working objects. Their education layed the groundwork for creating hopelessly complex, difficult to maintain and impossible to change nightmares commonly referred to as "Big Balls of Mud" [1]. Being an object-oriented programmer is more than incorporating byzantine thinking into a program running with an object-oriented language. A true object-oriented programmer knows how to think on a higher level. A level that is amenable to building much larger systems that are easy to maintain and change.

REFERENCES

1. The Big Ball of Mud paper is in my opinion a must read for anyone interested in enterprise-level software creation. This paper reveals the sticky problems of integrating the ideals of software creation with the reality of the contemporary corporate IT workplace.

Moneyware: Comparing baseball and computer science cultures

"I think, really, that this is one reason that so many intelligent people drift away from baseball (when they come of age), that if you care about it at all you have to realize, as soon as you acquire a taste for independent thought, that a great portion of the sport's traditional knowledge is ridiculous hokum."
... Bill James

"It is not the task of the University to offer what society asks for, but to give what society needs."
.... Edsgar Dijkstra

My sons have prompted me to read Moneyball by Michael Lewis. Anyone interested in baseball should find this a fascinating read. While contemplating Moneyball I found myself making comparisons between baseball and software development. The book tells the story of Bill James who began to statistically analyze baseball data and his results showed that there were skills that weren't recognized as having appropriate value. Value is considered in terms of what wins baseball games, contributions to runs. His efforts to convince the baseball establishment were met with stiff resistance. His message, although statistically sound and rational, was not synchronous with an irrational and stubborn baseball culture. I wondered whether the baseball phenomenon was similar to the resistance of the academic computer science culture to incorporate new proven methods, such as unit testing, into fundamental programming courses. This "we don't need no stinkin tests" culture leads to the creation of professionals who haven't been taught a very valuable skill that is sorely needed in the contemporary IT work place. A parallel example in baseball is that as youngsters, baseball players are not taught to be more selective about which pitches they swing at. Just as it has been shown that on base percentage is a more meaningful (in terms of contribution to runs) statistic than the batting average, we still announce a player's batting average when watching a televised baseball game. When was the last time you heard a baseball announcer tell the player's on-base percentage? We are a culture paying attention to statistics that focus on a less important aspect of the game. In software development, although it has been shown numerous times that unit-tested software increases ROI, our industry still suffers from >50% failure rates in large IT projects. Nevertheless, just as in baseball, we continue to go about these projects in the way the culture dictates instead of following proven practices. Even worse, we educate future programmers the same way we did fifty years ago. Isn't it time to re-evaluate how we are educating our future software developers?

Moneyball describes the development of the science of baseball to the point where people began to analyze the game from the perspective of derivatives in the stock market. However, to accomplish this, a better system was needed to analyze baseball events. For example, when a person hits a double in baseball, there are so many factors in play, that from an analytical perspective the term 'double' did not contribute enough information. An entirely new system was designed to analyze the events in baseball. The same is needed in software systems development and in the educational process at the undergraduate level.

Mr. President - Stand down

Upon reflection, I modified my original post by inserting the following quote from Nietzsche.

"He who fights with monsters should look to it that he himself does not become a monster. And when you gaze long into an abyss, the abyss also gazes into you."

Dear Mr. President:

I'm disheartened to hear statements regarding whether your administration will seek to prosecute former Bush administration officials for breaking our laws regarding torture. What happened to our beliefs in law as a process? We have institutions that investigate these matters so why not let them do their jobs? Isn't that why Gonzalez was discredited - following the wishes of the Bush administration? Let's hope our current justice department isn't waiting for you to make the call Mr. President. Please, stand down and let them do their jobs and permit us to believe you aren't calling all the justice department moves.

Respectfully but in doubt,

Doktat

Open Source Software vs. Caveat Emptor

One of the common arguments for proprietary software is that there is some kind of permanence in having a corporate entity backing the product you have invested in. To counter this I tell the following story. When Java first appeared in the mid-90's I was very eager to learn it and invested in a Java IDE from Symantec called Visual Cafe. It was a good product and won a best tool of the year award , a CNET Excellence award for Internet tools and many other accolades. Things were good and I was learning Java and paying handsomely to keep up with the Visual Cafe updates. Yes, I was thriving in the throes of capitalism and proprietary software ... and then it was gone.

No, Symantec didn't go out of business. They sold the product line to BEA and BEA did nothing with it but put it away - my investment meant nothing (caveat emptor). What remains of my investment is an unsupported product that is out of date and useless. My graduate research mentor used to say, "Don't descend into the well on a frayed rope." In my mind proprietary software is a frayed rope. Buying a software product should mean paying for access to code not a black box (I am reminded of Scott McNealy's question "Would you buy a car with the hood welded shut?"). Then, if the software company goes out of business, at least you have the code to do with as you please (except take it and sell it again). Better yet, go with an open source solution and use the money you saved to invest in a person who will know and understand how the software works or buy support from the people who wrote the software. Then there will never be a time when your software becomes useless due to bankruptcy or pricing. Beware of proprietary software, it is a short term solution with no future. Go with open source - no one can ever take it away from you.

Prompt Corrective Action Law (PCA): Off With Their Heads

Haven't seen the interview of William Black by Bill Moyers? Don't miss it - it's an eye opener and methinks something is terribly rotten in er ... ah, not Denmark, but dear old USA. Black's claims of fraud and implicit assumptions that we've been taken by the short term strategies of current corporations gone to extremes - ah, that is, crime - are scary. But even more frightening is the discussion of the PCA (Prompt Corrective Action) law and the fact that this law is not being enforced - a law that was intended to protect the taxpayers from failing banks.

Yes, I see reports of angry people in the USA but where is the action in the streets? We have been and are being screwed by the financial bourgeoisie in this country and we should be rioting. What has happened to the indignant riotous rabble that characterized those who founded this country? It appears that even Obama is held captive by the infamy. What is happening? We don't know and that is what Black is saying - it's a cover-up. Please don't tell me we need the executives, who ran us into this ditch, to get us out of it. If it's the law then the law should be enforced - particularly when the intent of the law was to protect us from what is happening right now - the looting of our citizens.

Time for a Paradigm Shift in Programming Pedagogy

### CODE ALA BUGS ###

A long-standing problem in software development is the detection and elimination of bugs. Numerous procedures such as Design by Contract , Cleanroom Software Engineering and Test-driven Development (TDD) are known to minimize bugs. Thus, one wonders why such practices are not used extensively in contemporary practices. Michael Feathers has recently noted that the common attribute among these practices was that they all required contemplation of the code’s purpose.

As an educator this lack of certainty regarding a programmer’s ability to write effective code triggers the question whether we are teaching programming courses appropriately.

### PEDAGOGICAL PRACTICES ###

Examination of current programming texts reveals the general approach to how programming courses are taught. This involves the reading, lecturing and discussion of the programming concept, studying code examples implementing the concept, and problem solving. The later generally requires the student to write a simple application involving the use of the above-mentioned concept or principle. The code correctness is easily determined because the application is simple. The application can be executed with a varying set of input data and the results determine the correctness of the code. This approach works adequately in such simplistic circumstances but fails when programming larger and complex software systems. Nevertheless the beginning programmer learns to depend on this quick method of verification during this important developmental stage.

### DENIAL AND INTERVENTION ###

The troubling aspect of this approach to teaching programming is the denial ensconced in the approach to the solution. The approach assumes the programmer will write code that will do what the programmer thinks it will do. The denial lies in the failure to recognize that the code often doesn’t do what it was written to do. In the words of Kent Beck
“I am good at fooling myself into believing that what I wrote is what I meant.”1
Even worse is the inability to alter behavior to compensate for this failure. Could contemporary computer science faculty be responsible for permitting this state of denial? Is it time for intervention?

### UNCERTAINTY IN PROGRAMMING ###

Programming students should learn about the uncertainty inherent in writing code; that all programmers, even excellent ones like Kent Beck, are susceptible to this uncertainty. Programming students should be taught that along with the recognition of the uncertainty implicit in the process of writing code, comes the realization that their solutions must be considered hypothetical. Hence, the validity of their hypothetical code solutions relies on how extensively the hypothesis has been tested. But wait! – isn’t this the scientific method every school kid learned in their K-12 years?

### PROGRAMMING AS SCIENTIFIC PROCESS ###

Considerable evidence exists that software creation is riddled with uncertainty and thus untested code represents at best a guess at a possible solution. Shouldn’t this be the fundamental principle taught to programming students? Why isn’t testing the validity of the hypothetical taught as the foundation of programming? In the face of the problems currently found in software development, why do we continue with a failed approach to programming pedagogy? Isn’t it time to confront the denial ensconced in the assumption that we can write code that will do what we intend? Hasn’t the time come to teach programming as a scientific process?

### SCIENCE & TDD ###

Test-driven development (TDD) defines a process whereby the programmer first writes a test which determines whether the intended function accomplishes its purpose. After the test is written, the function is then written to pass the test. Inherent in this procedure is the recognition that to truly understand the function one must understand how to test whether the function works as intended. This act is what Michael Feathers calls the contemplation of the code which is required to practice TDD along with other processes such as Design by Contract and Cleanroom Software Engineering. However, also implicitly assumed is the recognition that writing code is fraught with uncertainty and although the language of TDD is not that of the scientific method, the intent and the results are equivalent.

### REFERENCES ###
1. Beck, Kent (2000) Extreme Programming Explained: Embrace Change, Pearson Education, [ISBN 8178086670]

SOA IS A HACK

Anyone reading my expositions must recognize that most of these writings were created when I was teaching software design courses in the masters of software engineering program at Carroll University. Thus, a good part of the tone I have strived for is that of provocation, and stimulation to think about the problem. The following piece was written in 2008 after reading a piece on SOA - which used to be called web services. Today I came across a blog by UncleBob Martin on SOA and I decided to recreate my original exposition here.

Here is the email I sent my class introducing them to my discussion of SOA.

##BEGIN PASTE##
First, thanks to StudentX for continuing the discussion with the link to the article by Craggs on reasons for failures in SOA projects.

Second, anecdotal pieces by consultants that contain no factual data should always be considered with skepticism. This statement comes from my background as a scientist who wandered into the “software engineering” arena. My primary criticism of “computer science” has long been (I recall arguments with my wife in the 80’s over this point) that it has little to do with the scientific method.

I recognize that I’m thinking at an idealistic level but many of the problems described in Craggs’ article can be considered from my perspective. Consider the following quote from the Craggs’ article:

“SOA is not just something that can be “installed and switched on.” It’s a lengthy process, involving the business as a whole rather than just IT. As already discussed, for example, failure to involve the business units with SOA design decisions will result in an implementation almost guaranteed to fail to match expectations.”

This is the problem my son brought up – that the various groups within the organization could never get together to create an integrated domain-object model (DOM). In addition to the cultural mismatch, there was probably also a physical separation between groups. But I say, as indicated by the above quote, that there has to be significant integration of the cultures in the various functional organizations to do the SOA integration too. Just because it’s SOA, doesn’t make this problem go away. I’d rather work on integrating the disparate systems by putting them into the same DOM than speculate with SOA.

I got a chuckle out of the following quote from Craggs’ piece because it could have been taken out of a classic systems and analysis book (Kendall & Kendall, Whitten & Bentley, etc.) published in the 80s. This is nothing new – this problem has been around for a long long time. No silver bullet here.

“But the last reason for failure to meet expectations is by far the most common and can be truly devastating. Companies repeatedly build great strategies and plans for SOA, only to find that when execution is attempted, there are countless roadblocks and inhibitors to success. The cross-departmental interchanges never happen, resource availability becomes a problem, and attempts to gain agreement on service specifications descend into endless bickering. These issues typically stem from a lack of buy-in for SOA at the senior management level.”

And finally, the last quote really comes back to my original challenge of *how* the SOA was going to solve problems. This is a reformulation of the ‘South Park Underpants Gnomes’ problem.

“Another common frustration is being unable to get budget approval to support an SOA implementation. A major contributor to this problem is having a poorly prepared business case.”

Thanks for your indulgences – feedback is welcomed – this is an important topic.
##END PASTE##

Doktat Pontificates on
Systems Integration
or
DON'T BURY YOUR SKELETONS

Since 2001-2002 I have been pondering the move to systems integration via web services (we first studied web services in CSC560 in spring 2002). Conceptually, the idea seems plausible, but I heard the first warning shots several years ago during a web seminar. The participants were discussing attempts to create web services architectures and were finding unacceptable performance and were experiencing difficulties locating the source of the problems. The message was that when an organization moves in this direction, it should have a clearly defined strategy for how the system will be tested and criteria for what will be acceptable performance. Recently (spring 2008) an article appeared citing survey results indicating that most of those surveyed thought their IT departments incapable of implementing a system with the degree of sophistication required by a web services architecture. Subsequent discussions in the CSC560 course prompted the following.

For purposes of discussion, consider the schematic below. Here we see the integration of three different systems running on three different platforms using three different languages

encapsulating the business logic of three different databases. Basically each system is converted to a service by wrapping with an xml-based layer that assumes responsibility for marshalling/un-marshalling requests for that system's resources. The business logic remains encased in the language of the system; the methods of which are invoked via the xml wrapper. Integration of these disparate systems is implemented by an architecture shown here as the services oriented architecture (SOA). If we consider each of these systems "legacy" systems (and I'm using the term legacy to imply any system not accompanied by an automated suite of unit tests), one must wonder where in the system the tests will reside. So, from my perspective, we have just overlooked a nasty problem that the magic of web services isn't going to solve. I don't think this type of approach is the way to solve integrating systems with different platforms and different languages supporting business logic. The following schematic suggests an alternative approach to this problem. The platform problem is handled by JDBC drivers that handle the communication with the database.

The critical difference is the movement of the business logic from the platform and language-dependent system into a domain object model which is where the integration should occur. Organizations refusing to deal with this problem are not facing the real problem. The translation and integration of the business logic into the domain object model would provide enormous advantages and set a better foundation for moving towards a progressively complex future. It is clear that the best path to managing complexity is via POJOs that can be tested independently and this requires an integrated domain object model. Thus, in my opinion, the use of web services for integration of an organization's disparate systems is a hack. Who would want the responsibility of managing such a monster when at its very foundation lurk the nightmares that prevent a clear and fear-free testing strategy with no clear way to test its network performance?
Am I saying no web services at all? Consider the schematic below. Note that the marshalling/un-marshalling of xml-based requests can be handled by the front-end controller displayed there.

I Can't Believe It's Not Software

In yesterday's congressional testimony with AIG CEO Edward Liddy, the following was stated by New York's Gary Ackerman:

There's a great product called "I Can't Believe It's Not Butter," but at least they have the decency to tell you it's not butter... They're calling it "credit default swaps" because if they called it "I Can't Believe It's Not Insurance," he says, maybe no one would buy it.

In last evening's lecture, I found myself comparing this to software systems. A software system is code which includes an automated suite of unit tests. The unit tests are part of the system. A program is code without an automated suite of unit tests but often "sold" as a software system. Feathers calls any code not accompanied by a suite of unit tests, "legacy software." Perhaps a better name for it could be, "I Can't Believe It's Not A Software System." I offer this in the spirit of hope that software developers assume pride in their craft (ala UncleBob Martin) and at least have the decency to tell you when they are giving you a program versus a software system.

State Design Pattern and Schrodinger's Cat

In Programming Without Ifs: Challenge Two, our state diagram modeled that of a stopwatch. We found what varied (the behavior in response to a button click) and abstracted into an interface and named the method 'execute'. However because we wanted to avoid the use of conditional logic to decide what to do depending on which button was selected, we created more states to encapsulate the specific behavior we wanted. For example, when the stopwatch was in the 'RUNNING' state it could transition to either a 'HOLD' state or a 'STOPPED' state depending on whether the HOLD or the START/STOP button was subsequently pressed. Thus, we created two states, RunningToStopped and RunningToHold to represent the respective behaviors. How is this like the famous Schrodinger's Cat problem?

A fundamental property of quantum theory is superposition of states which mathematically expresses a system as a combination of many different states. When we go to take a measurement of the system, we collapse the wave function (expressed as a superposition of many states) into one of the possible states. But before we made the measurement, we have no way of knowing what state the system is in. Schrodinger's Cat was a thought experiment (gedanken) designed to show the strangeness of quantum behavior. I liken the above described application of the State Design Pattern to Schrodinger's Cat for the following reason. When the stopwatch is running it is actually in both the RunningToHold and RunningToStopped states simultaneously and we don't know which one it is until we hit either the 'HOLD' or the 'STOP/START' button. It is only after the button is clicked that the stopwatch assumes one or the other state.

Conditional Logic and Code Smells

>>>

At Ward Cunningham's wiki one finds a discussion entitled Switch Statements Smell. This discussion begins with considerations of Beck and Fowler's statement in chapter 3 of Refactoring (Fowler, 1999) that switch statements were smelly because they tended to create duplicated code. I unsuccessfully tried to add to that discussion the treatment found in the Gang-Of-Four book (Gamma, 1999). So, please find below a few more thoughts.

MONOLITHIC and LESS EXPLICIT
The following quote predates and complements Fowler and Beck's discussion in chapter 3 of Refactoring. In the Gang-Of-Four book one finds the following quote on page 307.

“Like long procedures, large conditional statements are undesirable. They’re monolithic and tend to make the code less explicit, which in turn makes them difficult to modify and extend. The State pattern offers a better way to structure state-specific code. The logic that determines the state transitions doesn’t reside in monolithic if or switch statements but instead is partitioned between the State subclasses.”

DECOUPLED STATE-BEHAVIOR PRINCIPLE and TEMPORAL IGNORANCE
Using conditional logic to implement behavior which is dependent on the state of a class is programming in temporal ignorance. If a change of state has occurred that affects behavior, then the readyness of that class to implement the appropriate behavior should occur synchronously with the change of state. Why should an object live in ignorance when a change of state has occurred that will also change how the object behaves? I refer to this state of ignorance as decoupled state-behavior (DSB). Allowing the state of an object to be decoupled from its behavior should be considered a loose end, a piece of untidyness which requires conditional logic to be resolved. Why leave such loose ends around? They can only lead to problems. Note that this does not apply to using conditional logic to determine other actions not related to the state of the object. DSB refers stricly to the relationship between the state and behavior of the same object. Since DSB requires conditional logic for resolution, this situation also demands consideration from the race condition perspective.

IF STATEMENTS AND RACE CONDITIONS
Temporal ignorance creates race conditions. In addition to violating a principle of OO programming, that a method should do no more than one thing, conditional logic statements are not thread safe. Consider the following 'if' statement:

if (propertyValue == 1)
execute statement1;
else
execute statement2;;

We generally assume that nothing will change the value of propertyValue before we execute statement1. That is a false assumption. It is easy to create race conditions where the propertyValue is set to 2 by a competing thread in between executing the 'if' statement and executing statement1 in the example above. Wouldn't it be smarter to securely change the behavior at the same time the property value is changed?

public void setPropertyValue(int intValue)
{
synchronized (this)
{
propertyValue = intValue;
currentStrategy = appropriateStrategy;
}
}

REFERENCES

Gamma, Erich et al (1994) Design Patterns: Elements of Reusable Object-Oriented Software [0201633612]

Fowler, Martin (1999) Refactoring [ISBN 0201485672]

Over-Engineering and Design Patterns

I began studying design patterns in roughly the same period that I read Beck’s treatise on eXtreme Programming (Beck,1999). There is a conflict between the two schools and it’s important to consider it. The design pattern mantra is that we have identified a pattern that occurs often in programming and we have a way to solve it. No sense reinventing the wheel, there’s a pattern that solves the problem in a way that creates desirable software architecture. By learning these patterns we are creating a system of best practices which includes a richer vocabulary. By applying these patterns, we create more loosely coupled systems that are easier to maintain and change. From a pedagogical perspective, this is important to learn and a key stage to development. The process of understanding your system’s responsibilities and identifying these patterns is important in the development of OO thinking - which is entirely different from procedural thinking. But then the student encounters the “Stop Over-Engineering” people and becomes confused.

After passing through his phase of studying, understanding and applying design patterns, Kerievsky (2002) wrote a short paper entitled, “Stop Over-Engineering.” He thoughtfully describes his evolution to the following recognition: “But over time, the power of patterns led me to lose sight of simpler ways of writing code.” After relating a story where he realized, while pair-programming, that his approach to solving a problem was "… like applying a sledgehammer when a few light taps with a small hammer would do," he proceeds to describe what I believe is the next pedagogical stage in a programmer’s education, refactoring.
Nevertheless, a student of OO programming can’t stop over-engineering unless they know how to over-engineer in the first place. Kerievsky’s insight and subsequent treatise (Kerievsky, 2005) is the product of an active consultant in the software construction business. Students must learn the difference between the teachings of a professor and the teachings of a professional. The latter isn’t necessarily concerned with the entire pedagogical structure - their audience includes those who have mastered the stages leading up to their current level of understanding. The Kerievsky teachings are not for those who haven’t already studied design patterns. So, in my opinion, learn to over-engineer first (Gamma et al, 1994; Metsker, 2002; Shalloway & Trott, 2004;Martin, 2002 ) and then begin your studies of Kerievsky (2005) , Fowler (1999) and Beck (2002).

REFERENCES:
Beck, Kent (1999) eXtreme Programming eXplained: Embrace Change [ISBN 0201616416]
Fowler, Martin (1999) Refactoring [ISBN 0201485672]
Kerievsky, Joshua (2002) Stop Over-Engineering [http://www.industriallogic.com/papers/StopOverEngineering.pdf]
Kerievsky, Joshua (2005) Refactoring to Patterns [ISBN 0321213351]
Martin, Robert (2002) Agile Software Development: Principles, Patterns and Practices [ISBN 0135974445]
Metsker, Steven (2002) Design Patterns Java Workbook [ISBN 0201743973]
Shalloway, Alan and Trott, James R. (2004) Design Patterns Explained: A New Perspective on Object-Oriented Design, 2nd Ed. [ISBN 0321247140]

Dropping Procedural To Go Object-Oriented

I am often making the statement that many programmers who think they are object-oriented (OO) programmers are procedural programmers using an object-oriented language. In this piece I hope to explain clearly what I mean.

For the past ten years I've been interacting with professional programmers enrolled in the Masters of Software Engineering program at Carroll University. In general these people are bright and clever at solving algorithmically-oriented problems. However, they often struggle with learning techniques in OO programming and design - particularly with the idea of assigning responsibility for actions among a collection of objects working in harmony. They have learned to solve programming problems in a procedural manner and when presented with the OO paradigm, they quickly learn the OO language but fall into patterns where they use the OO language to program procedurally. Talented procedural programmers need to expand their capabilities to meet the demands of more complex software.

There are many different interpretations of what procedural programming means. For example UncleBob Martin has stated that inverted dependencies is a sign of procedural programming(Martin, 19XX). I like this definition but I think it takes someone who already understands how to "object think" to grok it. I will continue here with more discussion of what I mean by procedural programming.

For me the first sign of a procedural programmer is the centralization of responsibility which is seen when we find objects that are doing too many things. Also, within these mega-classes are found methods that are also doing too many things and generally contain large conditional logic structures. The cognitive process used to create these types of programs indicates either ignorance of or a misunderstanding of the goals of OO programming. Or, if the goals are understood, the method for achieving these goals has never been learned. At this point the discussion could easily segue into an "objects first" debate which will be considered in some other piece. For me which side of the "objects first" debate one may take is irrelevant, it is clear that somewhere in the progammer's education, a critical step in their thinking processes has not occurred. These types of programmers are not suited for creating large enterprise software systems. These types of programmers create what are known as Big Balls of Mud.

Stop Relational Thinking

In my opinion the only reason why relational thinking should be kept in the contemporary curriculum is because of historical purpose and the constraint imposed by contemporary corporate data centers running relational databases. Come on people, there's a much better way to do things. Why are we constrained by this outdated, inferior and inadequate mode of thinking?

Developers should never have to think relationally except when they need to interact with those ignorant of object-oriented thinking. The object model is vastly more powerful than the relational model and when developers are thinking relationally, they are creating the wrong environment. Developers should always be thinking of the domain-object model which includes behavior along with data. The data model is a subset of the domain-object model and is easy to generate when needed. The data model is considered for those on the relational side of the operation and have limited understanding (MIS types).

Yes, I understand about the object-relational impedance mismatch. All developers need to understand this important constraint when interfacing the OO world to the relational world. In the meantime, the language of the developer should be in the context of the domain-object model. If the organization isn't using an ORM tool (ie., Hibernate), then the least acceptable architecture would include a persistence layer so separation of concerns is maintained. SQL should never appear in your POJOs.

Dependency Inversion Principle

This morning I was "retroFactoring" an application for purposes of giving an assignment to my software design class requiring application of Robert (Uncle Bob) Martin's Dependency Inversion Principle. I say "retroFactoring" because I was taking the application that was already refactored back to an application that I will give to the class for refactoring. In the process of doing so, the inversion of the dependency came about forthwith when I removed the interface. This required the switch class in the 'device' ('higherlevel') layer to learn about the classes in the 'lower level' layer - the light bulb and the fan. Thus I had to place an import statement in the switch class ('higher level') so it would know about these switchable objects ('lower level'). It was when I realized that I needed to place the import statement allowing access to these 'lower level' classes that I realized I was setting up the dependency of 'higher level' classes on 'lower level' classes. This is exactly the situation Martin refers to when he states: "High-level modules should not depend on low-level modules."

Programming Without If's: Challenge One

During the time between 2005-2009 I began my software design courses with a problem I call the “Bergin Calculator Problem” (Inspired by Joe Bergin’s Polymorphic Calculator). It requires the student to program a simple calculator with only six buttons. Three number buttons (2,3,5) , two operator buttons (+,-) and an equals button. The calculator need only perform one binary operation before yielding an answer following a strike on the equals button. A typical computation would involve entering 2, 2, +, 3, 3, = … and the display would indicate the answer of 55. The display would show the numbers entered in both the pre-operator and post-operator modes, but not the operator itself. Thus, one would only ever see numbers in the display. Following each computation, striking the equals button would also render the calculator ready for a subsequent computation with an entirely new set of numbers.
Over ninety per cent of the submissions I graded used conditional logic to solve the problem. The week following, the class would go through the problem and together, construct a calculator that uses no conditional logic nor loop structures. The fact that this exercise amazes many students, indicates the very real possibility that most have been taught how to use an object-oriented language to do procedural programming - a very easy thing to do. In fact, I recall one graduate student who had taken the problem back to his work place and one of his co-workers, literally a rocket scientist, said the problem couldn’t be solved without the use of if’s. Since then, I have taken to giving problems to students that require them to produce a solution not dependent on conditional logic – I call this “Programming without if’s.”
I will discuss in another place the problem of over-engineering but for now assume it’s OK, in fact desirable, to construct an over-engineered solution. Why? The metaphor I like to use is that of the toolbox. When you go to your toolbox and see only a hammer, then every problem appears to be a nail. Most contemporary programmers were taught by procedural programmers whose only adaptation to learning object-oriented programming was to begin using an object-oriented language. One way to break out of this mental trap is to solve some problems without reaching for the hammer, which in the programmer’s case is the conditional logic structure.
Do I expect programmers to avoid using conditional logic as a best practice? No, the student of programming has to understand the difference between what we do to expand our capabilities, ie., put more tools in the toolbox, and what we do when programming professionally. Programming without if’s will expand your ability to see alternatives in the power offered to you by the object-oriented paradigm. If you’d like to take the Calculator Challenge a zipped Eclipse project named SwingCalculatorWithIfs is here. See if you can refactor this code to a solution that contains no conditional logic (if statements). A discussion of the answer will follow and I will post a solution at the same address the challenge code was posted.