Naked Objects Exposed

I think I now have a handle on what makes Naked Objects interesting. I had previously perused the site and came to the preliminary conclusion that it’s just a generic UI framework. Last night at the DFWPP (Dallas-Ft.Worth Pragmatic Practitioners) meeting I got to hear Dave Thomas talk about Naked Objects (and believe me, it is a topic rich with double entendres). It helps me to think of Naked Objects in a parallel manner to TDD (Test Driven Development).

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>

Note: This is crossposted to my java.net weblog.

potential differences [/development] permalink

NoFluffJustStuff

I had a great time at last weekend’s Dallas NoFluffJustStuff symposium. I was so busy putting together the presentations, I didn’t have a chance to mention it ahead of time here. I’m also slated for the Atlanta and Denver instances. The three talks in my current set are on Expressive Code, a JMX case study, and I/O performance tuning.

One of the best things about these conferences are the hallway discussions. All the speakers are very accessible both in and out of the sessions. I almost gave away Stuart Halloway’s classloading talk (good thing he shut me up quickly :-) and Ted Neward had some great input during the QA of my JMX talk when a question was asked about some overlap between the things JMX and Aspects are good at.

Kirk Pepperdine has talked me into preparing an article for an upcoming issue of the Java Performance Tuning newsletter based on a performance hack I talked about in that talk. I’ll put a note here once it’s published, but you could always go get yourself subscribed in the meantime.

potential differences [/development] permalink

Another Software Development Analogy

There’s much discussion of different analogies for software development. Some like to think of it as engineering such as building a bridge. Others like to compare it to building construction. The Pragmatic Programmers compare it to gardening. But none of those really resonate with me.

James Robertson compares it to movie production. Now that’s an interesting concept. We always hear about movies missing time/budget projections. Producers are the financial sponsors. The director has creative control. Various tradespeople (craftsmen?) do the acting, camera, sound, editing, special effects, etc. Most of those are organized around unions or guilds. Each movie is unique, but may be formulaic, and the cost of copies is miniscule compared to the cost of the development in the first place. I think this analogy has legs.

It gets me thinking about a guild or union structure for developers. Could it work? A few years ago during the dot-com boom it certainly wouldn’t, but I wonder if it would these days. Fred Brooks talked about a 20X difference in productivity between developers in The Mythical Man Month and Pete McBreen talked about compensating developers based upon that in Software Craftsmanship. You see an even broader range among actors, yet they are all members of the Screen Actors Guild. It sure would be nice to be a Mel Gibson equivalent in a Software Developers Guild :-)

potential differences [/development] permalink

Generalist vs. Specialist

I’m playing some blog catchup right now, but there’s another entry of Brian Marrick’s I want to comment on: Technology-facing Product Critiques . In it he explores the need for specialists even in an Agile project. I’m not certain I can completely agree.

I submit myself as a counter-example to his argument. I’m a developer, and Agile-minded. I’m interested in security, UI design, and even testing (why I started reading his blog in the first place :-) I guess that makes me a jack of all trades and a master of none. While I may not feel qualified to be the sole person in charge of security, UI design or testing on a project, I do think that with a group of developers that are as much of a generalist as I am, we could collectively get the job done.

I suppose pragmatically there’s the question of how many projects have a group of generalists this broad. Maybe I’m just a singular oddity. I’ve been accused of that before.

potential differences [/development] permalink

Hardest Part of Software Development

Over time I’ve come to realization that the hardest part about software development is human psychology and sociology. That was the farthest thing from my mind when I was a bright-eyed and bushy-tailed newbie professional programmer (mumble) years ago. Maybe I’m just getting old, or maybe this is specific to software development inside enterprises, where the majority of my experience is.

In so many cases it seems the most frustrating parts are getting people to care — mostly to get developers to care about honing their craft and their own skills. But I could take it in many other directions — different sets of people, different things they should care about. Anyway, this puts me squarely behind Brian Marick’s position paper to the NSF on the science of design. I agree with his stance completely.

I hope this isn’t pushing me toward the path of … management !

potential differences [/development] permalink