On the surface TDD looks like it is primarily a means of testing. The 'aha' moment happens when you invert your thinking. TDD is primarily a design tool, and secondarily a testing method. It ends up that testable code is more cohesive and loosely coupled, and that's the major benefit. My 'aha' moment with Naked Objects happened when I began to see it as primarily a design and requirements gathering tool, and secondarily a UI framework. Coding in Naked Objects style promotes minimal temporal coupling (the GUI is modeless), complete business rules in the business objects (none of it hanging in the GUI layer), and explicit relationships between business objects (so the GUI knows what can be dragged and dropped onto what).

So, just as TDD taught us that testable code is well designed code, so now Naked Objects are teaching us that naked (or maybe strippable?) code is well designed code. Also in a parallel vein, we know that the unit tests from TDD are rarely going to be a sufficient amount of testing, so also the GUI of Naked Objects is rarely going to be a sufficient GUI. Just as the more traditional functional, system, and user acceptance tests can be added to a TDD-built system, so too can a more traditional menued, or script-driven GUI be added to a Naked Objects-built system.

Dave will be giving that Naked Objects talk (and also one on Coupling! I warned you about the double entendres) at the Atlanta Java Software Symposium this coming weekend. Come if you can! <shameless-plug>You can even hear me speak on JMX, IO Performance Tuning, and Expressive Code there too.</shameless-plug>]]> 2008-01-02T17:42:16Z 2003-09-10T03:15:01Z tag:weblogs.java.net,2003:/blog/gvaughn/66.507 2003-09-10T03:15:01Z

This blog entry will self destruct in 30 seconds....

This entry is a follow-up to my Fundamental Problem with Extreme Programming, the great comments it generated, and Philip Brittan's XP, User Champions, and Software Vendors. It's great seeing the conversations flow. It helps me to refine my own ideas as I get feedback from a larger group than just the folks I meet in person. I've also recently read a free requirements chapter of Christopher Duncan's book, The Career Programmer which I've just added to my reading list.

Like Philip, I have been in a situation with a self-appointed project champion who knew the business and was extremely interested in software. It was great to develop on that project for a while, but things went south very quickly when she started throwing around political clout she didn't really have and ended up leaving the company. Be aware of the failure mode of this approach. We became scapegoats when she left even though we'd done everything she asked of us.

I've known very few software projects that fail due to technical reasons. It's almost always political. It is usually an issue of either not understanding the business needs, or writing the software to please the wrong person(s). Because of this, focusing on optimizing the efficiency of the pure development effort, like XP, doesn't really help the underlying issue. Those of us typically introverted, logic-ruled developer types are going to have to determine to learn something about corporate politics. Yes, I actually believe that though I do not relish it.

What this means is that we're going to have to identify the head person that needs to be happy with the software, get some high level of understanding of what it'll take to do that, plus get him to delegate the details to someone or some group that we'll spend a lot more time with to wring out the details. Convincing him to spend his business people's time on this is going to require something akin to espionage. We've got to get inside his head and figure out how to present things in such a way that they further his individual goals. Also, keep in mind that his personal goals may not always be in line with just improving the corporation's bottom line (the logical position we techies like to argue from). In some cases, he'd get more political clout by having control of a bigger budget. We've got to learn what motivates him and adjust our approach based upon this knowledge

I'm not advocating dishonesty, but we techies need to step out of our navel-gazing tech-only mode and learn something about those topics that we typically say with a sneer on our face or while rolling our eyes -- politics, marketing, business processes, chain of command, etc. This is going to vary from project to project, and therefore a one-size-fits-all, the true cost of requirements are in your face, approach of XP doesn't work. It can work in the rare case you've got a project sponsor who's open to it, but your toolbox needs to have more options available to you.

I also have the feeling that demonstrating to the business sponsors that we know what they want politically in addition to the software technicalities, and learning to speak their language can also help with the issue of having our jobs outsourced. The real issue of requirements is figuring out what it'll take to please the person in the right political position. Enterprise software is never developed in a political vacuum, and we can either choose to accept that fact and work within its framework, or continue in our frustration and gripe amongst ourselves at how things should be done.

XP requires too much of an investment from the business. Even aside from the obvious on-site customer that XP requires (and Mr. Stephens makes a good case that the best you'll get is a junior person) there's the regular unfinished (and unpolished?) versions of the software they're expected to use and give feedback about in the Planning Game every few weeks. There's also the ideal of the business users working to develop the acceptance tests.

It's like watching sausage being made. Business users are not techies, and generally don't want to become techies. They want the software, and they want it with a minimum of their effort. The overall development efficiency that XP is built around actually decreases the business users' efficiency in doing their own job during the development. They find it tiring to think like a techie and answer all the detailed questions about how various requirements interact and handling all sorts of 'what if' scenarios.

Please, don't misunderstand me, gentle reader. I do respect XP. It has served as the spark that got people (me included) thinking more about Agile methods in general (though the ideas go back much further than that). I've written in more detail about why I choose to associate myself with the Agile movement rather than XP before. The gist of which is best explained by comparing XP to Free Software (FS) and Agility to Open Source Software (OSS). XP/FS adhere to uncompromising purity of their ideal. Agility/OSS agree with those ideals, but realize compromises must be made in the name of practicality. XP/FS have actually become special cases of the broader Agility/OSS categories.

I guess I'm just a practical sort of guy.

This is a really great (and subversive) idea. I wish I'd thought of it. I'm noticing a lot of work down below the level of J2EE. In some sense, it seems that J2EE has been developed backwards. Servlets came along first which is at the presentation layer, later EJB's came along for business logic. Next came CMP Entity Beans warts and all. Now JDO seems to be taking over the mindshare for persistence. However, the lower layers of infrastructure came later, or at least showed up with very little visibility. JNDI is an important layer that showed up with EJBs. Later came JMX, and then app server vendors worked furiously to build the foundations of their products on JMX. That's where the real low level foundation exists today. Aspect Oriented techniques (or Interceptor oriented if you prefer) are being using to more modularly implement much of these underpinnings.I also hear that Jini is even being used in some places for clustering of the app servers.

The subversive part (and I use that in the fondest sense) is now using JMX to get JavaSpaces and Jini in the picture as peers of the JMX managed web and EJB containers. JPower is the first I've heard of this, but I'll bet it won't take long for other vendors to do the same. Later on Sun might even catch up and make them part of the J2EE spec.

I'm excited that this might be the first step taking JavaSpaces and Jini to the mainstream. Go JPower!

Find some giants, and stand on their shoulders, to co-opt Isaac Newton's famous quote. I don't mean this as a way of keeping someone else down, but instead building upon their insight and work. Become aware of what's offered in the Java libraries you work with, be it J2EE, J2SE, or J2ME. There's lots of good stuff in there that often gets overlooked. Case in point: the other day I was doing a methodology exercise of breaking a feature into individual tasks. The feature was logging into a J2EE application. Out of about six groups particpating in the exercise, mine was the only one that had a tasks of learning the basics of JAAS (Java Authentication and Authorization Service) and configuring it in the appserver. All the other groups were ready to write their own custom login logic. I've never used JAAS before, but I've read an overview and knew it was commonly supported in J2EE containers (It's actually now part of J2SE 1.4.) and was specifically intended to be a reusable login service.

Now, the first time learning and using a new API may not save you any time over a scratch custom implementation, but it will save time the second and subsequent times you need to use it. Think over the long term about all these APIs you've had some experience with and how much faster you can do the well known pieces of your application. That frees up more time to work on the truly unique aspects of the particular application. Not only that, but coworkers will notice your experience and start coming to you for advice and you'll be able to help the speed of your entire team.