JSPs are the ultimate contradiction to Java reusability, there is simply no mechanism in J2EE which allows even an honest man to reuse a JSP. If you’re thinking of <jsp:include>, you’re missing the larger point of reuse - reuse as in other components of the application or even different applications. Of course being confined to a Servlet container kills off any chance of reuse in the SE world along with making testing so hard that you’re forced to mock an application server just to see what’s rendered. The direct binding to a Servlet is also something that never amused me nor did I find the behind the scenes conversion from JSP to Java to Class file ever a needed exercise. Why bother with an extra compilation stage when you’re already serving your page from a compiled Servlet?

Be advised that if you’re still considering using JSPs as the V part in MVC for even a mid-sized application, you’re making a mistake. This is especially true if you’re using JSPs as purely a view mechanism (no actual code in the pages but just taglibs) since you’re not even taking “advantage” of the ability to write Java code in them. If you are one of those folks who thinks the library wasn’t the ultimate example of bad ideas, you might actually still be using scriptlets in your pages and passing them off as acceptable software. You, you just keep doing what you’re doing, there’s no help for you.

Not too long ago a colleague of mine stumbled upon a major bank website (TD Canada Trust) who had managed to seriously screw up their application server configuration and ended up serving the raw JSP page instead of actually executing the code in it. Needless to say the code looked like crap with request.getParameter() being used more often than white space to compute user states in a banking application. It was one of those “this page can do a lot of stuff so I’ll just write a lot of ifs to figure stuff out” type things. What I’m trying to say is that JSPs promote shoving control logic in your pages no matter who you are simply because it’s so easy to fall into the pitfall that are scriptlets. It’s best to eliminate the temptation and use a dumb templating tool to render your views because let’s face it, they’re views!

What to use if not JSPs? Plenty of choices including Velocity, Jamon, Freemarker, StringTemplate, JByte etc. All good options with Freemarker being my favorite because of it’s lightweight nature, templating prowess and out-of-the-box support for Taglibs. Whether you’re templating a simple email to be sent out or a full-fledged page, the concept remains the same. Add in very easy Struts 2 integration for both Velocity and Freemarker and there’s little reason to rely on JSPs to do anything.

I used Selenium as a functional testing tool and realized that I was falling into the pitfall of checking the content displayed on the page to test whether the correct business logic was being performed rather than whether the correct view was being returned (think about it, there’s a difference). If you use a templating engine other than JSP, you can quite easily test the former without having to resorting to a functional testing tool.

As AJAX is becoming more and more popular, JSPs are getting further phased out. Lot of developers prefer to return chunks of HTML from the server rather than an actual dispatched forward. A lightweight and powerful template language is much more suitable here as your AJAX interface view will be an aggregation of snippets of HTML returned from the server. Doing this using JSPs would add a level of complexity that is both undesired and unneeded.

Having said all that, you can produce the same product with both JSPs and other lightweight template engines, but the latter stay much truer to the MVC philosophy and result in a much cleaner code base.

Most of the speeches were tin-canned and delivered a thousand times before but if you've never heard it, its new to you, right? That's the optimist in me talking. There were some talks which could cure insomnia (Nati Shalom) while others entertained and informed (Brian Goetz - Java Performance Myths), but most fell into the category of "Here's a product X, it does A and B and it's good for people who are doing C". Maybe I'm being naive and not critical enough but at least that's what I got out of the talks.

Does all this AJAX stuff really belong at a conference dedicated to the "server side". Prototype and GWT? No matter how you swing it, it's still simple old JavaScript. I can see this being a topic at JavaOne where there's plenty of sessions to fill out but at a specialized conference like this one, it seemed out of place. I know a lot of developers are making the crawl over to the client side but to me these were sessions where the knowledge gained could've been done so using Google searches.

This was a smaller conference without any security guards armed with guns at the doors so technically anybody staying at The Venetian could get in (and some did thanks to Tech Target - lazy SOBs). All the sessions I went to had plenty of room to sit or move up and almost all the sessions went without an AV hitch (Ross Mason's Mule2 and Chet Haase's Rich Client one being the exceptions). Most of the talks were focused and concise and although the aforementioned fluff reared its ugly head often, it was in most cases, quickly put down in favor of practical speech.

