I have been struggling with this lately, and Jeff Attwood sums it up really well

But some commenters were understandably apprehensive about the idea of having a Senior Drill Instructor Gunnery Sergeant Hartman on their team, enforcing engineering discipline.

You little scumbag! I’ve got your name! I’ve got your ass! You will not laugh. You will not cry. You will learn by the numbers. I will teach you.

Cajoling and berating your coworkers into compliance isn’t an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn’t to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.

Here is the thing. I fully accept this premise. The problem is one of communication. By that I mean, communicating what the engineering goals should be in a concise form, without starting out having everyone on the same page.

Let me elaborate on this a bit with a couple of personal examples. A *long* time ago, I was tech lead on a dev project. Back when XSLT was brand spanking new, we had a project come through a Professional Services company I was with. I immediately realized we needed something like this, and outlined a whole architecture for a multi-skinned/multi-host/user customized app. Most of the people on the tech team had never worked with any of the technologies before, but I wrote a couple of core classes, and gave very explicit interfaces for each of the components, worked with the “web dev/design” group on XSL and gave them sample documents. Over time the project snapped together like lego, and I was very full of myself. I still feel like this was my best experience with a large team effort, because I was able to build language-level interfaces and test cases and tell people “build this.” Over time, we could optimize later (as you should) and where appropriate, and the architecture grew into a methodology.

Lately, however, I have had a harder time. When you are building more generic frameworks, rather than for a specific app, you need to communicate a *philosophy* of app construction. The problem here is without a “look at this” example, I have not been able to communicate the ideas behind the structure and lifecycle. When you have a team that has diverse backgrounds and maybe doesn’t have the same mental shorthand based on “everyone has built the same apps, read the same blogs, read the same books”, selling, if you will, a new design philosophy is really hard.

The core rules Dennis provides are great:

Be humble. Always first presume that you’re wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you’re certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.
Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.

The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes — like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet — won’t yield the same effect, and are more easily neutralized.

Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you’re just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they’ll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn’t guarantee that the initiative will fly, and the effort might be for naught, but the team will identify that it’s actual motiviation and effort behind it, rather than an attempt at some easy points.

There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that’s the most common best-practices subject doesn’t mean that it’s even remotely the best design philosophies for the group you’re joining.

My question is: if you have a vision, and want to try something that is honestly new, how do you communicate that vision to software developers… without software?

Scott let everyone know about GWT 1.4.59 today. This is mostly a bugfix release on GWT 1.4, and there are a TON of fixes, as wells as some real improvements to the Benchmarking application.

We have been hard and heavy in GWT work in my day job, and a good number of these fixes are welcome — the super call to native method was one that freaked me out for a while. GWT 1.5 is going to track the Java 1.5 language constructs, which is really exciting.

I am going to go ahead and leak some information here on some work that is coming out of Manheim to the open source world to go along with this release: Gwittir. The intent is for this to become a Rails like framework/generator for GWT. There is a lot of code on hold for it, but the exciting thing for GWT users is our “Reflection Light” introspection API. This, of course, gives rise to all kinds of cool stuff, including our Data Binding system. We are using this for several internal projects, and the whole thing is a moving target. The Introspector and the Binding stuff is stable, though, and very usable. Watch this space for more on the Gwittir MVC patterns and Widget patterns later.

Conversations between loosely coupled services presentation by Gregor Hohpe on InfoQ. It’s an interesting presentation for people who want to learn more about what BPEL and CDL really mean.

So this post is making the rounds amongst the kids. The gist can be summed up with the graphs:

It seems to me that people building LAMP, Ruby, django, or other applications think of themselves more as building web applications with whatever technology tools they need to use: web services, cron jobs, MySQL, ruby, PHP, python, maybe some Java: whatever. What matters is getting the web application working.

People who using Java see themselves primarily as building Java applications that happen to have a “view” (as we OO head-jobs would call it) that’s the web. Our primary goal is the metaphysical and headless application, not the delivery mechanism. Hopefully you can get a sense for my view of Java culture at this point: it’s more concerned with keeping the concepts, work-flows, and design of the application pure and tidy than optimizing the delivery mechanism, or implementation. Them UML diagrams should look good.

So here is my thing, as a Java developer, I am SQUARELY in BOTH camps here. I am going to give you all my dirty little secret:

I think JSF blows chunks.

I think Seam blows chunks squared.

While I can appreciate the design ideals of component based development on the web, each of these technologies, and especially stacked, represent an abstraction above and beyond what HTTP really is that makes me sick to my stomach to think about. I will freely admit, I am a GWT bigot. Once I saw GWT at JavaOne over a year ago, I had the same gut response I had to Java itself having come from the VC++/DCOM world: this is the way we should have been doing it all along. GWT still encompasses this layer on top of native idea, but does it at the right level. GWT doesn’t pretend HTTP is smarter than it is, it just gives you a “real” and reliable client API. Moreover, you still get to run PMD and FindBugs and have good refactoring support on your code as you develop it. Win. Win. Win.

