This quick entry announces that we've started work on JSF 2.1 in earnest.
Soon after Oracle acquired Sun, Blake Sullivan and Andy Schwartz, Oracle UI Technologies Architectects from the ADF Faces team, donated a significant patch of performance enhancement work to the Mojarra project. This work initially went into JSF 1.2 and will be in the upcoming Mojarra 1.2_15 release. I have recently completed integrating it into the HEAD branch of Mojarra for JSF 2.1. The easiest way to try it out is to grab a GlassFish 3.1 nightly build from 14 July or later.
If you're interested in the specific fixes, this java.net query shows them up.
The original Pragmatic Programmers, Andy Hunt and Dave Thomas, talk about the tragedy of the software ghetto in this 2003 interview with Bill Venners. We all know the story of how unfixed broken windows can cause a nice neighborhood to start looking like a ghetto, and how this analogy is applied to an enterprise software project. While working through my email today, I came across a management pitfall: Agressive Scheduling + Lean Team = Software Ghetto. Here's the story.
My current lean team is dealing with a steady influx of bugs/issues found in the source code, while at the same time having to conform to an agressive schedule with very clearly defined priorities. If an issue doesn't fit within the priorities for the schedule, it's put on the bottom of the list.
As one of the responsible engineers for Oracle's JSF implementation, Mojarra, I have committed to review and evaluate new issues on the issue tracker as quickly as possible after they come in. I try to do this as part of my email reading process. Today's issue: 1729. While using our existing automated test harness to try to reproduce the bug, I made an XML authoring error, but it took a while to diagnose because I found another bug that was masking the exception. The right thing to do would be to file an issue on this other bug and move on. However, our current agressive schedule and lean team would dictate that this issue would certainly not be addressed this calendar year, and would likely never make the cut because such little issues are never high priority enough to be judged important when crafting an agressive schedule. So, I decided to fix the exception masking issue now. Did I make the right choice?
According to the management school of laser focus, schedule at all costs, probably not. According to the school of quality and ghetto avoidance, probably yes. I assert that projects that have agressive schedules with clearly defined priorities combined with a lean team to meet that schedule will tendto generate software ghettos. What do you think? Did I make the right choice?