The keynote speaker simply sucked, maybe I was expecting too much of Eric Gamma but the guy kept droning on about Jazz and how great the Eclipse team is. Didn't really feel the vibe man. After that on Wednesday morning, my expectations were pretty low but things got progressively better over the day thanks to some Spring2, OSGi, ESB and AOP talks. I think I also felt a lot better after Mark Richards told me that I'm not an idiot for not really knowing what an ESB really is or whether I need it. This was probably the best ESB talk that I went to. It's good to see a speaker who wants to make a singular point and dedicate his entire talk to it by guiding you through what went in his mind as he reached his conclusions.

I stepped up to the Google desk in the vendor area and asked some Googly guy what he was doing for his side project, for those in the dark Google has a policy of allowing employees to work on side projects for 20% of their paid time. It turns out he was wasting it by thinking about it for the past four months. I get a sick feeling every time I meet a Google employee. Can't really explain it. I think it might even be jealousy. My colleague still isn't over the fact that the Google supplied computers in the "Cyber Cafe" were missing J2REs.

The GigaSpaces logo was about as abundant as Gordie Brown posters, even penetrating a few talks through their new Interface21 partnership. Spring2's endorsement of SBA includes declarative XML and annotation support for the architecture, making the product-pitch much easier for GigaSpaces.

One of the regrets I have is forgetting to attend the cocktail party on Wednesday night, if anybody did go to it, do let me know how it went. Since I've already attended the one conference that I get allotted a year, I can't go to JavaOne which is a shame. If anybody's feeling charitable enough to fly me out, be so kind to do so. Great to meet a fellow Arsenal fan at the conference. Go Gunners.

If anybody cares, my reviews of the sessions are posted here:

• Part 1 - Eric Gamma, how could you?


• Part 2 - Spring2 + = cool; ESBs exposed; OSGi love


• Part 3 - Rich GWT Clients using SBA


• Best Session - Java Performance Myths by Brian Goetz

JavaOne is too big: It's f***ing huge! There's like 10,000 people there and although you might argue that the size of people attending is proportional to the quality of the presentations, you're wrong. I did attend a couple nice sessions last year but there were more than a few crappy ones (Spring Web Flow, Composite Applications etc.) which tells me (keeping proportions in mind) that there are many crappy ones. The rooms are huge which takes away from the learning environment that it should be; it feels like a first year chemistry class rather than a conference where you're supposed to quickly pick up stuff while having some fun at the same time.

The Commercialism: Everyone's trying to sell you something and as soon as you tell them you don't have any purchasing power in your company, they throw sharp pointed objects at you. I talked to the guy from Terracotta last year for about 15 minutes asking him all kinds of questions and at the end he asked me what I did at my company and when I said I was a measly developer, he gave me one of those I-can't-believe-I-wasted-20-f***ing-minutes-on-this-guy look.

Bad Food: Just horrible and awful. I was scared to touch it, let alone eat it. But when I finally mustered up the courage to eat it, I regretted it after two bites. I threw the sandwich away and gave my warm soda to what appeared to be a homeless developer.

Repetition: There were around four different sessions on Java Persistence API which covered the same subject matter. I made the mistake of attending two of them only to realize they're talking about the exact same thing, they just labeled the sessions differently just so everybody on the expert group had their crack at impressing the bored audience how they copied Hibernate.

Bad Party: Any party where the ratio of men to women is 6:1 is never going to be good but you can make up for it by actually providing accessible food and drink. When you shove 10,000 people in one big room and setup 4 stations where you can get drinks and food from, your appetite will force you to exit the premises and the lack of women will only motivate you to do so quickly. I scampered off to the Marriot nearby and admired San Francisco from towering heights. Also, chugging T-Shirts out of a cannon is not entertainment.

Long lines at sessions: Again, the size issue. The Gestapo regime that is the event staff forces you to lineup before every session and swipe your conference card. The lineups are long and painful and if you're in the line, you'll often here more than a few people muttering "I don't believe this shit". Don't believe me? Ask anyone who attended last year.

Spam after you come back: Here's a tip to anyone attending this year, give a fake phone and email address in your JavaOne registration form. You'll thank me as you're laughing at your friends for having to deal with daily spam and intruding phone calls imploring you to buy some product from Quest Software and pay for training courses from Sun. These people have a knack of bothering you during lunch hour which is a double whammy. Every moment you're in the pavilion, somebody's begging to swipe your conference card like they were get paid by the swipe. They probably are.

No Networking Opportunities: Aside from the BOF's which you may or may not be interested in, there are really no parties or events that will allow you to network with other people. Given how most IT folks are socially inward and scared of light, the task of networking at JavaOne is a little tough. The best time I had last year was at the Geronimo party, although I've never even used Geronimo, I sure enjoyed the free food and drinks provided by IBM etc. Side note: Again, aside from the waitresses, no women at this party either. I actually exchanged a few business cards with some fine folk; more of these events would only help JavaOne.

