I had worked on a Struts web application a couple of years ago, and within our team I am still considered the “expert” on that application. So yesterday, when something wasn’t working correctly, a teammate approached me and asked for help.

As I walked her through what was going on, I made it a point NOT to rely on any knowledge of the application (after all, it has been two years and several maintenance programmers since I have worked on the application.) Here’s what we did:

• Based on the URL, track down the action mapping
• Look in the struts-config.xml file and find the JSP that is rendered
• Examine the JSP and see where the data is coming from; identify the form object that holds the data
• Back in struts-config.xml, find the action that does the work
• In the action, look at how the form is populated

In finding and resolving the problem, I didn’t have to use any tacit knowledge of application. Instead, we just ran the application, identified the problem, and tracked it back to the code that was causing the problem.

In Java, we often see code that compares a particular value to some know constant. Often this is written like this:

someObject.getSomeValue().equals("SomeConstant");

This works ok, assuming that someObject is not null, and as long as you are sure that getSomeValue() will never be null.

If you aren’t so sure, or if you just want to develop a good habits that will minimize the number of NullPointerExceptions you run into, you may try to write the same comparison this way:

"SomeConstant".equals(someObject.getSomeValue());

You are ensuring that you will not run into the dreaded java.lang.NullPointerException, because your constant value will never be null. And you are improving your own productivity, because you and your teammates will spend less time tracking down and fixing NullPointerExceptions.

When I hear about Ruby, the first thought that comes to mind is Ruby on Rails and Web 2.0 applications. I would have never made the association from Ruby to desktop application. Until now. About a year ago, it was suggested that JRuby and SWT might be a viable combination for Ruby on the desktop. After all, SWT is the performant, native desktop library available from Eclipse, and Ruby gives you many productivity advantages. There was even a SWeeTgui project at the time, though it doesn’t seem like there was much traction.

Fast-forward one year, and we now have Glimmer: “a JRuby DSL that enables easy and efficient authoring of user-interfaces”. What advantages are there with Glimmer? Here’s what I see:

• A compact api that allows Ruby developers to write native destop applications
• A clean wrapper around the SWT libraries, that takes a minimalist approach by exposing the most important features and applying smart defaults everywhere
• An API that is based on Ruby’s programming paradigms, not Java’s.
• The ability to implement complex SWT desktop applications with only 25% of the code.

That last point is what brought me over. Being able to write the same functionality with just a quarter of the code (and time). I’ve been developing Java applications for nearly a decade now, and using SWT for two years, and I feel very comfortable. .

When I first saw Glimmer, I didn’t believe that I needed it for my Java SWT applications, because I know Java, and I know SWT. But as we discussed the merits of this API, and I saw a demonstration of some complicated user interfaces, I got a “glimmer” in my eye. I could see alot of productivity benefits here.

Take a look for yourself, and consider it for your next desktop project.

I’m currently working on a project that is using an agile process to manage development. We use most of the XP practices, but are mising what I would consider the most important one: an onsite customer. Though our customer is a manager, and the final decision-maker, she doesn’t participate directly in the daily development activities. Instead, she sends a proxy.

This works out great about 75% of the time, but doesn’t work so well the other 25%, when we need a tough question answered quickly. And that often introduces some long waiting. Here are a couple of examples.

Last Friday, the manager had her proxy call a meeting with the developers to discuss a featuer we had just completed. She wanted to improve the flow of the feature, and make sure that it was as easy as possible for the users. We got together with the proxy, brainstormed, offered ideas and estimated the different steps. He then went back to her, she had some other ideas, and some questions. So he came back to us and …..

All this going back and forth was costing precious time. We are still answering questions and going over ideas, though we never really meet with our customer. There are several problems with this approach. Information is lost, intent is misunderstood with each link in the chain, and delays are introduced. And this happens both ways. The proxy is an intelligent guy, but all the intelligence in the world doesn’t help here. Its the nature of communication, similar to the game we played in grade school, where we each whispered something to the next person, and what came out of the chain is not what went in. Extra energy is expended going back and forth. It would be much more convenient, and direct, to be talking directly to the decision-maker.

Contrast this to what happened yesterday. We were discussing a feature that the developers thought must be included, but the manager thought wasn’t necessary. Of course, she sent the proxy to discuss this with us. However, we didn’t feel she had a strong argument, and she didn’t think we had a strong argument. By chance, one of our teammates saw her walking by, and we asked her to explain her point. Then we explained our. We were quickly able to come up with some options that would meet her requirements and our own. I walked out of this meeting energized and excited about our application. We were going to deliver a valuable feature that met the needs of our users, and our developers, and we were able to get to that point very quickly.

All modern books preach the need for an onsite customer. This experience of two extremes solidified the idea in my mind. Your team can definitely work more effectively with an onsite customer. Not a proxy, nor a proxy to the proxy, but the real decision-maker, in the trenches with your team, day in and day out.

Yesterday, a colleague sent out an email to the group, asking for help on a certain topic. Over IM, I asked if he was doing this for a particular scenario, which he was. So I suggested he use a feature of the tool we are using. He said he wasn’t aware of that feature, so I said “RTFM” (read the frickin’ manual).

This didn’t go over very well with him. His first reaction was to lecture me, never to do something like this again. I didn’t need a lecture, but I apologized, trying to quell an escalating situation. Later, after he calmed down, he explained that this triggered memories of bad relationships with past colleagues, and that he didn’t want our rapport to get out of hand. Fine, I can accept that. But this situation got me to thinking about two things: why I said RTFM to begin with, and how I could have said the same thing in a more gentle manner.

As a consultant, I know alot is expected of me by the client. There is a reason they are paying more for my services than they pay their employees, and I have an obligation to keep up my end of the deal. I expect the same of the other consultants on the project. In this case, I expected my colleague to know the tools that we are working with, and to have at least gone through the manuals and have been familiar with the concepts. Staff employees often expect to be sent to training. As consultants, we need to go out of our way to quickly learn as much as we can about the tools and technologies we are using. We also need to be able to pass that knowledge on to our teammates, whether they are consultants or employees. It’s by this transfer of knowledge that the entire team gets better, and the entire project can go smoother.

Which brings me to my next thought: how could I have been more effective in that communication. After thinking about it, I should have said something along these lines:

You can use this feature. You should be able to find information about this in the manual. Take a look, and let me know if you have any questions.

It would have gotten the point across much better. It also would have been in line with the kind of response my colleague expected. Even though I don’t have any particular title, I am often perceived as a leader on our team. To fulfill my part of being a leader, I should have used the gentler statement to get my point across.

The work we do executing projects and developing software is difficult enough. We don’t need to make it any more difficult by creating problems among our colleagues. As a team leader, whether by title or by perception, we need to excel at increasing the knowledge of our entire team (and organization), and working towards project success.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.