For all the humor about what “QA” loves in the linked article, I have to say “Techops loves ‘technology tools they need to use: web services, cron jobs, MySQL, ruby, PHP, python, maybe some Java: whatever. ‘” One of the things that makes JRuby and Quercus compelling is getting the WAR deployment story. A “mish mosh” application that has 40 steps to deploy to 25 web servers sucks, and it sucks worse than taking time to QA, because deployment (likely) affects the end user and not the organization.

I am not going to say Java is the End All Be All. However, I am certainly not going to poo poo the Java ethos. Granted the Java Web Dev story has not been perfect, but I will hold it up against anything else out there proudly. Moreover, I will give your circa 2002 Struts app credit for maintainability against anybody’s hand rolled PHP, Perl or whatever else App. Frankly, GWT’s unified asset deployment and deferred binding for native hacks leads me to see it as the best successor to Java in “Web 2.0″ development, but frankly anything is better than where we came from. Even RoR, which I have espoused in this space as a PHP killer over a “Java” killer, represents a step forward in maintainable code in the web tier, but only in conjunction with JRuby. The “Check out a tag from svn to all the servers” deployment method will make Techops AND QA ill, nevermind force you to do some kind of rolling load balancer hack to make it happen smoothly.

So, I have heard about this story in a couple of places, but all the coverage is lacking.

I know, for instance, The Java Posse used to make this mistake a lot and say “This is covered under *the* Creative Commons License” and not *A* Creative Commons License. The thing is, it sounds a lot to me like Flickr users who granted, say Share Alike or By-SA licenses to their photos are upset they didn’t say “Non Commercial.”

This has been one of the weaknesses of “CC Licensing” since the beginning, IMHO. The combinations make it hard for the average person to understand. The GFDL (like Wikipedia) is very clear. The many combinations of CC licenses you can selecte makes CC licensing confusing to the average shutterbug.

For insance. I say this photo:

(Congrats to Les and Fras BTW)

Is CC-By-SA. If Virgin wants to use it on a Billboard, they are welcome to, as long as my name is on the billboard and they don’t sue the Farkers who mutilate it. Something in my gut tells me these angry Flickr users simply didn’t kow what they were agreeing to when they tagged their photos with a License.

Do you know more about this story? Please tell!

Summer is flying by and as we usher in fall, we wanted to give all New Englanders a heads-up that we are having a second Ignite Boston. The second Ignite Boston will take place on Thursday, September 6, from 6 to 10pm at Hurricane O’Reillys. Yes that is right, Hurricane O’Reillys. No, it’s not Tim’s office after FOO Camp. We’ve picked a venue that is more acoustically-oriented and should allow everyone to hear what is going on. And we are planning to mix-up the format a little bit. There will be some short “launches,” followed by lightening talks, and a couple of other ideas that we will inform you of in the coming weeks. Let’s show our tech colleagues around the country that Boston/Cambridge have a vibrant tech community that gets involved in talking about cool new technologies and ideas. Not to mention that it is a social event to get to know other developers in the area.

If you plan to attend, email IgniteBoston at oreilly dot com for the chance to win $300 worth of O’Reilly books of your choosing. You must be present to win.

If you are interested in connecting with some of the folks who attended the first Ignite Boston, we have a social network set up for this purpose. You can reach our Crowdvine network here.

Another reason we wanted to announce this event this early, is so those of you who would like speak for five minutes on something cool, new, or exciting you can get into the queue sooner rather than later. Please submit your idea/s here:

Presentation Guidelines

• Be no longer than 5 minutes.
• Be on an innovative topic (no sales pitches, please!).
• Be viewable on a PC [a MacBook Pro with Powerpoint, Keynote/has remote control, and PDF] with standard AV equipment.

To submit a proposal.

For anyone that’s never been to Ignite, you may find it useful to see a talk or two. Here’s a link to a good example [but poor audio quality] from the first Ignite Boston talks.

Google Guice is a Dependency Injection Framework that can be used by Applications where Relationship/Dependency between Business Objects have to be maintained manually in the Application code. Since Guice support Java 5.0, it takes the benefit of Generics and Annotations thereby making the code type-safe. This article gives good introduction for google guice.

Eclipse is an extensible platform for building IDEs.Tool builders contribute to the Eclipse platform by wrapping their tools in pluggable components, called Eclipse plug-ins, which conform to Eclipse’s plug-in contract. The basic mechanism of extensibility in Eclipse is that new plug-ins can add new processing elements to existing plug-ins. And Eclipse provides a set of core plug-ins to bootstrap this process. This article explains the eclipse plug-in architecture.