Now I've never been to TSS Java Symposium before but from what I can gather from the session descriptions, they seem to cater more to my line of work: enterprise development. I read some horror stories about TSS last year but it's time I take a look and judge for myself.

Since I write about other stuff besides just Java, I primarily use a wordpress blog: arsenalist.com. I'll be talking and reviewing the sessions at TSS Java Symposium over there. If anybody cares.

Don't take my word for it, just ask anybody and everybody who's ever converted a project larger than 30 source files from Ant to Maven. God forbid if you're dealing with XDoclet and generated files, if that is the case, then you'll need enough Valium to last you a mvn deploy and no you can't use -Dmaven.test.skip=true. Let's keep the attempts at humor on the side and talk about what really plagues Maven. You, you right there who’s reading this and thinking, Has this guy lost his mind? Maven is the greatest thing since the wheel and I've never run into any problems with it so it must be great. You my friend have obviously never worked with a multi-module project or mastered the maven-release-plugin which was originally designed to keep ADD patients occupied for months on end.

Let's look at the good first:

Maven does all the dirty work for you. Given a set of Java source code, it will take you no longer than two minutes to set up a Maven directory structure (using the archetype plugin), compile your sources and jar them up. Given a set of Java sources, web.xml, and other web resources, it will take you no longer than two minutes to create a fully functional war ready to be deployed. If you have any test classes, it will even run them for you without you even having to write a single line of XML.

As you can see the convention over configuration thingy does make sense. To accomplish the above tasks, you would be required to write a verbose Ant script but with Maven you have to write almost nothing. Note to Maven virgins: Maven by default assumes your source classes are in src/main/java, test classes in src/test/java, and web resources in src/main/webapp. It also assumes you have the ability to find a grain of salt on the beach when it comes to the mailing list but more on that later.

Continuing with the good, Maven's greatest feature (and it is a HUGE feature) is dependency management which it does a fine job of. No more downloading xfire-1.2.zip, unzipping it and adding it to your classpath. Almost everything is on ibiblio and you can download it from there using a reference in your pom. If something is not on ibiblio or if you’re dependent on a home grown artifact, Maven allows you to install the artifact in your local or remote repository with minimal bruises. Your application can literally be built from scratch by using a single call to mvn package.

Let's now look at the good and bad:

The first thing to do when working with Maven is to get the bleeding edge version (2.0.x) which has as many fixes as possible and then read Mergere Inc.'s book. Same goes for any plugins that you'd use. One of the better things about Maven is that it's very easy to develop plugins to fit your need; this of course might also explain why all the plugins have bugs in them.

maven-antrun-plugin

What this plugin is saying is this: We know Maven has problems and it can't do everything but we want to say that it can do everything so here's a blanket piece of code which covers all cases, granted with piss poor quality.

The maven-antrun-plugin for those of you who've never had to use it allows one to write Ant scripts inside a pom.xml, allbeit with strait-jacket type restrictions. If you plan on doing a medium sized Maven migration, be sure to familiarize with the evils of this plugin:

1. It does not pass Maven properties to the Ant script unless you specifically redefine each property inside the Ant script, thus defeating the whole purpose.
2. There is no way of passing Ant properties to Maven.
3. It magically runs twice if a parent pom also has a maven-antrun-plugin defined, an entirely possible scenario.
4. It does not allow for macrodefs to be called.
5. It has class loading issues if you plan to use Ant optional tasks.
6. It ideally should be used as a last ditch effort to perform tasks but has become a primary means of building with Maven.

So although the antrun plugin is powerful, it is a direct contradiction to Maven's philosophy of convention over writing-big-ass-scripts-to-do-build-tasks.

Plugins in General:

The power of Maven lies in its plugins. If there is a task that needs to be performed, say compilation, it's handled by the maven-compile-plugin; if you need to run tests, the maven-surefire-plugin; if you need to filter files, the maven-resources-plugin; you need to precompile JSP's, the jspc-maven-plugin. You get the idea.

The problem is that so many of the plugins hosted at Codehaus or Apache have bugs and "features" that will keep you up for nights wondering if you'll ever get to resume your FIFA game. Allow me to point out a couple brisk examples for the unbelieving audience:

