Having just returned to Melbourne after a longer than expected stint in The Netherlands, I have been going through the rigors of resume updating, assessing the market, applications, interviews and a temperature shift of some +34 C!

It’s generally a stressful time considering opportunities, balancing the base urgency of income with working in a challenging environment with quality people. Unfortunately, usually one doesn’t imply the other, with the odd stand-out exception. What’s made it a tad worse for me this time is the stressful and time-consuming nature of relocation. It’s been a distraction from performing pre-interview tasks that most competent organizations demand, such as solving coding problems or answering questionnaires. It’s also distracted me from pushing through my book list, with a book I’ve been looking forward to punishing, Agile Web Development with Rails, unfortunately taking a back seat.

Looking for a position this time around has also been a tad different for another reason. I’ve been asking myself if using the “J2EE” word is a bad thing from both a job advert point-of-view and from advertising myself as a “J2EE Developer” point-of-view. I’m very comfortable using the “Java” word but “J2EE” is another kettle of fish. Certainly I consider the use of the “EJB” word to suggest that perhaps an organization isn’t that switched on. I have no doubt most organizations using EJB are not doing so for sound technical reasons.

I guess a big reason why I’m dubious about using the “J2EE” word is its traditionally strong association with the “EJB” word. Of course I expect any “Enterprise” development I’ll be doing in the near future to be using some part of J2EE, so based on that alone it would be unwise to consider the “J2EE” word badness. It’s also not that bad given it contains a heap of API’s with perhaps only one bad apple in the lot.

But still J2EE anti-sentiment grows. More and more often comments on theServerSide discussions read “J2EE has cost organizations billions”, “J2EE has set the industry back years” and “EJB1/2 have done irrecoverable damage – EJB3 is too late”. Sure, maybe early on we veered from the asphalt, but the industry has firmly steered back on with Spring, Hibernate and alike. You cannot possibly argue that they (i.e. JCP committees) are continuing to steer us in the wrong direction – they have demonstrated a track record of responding to feedback. Maybe they steered us in the wrong direction when the industry wasn’t sure where it was going, and now it does and they are being responsive.

So right now I’m not too fussed using the “J2EE” word. Perhaps shortly I’ll be modernizing my role description to “Software developer with Java, Ruby, Python, experience” - especially as the software community seems to have no interest putting its weight behind a single language. Instead each language seems to be perfectly happy to develop similar features, each one striving to stretch it’s neck further to be the dominant language for a short time before others catch up. Am I the only one that sees this competition as somewhat saddening? So long as the software development community has a strong voice in the evolution of a language, the language itself easily produces DSL’s, and its syntax balances succinctness with readability – I’d be very happy to see one language dominate.

I guess this mirrors my sentiments towards, one day, having a world with one currency and language.

When I purchased Organizational Patterns of Agile Software Development I had a couple of things I wanted to sponge:

• Understand more about the structures of organizations and how they can nicely evolve.
• Learn more about the world of software development as managers see it.
• Gain an appreciation for the origins of XP.

It delivered on all points.

For my first two goals it provided reams of useful information on organizational healing and growth, and about the principles and practices of highly successful teams. For those wanting to know more, the book bases its core (a series of pattern languages) strongly on empirical evidence gained from analyzing highly efficient and successful organizations. It focuses on the values of these organizations and the product of these values – their structure and communications. It stresses the importance of organizational learning, the key to allowing organizations to remedy their dysfunctions. It presents some strategies organizational introspection and learning. As with most books I read the theory all seems sound, but this book goes deeper proving to you it works in practice by presenting successful use of the patterns. Often the authors provide insights that transcend software development, but that often seems to be the case for organizational/management theory. They also present plenty of antropological references that substantiate their theories and patterns, demonstrating stong background knowledge (for example Maslow’s heirarchy of needs).

As I read through the patterns, shortcomings of organizations I’ve worked for became very obvious. The patterns made paths to healing these organizations very clear. To me thats a sure sign this book is good value. While I’m usually a developer lacking the organizational influence to implement these patterns the book stresses you can plant the seed and play your part with your immediate team and colleagues.

On the origins on XP, it did provide some teasers. It cites Ward Cunningham’s Episodes Pattern Language work as providing ‘much of the foundation material for XP’. An early reviewer of the first published version of the patterns ‘would later go on to be one of the founders of Extreme Programming’ (anyone know why no name was mentioned here?). An early publication of the book ‘was an early influence on SCRUM’, a process familiar to all the ThoughtWorkers out there. So it certainly points you in directions where you can get more information about XP’s inception.

For those of you who have been disturbed with my passion for software design patterns in recent years, expect it worsen as our pattern conversations will now surely touch software and organizational design patterns (i.e. code and politics).

For those of you who have a passion for being a technician and staying that way, rest assured the book is targeted for developers, not just managers. The authors acknowledge their developer audience saying, ‘we predict that many that read this book will not be managers, but developers’. They even present some software design patterns that strongly align with the organizational patterns (although I wouldn’t recommend them).

Keeping true to the critical nature of my blogs though, I do have a couple of gripes. I raised on eyebrow when reading the authors ‘chose “Agile” for the title out of marketing concerns’. The patterns promoting an architect role did little to counter my animosity towards the role. The software design patterns presented seemed largely out-of-place and were very questionable designs, almost shoved in to convince the reader that the authors have been developers.

