Agile DNA

I claim that most Java/J2EE applications are written in a Data Processing (DP) style. Rather than an OO style. I'll also say that over 90% of the java being written is DP-oriented. Since most development is in DP style, is Java really the best choice for building DP programs??? (Years were spent in attempts to use C++ as an everyday OO langauge.) That's why I'm trying to raise the issue of COBOL oriented J2EE.

Java is a mostly-OO language. But the culture that surrounds it is a mostly Data Processing culture. You can't (probably shouldn't) build OO apps in a DP culture. I have nothing against Data Processing. It has a cost/benefit model that may work in some situations. I'm just concerned that an OO language being used in a DP culture is a mismatch.

I gave a talk in Febuary 2005 at the local java group called COBOL oriented J2EE

The point to the talk is not to say that "COBOL orieinted J2EE " (COJ) is good. COJ makes development and maintenance harder and more expensive.

However, "COBOL oriented J2EE" (COJ) is the dominant paradigm. And if we want to make our jobs easier, we need to understand:

(1) why does COJ exist? (2) what is Domain Design? (3) who benefits from COJ? (4) How can those same people benefit more from OO Domain design? (5) What small easy steps can we take to more toward OO Domain Design? or How to escape being just a "COJ on the wheel" (couldn't resist :-)

That's a pretty long list to cover in one short presentation. But I tryed to give some jumping off points for people who want to go deeper in a particular area.

After the presentation below Steve G. asked : When the user (the one who is paying the bills) starts the project off with 'we know what data is available, and we've mocked up what we want the pages to look like and how they should flow, what we need is for someone to get it on the Web' ... you'll never get out of the Data and Processing scenerio. How do you typically address these?

He's absolutley right. That's why I say the the Data Processing attitude is deeply dug into the larger culture. The OO or DP decision is usually made before anyone knows that they are actually making a decision.

However, you can at least put together a Simple Domain Model and build with that. The requirements above do push you into talking about data and transformations, where you implemented is still (maybe) under control of the programmer/designer.

It's best, of course, if you can refocus the requirements discussion away from data fileds and transformations and onto business problems and behavior.

That is often quite tricky given that most IT people and most business people deep in their sub-conscious can only think about programs in terms of non-OO, data processing concepts. That's one reason I also talked about small improvments we can make like eliminating the use of un-encapsulated, public constants. It's a small thing. But it can move us all to focusing more on Behavior and Nameing. With any change, I encourge Baby Steps in the OO direction.

Many people are realising the need for functional testing. The seach for these is often limited to commercial screen driven test tools.

While I don't have numbers to back it up, my experience is that the commercial screen driven test tools are nearly as expensive as manual testing. They perform very nicely in demos for management because they simply record the user's actions and replay it later. What could be less expensive???

Most time they fall down because as soon as something changes someoneneeds to rebuild many of the scripts. This either happens over and over again, or the scripts are abandoned. Mostly, I've seen them abandoned. Plus (or better said 'minus') you have to pay for thesescreen driven tools, lots.

So, whats the alternative? Well it would require upfront work, giving lasting value. The functional testing tools I recommend are

• www.fitnesse.org
• http://wtr.rubyforge.org/

If you want your user's to take ownership of writting the tests, youcan use Fitnesse as the tool for them to enter the tests. If you want to drive IE via the ActiveX interface in the simplestpossible scripting language I've seen, use Watir.

Either way the tests are more maintainable because they are code notsome binary, proprietary format. And you pay nothing for the tools. One of the items on my personal todo list is to write a Fitnessefixture in Watir. Unless it has already been done.