1. Plugins getting executed in no particular order: Not really a specific plugin issue but more of a general one. If you have multiple executions for a plugin bound to the same stage, they execute in, get this, RANDOM ORDER. Instead of caring for our sleep and executing them in the order they were defined, which would make too much sense, the Maven developers have decided to throw a curveball our way. This will make you wish there was another phase between process-classes and test-compile, guaranteed.
2. maven-resources-plugin: Treats even built-in property values as verbatim. ${project.build.directory} will not be evaluated to "target" which it should be but to ${project.build.directory}. This can drive you insane if you're filtering for different environments.
3. maven-surefire-plugin: Despite pleas by the general public to add a configuration parameter for having an additionalClasspathElements, the surefire plugin is committed to pissing people of by forcing them to have a custom version which they will need to patch and deploy to their local repository.
4. maven-release-plugin: If anybody has got this working with a hierarchical project, please let me know.

The maven-idea-plugin, or sorry, the idea-maven-plugin was a pleasant surprise. Yes, the name matters. If you start your plugin name using "maven-", you better be part of the Apache group or they nuke your PC. Back to the plugin: Type in mvn idea:idea and you have a bunch of IntelliJ files which get you fairly close to compilation as long as you're doing nothing fancy. Unfortunately, if you're doing anything remotely complicated like generating source files or resources, you'll have to fiddle with the settings (classpath, source tree, XML files etc) to get it to do anything. All in all, it was a decent find.

When well written like the jspc-maven-plugin, life is good. If written like the Cargo Maven plugin, it lulls you into a false sense of security, shoots you and then gnaws your head off while you’re sleeping on your keyboard. Chances are that if you're going to decide to use a plugin beyond the most basic case, you will end up looking in its source code to figure out what the hell its doing. That's probably why every plugin has a convenient link to the source repository. What better documentation!

Generated Files:

If you're using XDoclet, you fall into two categories of people: Those that have fixed a bug in XDoclet and are using a custom version and those who haven't contracted rabies from a careless XDoclet developer error. If you fall into the latter group, you can go ahead and use the maven-xdoclet-plugin and see how far it gets you. However, if you fall into the former category, what lies ahead is the unenviable task of copying all the stuff you did in your build file over to your Maven POM and in to the antrun plugin. The other thing you can do is to force the xdoclet-plugin to use your custom version of XDoclet rather than getting it via its defined dependencies. Good luck going down that road.

Maven completely missed the boat on generated sources. Since all the source code is supposed to be in src/main/java, one is forced to do one of two things, both not very glamorous:

1. You could dump them in src/main/java in the generate-sources phase and delete them in some subsequent phase after compile. Stinks of bad programming and will probably get you fired.
2. Create a gen directory in target or as Maven likes to call it ${project.build.directory} and then use the build-helper-maven-plugin's add-source goal which will add another 25 lines to your pom.xml, making you nostalgic about Ant. Side note: is it just me or is ${project.build.directory} excessively long an alias for the word "target". Same for target/classes which the Maven folks happily defined as ${project.build.outputDirectory}. How nice and compact.

I hope you're a religious man if you're generating a web.xml or a struts-config.xml because the only way you'll ever get them in the WEB-INF folder is through prayer. Although the following misuse of the maven-resources-plugin would work too:

<resources>
   <resource>
      <directory>src/main/resources</directory>
   </resource>
   <resource>
      <directory>target/gen/web-resources/WEB-INF/</directory>
      <filtering>true</filtering>
      <targetPath>../wardir-cant-use-property-here-due-to-bug/WEB-INF</targetPath>
   </resource>
<resources>

See, if you want to copy over a resource other than the default one, you have to redefine the default resource (the first resource element). The second resource element's targetPath assumes the default location of target/classes which makes the value of targetPath rather confusing to the untrained eye.

Maven should seriously consider having a target/gen/src/main/java etc structure to combat generated files since this is a situation faced by most medium to large projects.

Again, there is a solution but it’s not pretty.

Profiles:

Remember the good old day of AntContrib's if/else statement? How simple? If or else. Two options, pick one of them. Well in the ultimate example of killing a bird with a cannon, in order for one to execute an if/else statement in Maven, you must write a profile which stores the plugins that execute on the true condition. If you want something else to happen in the false condition, write another profile. Sounds overkill? It is. Well, you could always use the maven-antrun-plugin but that won't get you far since you can't call Maven code from Ant code and you'll be forced to do everything with Ant once you go down that road.