They also had a dig at XP on a few occasions, points I could see some merit in but largely disagree with:
Quote: ‘….if the organization adopts a policy of daily status meetings, it perpetuates the crisis mode or even creates a crisis mode…’. They go on to explain, ‘Even when not at work, the people will have work on their minds so they can be prepared for the next day’s status meeting.’
Rebuttal: Status/stand-up meetings streamline communications, allowing the team to engage in short and sharp conversations. The team also gets a collective picture of status allowing them to immediately identify and resolve blockages. These benefits are valuable to any collaborative team effort, crisis or no crisis. Regarding work remaining on the mind, reporting status becomes part of your natural rhythm of activities. I haven’t found it adds more stress to report on progress, any conscientious developer should know where they are at without expending any additional brain processing cycles.
Quote: ‘Other aspects of XP – such as the inability to work alone and the need to always have your thought processes open to a pair programmer – help sustain crisis mentality.’
Rebuttal: I see pairing as offering more opportunity for the collective knowledge of the team to be expressed in the code and to learn from others. I do not see it as a negative activity, a subtle way of assessing the adequacy of my domain knowledge or programming. Granted the less experienced are usually more suspicious of its merits.
Quote: ‘…focus on organizational learning distinguishes organizational patterns from other organizations such as XP, which, though rooted in principles, imposes those principles…’.
Rebuttal: XP has feedback, learning and evolution at the heart of its principles. XP doesn’t ‘impose’ principles, you progressively take what works most effectively for your context and culture, much like organizational patterns. Also, much like organizational patterns, they have individual benefits - benefits that strengthen and expand in symphony with other practices.
(Perhaps my instinct to defend XP indicates some close-mindedness on my part)

Regardless of these criticisms, I recommend anyone whose sponge wants similar information to what I craved to make the mental investment.

Before my last assignment, for sometime I had hoped to work on an a Swing App as a short break from developing web UI’s and to see how the other side lives. (Just like Simon does it seems)

Well my first experience has left me fairly jaded, mostly because Swing was far more complex than I expected – certainly far more complex than it should be. Perhaps Swing is another example of overtly complex software development in Java.

The most significant gripe I have with Swing is its tool and framework support. They don’t seem to be there yet, at least to the same quality and depth of web tools and frameworks. I guess its a reflection of the volume of Swing vs. Web App implementations. There are plenty of tools to assisting in composing Swing screens, but there’s always a catch. The code generated is terrible (sound familiar?), they require a custom component library, they come at significant cost. There have been no frameworks like a Struts that has strongly influenced Swing application development.

Some (non-coders) I worked with were of the opinion that Swing Apps must be simpler to develop than Web Apps. There’s less tiers right (as in physical tiers)? Yes, but I believe it’s actually harder. Yes, less phyiscal tiers may mean simpler installation and configuration, but as a software developer that doesn’t help my day-to-day activities. From a software perspective the same tiers exist - but Swing offers developers even more opportunities to hack. For instance, as the View is completely Java it offers more opportunity for the View to be spaghettized. Also a significant amount of ‘glue’ code is required to enable drag-and-drop, copy and paste, undo and redo functionality and alike. Glue that can be quite easily hacked to hold domain logic and other layers. So it requires plenty of discipline to maintain the conceptual integrity of Swing Apps, even more than Web Apps.

Talking of Swing Hacks, I recently purchased a book titled just that, Swing Hacks, containing 100 ‘hacks’ for constructing complex Swing UI’s. For mind, right now that title makes perfect sense for Swing.

Swing tries to provide you with the tools you need out the box, like progress bars, file choosers and transfer handlers, but they often require implementation or customization. This slows your progress and constantly gets you asking yourself, ‘It feels like I’m re-inventing the wheel here. Surely this type of thing has been done before? How could it possibly be this verbose?’.

Going even deeper, occasionally Swing’s API made checkstyle compliance extremely difficult. In cases were the API presented methods that contained some 8 or so parameters, the team had no alternative but to crank out a suppressions file. Data Abstraction Coupling was another that the UI layer consistently struggled with, after all it’s fairly common for containers to house a fair amount of components.

Then there’s the functional testing tools, there are plenty of them but each have their short-comings. Mind you, we were using open source tools (eventually choosing Jemmy) so you get what you paid for, but plenty of customizations were required. Screen discovery as Pam mentioned in her blog was one of them. We encountered larger issues striving to have our functional tests executed on both Windows and Macs, but we never expected that to be a simple task. Different key-strokes and different component behavior all mounted to tests that were time-consuming to produce, so much so that some journeyed to manual testing land (mysteriously never to be discussed again). The functional tests were also extremely fragile, for instance drag-and-drop tests needed to literally control the mouse, so no mutli-tasking for developers while tests executed. Regardless of these set-backs, the value of immediate test feedback is too great for any team to justify scrapping them.

I admit that working with a Swing team that was relatively inexperienced compared to the Web teams I’ve worked with has significantly influenced my thoughts. Still, Swing is screaming for simplification. I understand that Mustang will re-write/enhance some of Swing. I particularly applaud the decision to Improve Swings drag-and-drop Support. Great - it’s all much needed, but don’t stop there. In the short term, Swing is crying out for some simplifying frameworks, just as Web Apps were 5 years ago.