Having said that, profiles do allow executions to run in different conditions. For example, if you only want your JSP's only to be precompiled when you're deploying to production, you would define the jspc-maven-plugin in a profile with an id of "precompile-jsps" and it'll only get executed if you activate it, for .e.g.: mvn -P precompile-jsps deploy. But say if you want to copy a file into either dir1 or dir2 based on ${prop1}, whip out the antrun plugin.

Class Loading

Justifiably Maven's class loading mechanism is complex, especially when it comes to multi-module hierarchical projects. They do have the decency to provide you with different classpath's which are built from the dependencies specified in the POM. Although this is very convenient, you just never know when you need to specify a weird property out of the blue.

Mailing List

Exhibit A, The Maven Users Forum. Where the users providing help are as confused as the poor bastards asking for it. For every query typed into the search box, six different "solutions" pop back all claiming to work but rarely ever doing so because you have something sliiiighhtly different somewhere. These posts usually have a link to a JIRA of some sort which may or may not be related to the actual problem. What I'm trying to ramble through is that the mailing list has tons of useful information in there but you have to be careful for what you accept as a solution as it's pretty easy to get lost.

Let's take a look at the bad:

Properties:

This bothered me to no end and I ended up writing properties-maven-plugin which still hasn’t been accepted despite many users supporting the feature. The feature in question is loading various project properties from property files. It only make sense but this essential piece of the puzzle in any application is mysteriously missing from Maven. For example, I want to load a different property file for production versus for development. Is that too much to ask? What Maven wants you to do is to define two profiles with their own set of properties and activate one of those profiles during the build (and hope that the profile properties override the project properties which they don’t). This makes the POM unnecessarily huge since defining properties in XML is a bitch:

What would be this:

myprop1=myvar1
myprop2=myvar2

becomes this:

<properties>
<myprop1>myvar1</myprop1>
<myprop2>myvar2</myprop2>
</properties>

Note you have to do this each time for every environment in your POM. Those of us coming from Ant can’t get a handle on this. There needs to be a replacement for <property file="build.properties"/> in Maven. Don’t even think of using the maven-antrun-plugin to do that.

Oh, by the way, the ${line.separator} property is broken in Maven and if you try printing it out, you'll only be disappointed.

Multi-Module compilation:

Be very careful in a multi module project. If you’re doing a mvn compile, it will look at your sources in all POM’s that have a version number ending with the word SNAPSHOT, however, if you’re doing a mvn package, Maven decides to ignore your checked out sources but instead looks in the local repository for a snapshot jar. To avoid any possibility of compiling against older source, it’s best to do a mvn install for the module that’s serving as a dependency before doing a mvn package for the main module. Remember this and you’ll never find yourself doing an mvn package for hours without figuring out why your changes aren’t showing up.

Maven’s whole deal of treating –SNAPSHOT versions differently is bound to cost anybody a few hours of headache but once you’re past the initial growing pains of somebody shoving a philosophy down your throat, you’re bound to like it.

So in closing: Maven has been a complete pain to work with but it has pleasantly surprised me at how integrated my build has become and how source code from multiple modules is combined together to produce multiple artifacts. Something Ant just couldn’t do.

So hard have I worked to come up with a word at least eight characters long, containing a digit, an uppercase letter, a symbol and one that I won't forget and you have to ruin it all by sending it to me in clear text over email? Especially even when the password-o-meter told me I had chosen a great password. Why, I ask, Why?

The first thing that comes to mind is that this sacred phrase is most likely stored in a cheap MySQL database without being md5'd. This alone is enough to warrant public execution but I'll let this pass as we live in times where acts of such vileness are tolerated. Who has access to my sacred word? Well, in this case it's the JIRA admin. I know he's (she's?) sitting there on those lonely nights just going through the list of the poor souls he has seduced into supplying him with the key to their lives. I've also been naive (stupid?) enough to supply the same password I use as for my email, youtube, home computer and most importantly bank. Yes, it is my fault, I have shown too much faith in common technology courtesy and will be punished for it by the JIRA admin finding out all about my porn stash.

My best judgment on why these sites don't encrypt passwords is because a) they're lazy, b) they don't know how, c) they want the user to have a copy of the password in case they supplied a really made-up one and will forget it instantly. Let’s give them the benefit of the doubt and say its c). Even in this case you HAVE to encrypt the damn password for database storage or at least ask the user on the sign up form whether they'd like their password mailed to them in clear text or not.

Listen, I don't have much going on in life and by no means will the person who knows my bank password be at a great advantage but it's still absolutely wrong to a) store such info in clear text for anyone with database access to see and b) to send it in an email which can be easily compromised. I've never been a JIRA admin so I'm not too sure if there's an option to use encryption or not but I'd be shocked if there weren't considering one has to open their wallet to use it.

So for next time let us all agree to be careful with passwords for the sake of internet privacy:

For every piece of information that you want to pass from the JSP page to the SiteMesh decorator, create a <content> tag. In the following example, I want to pass in two pieces of data, a "page name" and a "site section". So I must declare two content tags in the JSP page:

<content tag="pageName">
    Login Page
</content>
<content tag="siteSection">
    Administration
</content>

Now, all thats left is telling the SiteMesh decorator to access this information, and that is very easily done using the following syntax in the decorator:

<decorator:getProperty property="page.pageName"/>
<decorator:getProperty property="page.siteSection"/>

That's it. Now you can pass in anything you want and aren't restricted to using <decorator:head/>, <decorator:body/> and <decorator:title/>. My problem with these three tags is that I don't want to declare a head, title and body tag for every JSP page since the JSP page is usually the "main" content of the page and shouldn't have to declare such basic HTML elements. IMHO using <content> tags is a cleaner and more powerful solution as you can pass in an unlimited amount of data without using specific tags. However, combining the three tags mentioned with the <content> tag is also a fine strategy.

Thats when it struck me that Log4J does exactly what I want to do. It can print out the method and line number of the code for each log.debug(..) call. So of I went digging into Log4J code looking for an answer. I found it.

What Log4J ends up doing is that for each debug(..) call, it creates an instance of Throwable which takes a snapshot of the runtime stack. It then proceeds to parse the stack to yield the current line of code being executed along with class and method information.

Keep in mind that constructing stack traces is a fairly expensive operation. When an Exception is created, the JVM needs to literally pause the processing and so it can get a good glimpse of the entire runtime stack - this includes classes, methods, line numbers etc - starting from Thread.run() all the way till the creation of Throwable. From the runtime's point of view, this is acceptable since it's not designed for great Exception handling but to run as fast as possible.

However, in the logging scenario, the culprit is the call to the Throwable.fillInStackTrace() method in the Throwable constructor which gets invoked on each debug(..), info(..) and other logging calls. This is the only way to retrieve the logging information requested via the PatternLayout class. Give Log4J credit since they only create the Throwable instance when the specific PatternLayout is specified; plus they have the decency to warn you about using the l, L and other expensive options.

Although descriptive logging can provide good roll-back mechanisms in production code, the cost incurred by specifying method and line numbers when logging is simply too high. It seems like the pain of typing out the method name when logging is unavoidable.

To some, this might come as old news but to many it'll make them change their log4j.properties.

A meeting is held by all parties involved only to be cut short by 12:00 PM and the ensuing two hour lunch break. The developers are left figuring what this stack of paper is trying to say. The front page is pretty clear, "Inventory Management System" it says. On the second page there's something about Java being a requirement. There's also a due date. They start working.

Fast forward to five months later. The stack of paper has a lot of writing on it. Lines have been scribbled and crossed out. Along with bits and pieces of scribble, you'll also find pepperoni stains and some fluids which can best be ascribed to coke spills. Lots of code has been written, some of it has even been tested. The programmers are feeling fairly confident, the PM has his ass covered, anything goes wrong, and he’s ready to play the blame game.

Guess what? Something does go wrong. Seriously wrong. Turns out something works the way it's not supposed to work. "No Problem" says the PM and says he can have it fixed by end-of-day. The developer is told of the "problem" and the expected fix date. The look on his face is priceless: "That's not a problem, I've made it that way just like you said", he pleads pointing at the greasy stack of paper. They both consult the stack, sure enough, he's right. He's done what he was asked to do.

The PM frowns, goes away, comes back half an hour later and says, "You've misunderstood the document, this is what it really means". The developer listens, frowns, frowns some more, consults the other developers who all frown. An hour later, they reach the agreement that the wording can mean more than one thing depending on the time of day and the salary you're making.

The PM has found somebody to blame.

********************

It's incidents like these that motivated me to go back to class and take a couple Project Management courses via pmi.org. I'm almost through with the courses and have so far learnt that Project Management is simply common sense wrapped around acronyms, document formats and jargon. It really does sound very simple and sometimes quite bloated. Hey, did you know if you have 10 people on your project you have 45 communication channels? How did I arrive at that number? Why I simply applied the formula n(n-1)/2. That’s 45 different conversations between two people and thus a lot of room for miscommunication.

See what I mean? Someone wise once said, "common sense is not common". I agree.

More on the conclusion of this course.