I recently had an e-mail exchange with a Tapestry user; after
congratulating me on creating Tapestry, he went on with the following
observation on his organization: The company I work at unfortunately
chose JSF for their big app. The reason was that Tapestry was
"brittle"
in the sense that, if one developer breaks something, on a page or a
service, very often the whole site won't come up because the initial
registry startup will fail. Or for example, if page A has a pagelink
to
page B, and page B is broken, then page A won't render. While I agree
that we shouldn't ship unless the whole app is working, this is a
thousands of pages big app with hundreds of mediocre (as in likely to
break things) developers. They'd rather have 80% of the thing working
than nothing at all. I never thought of this for my own projects, and
haven't had the time to examine the truth of their claims. What's your
take?
I provided the following response:
Early failures are absolutely, 100%, the only path towards code
quality. You may have heard the phrase "no broken windows" (see "The
Tipping Point" by Malcom Gladwell for more details) but the short form
is that when errors go uncorrected (whether they are broken windows in
an abandoned building, or broken code in an application) they tend to
multiply quite rapidly.
The things that will "break" a link from page A to page B are
substantial problems such as invalid templates, references to unknown
properties or components, or compile errors in the page B class ...
things that no other developer should ever see when page B's developer
is working and checking in code. That is, problems that should never
be
checked into trunk, but instead kept in a local workspace or a private
branch.
An organization that thinks that fail early is a problem is an
organization that isn't prepared to develop a large application in any
technology. The image I'm getting is one where there is no build
server, no continuous integration, at best CVS for source code
management (or possibly one of those "shared directory"
monstrosities) .... i.e., a chaotic environment where errors are
allowed to be checked in to the trunk and can go unnoticed for some
time.
The solution to coding errors in pages or components is not to wait
until your testers (or end users) find the bugs, but to identify and
fix the bugs early. That's called "engineering discipline" and the
reality is that even self-professed "mediocre" developers can do it.
Tapestry helps because it fails early and has great exception
reporting
to guide you right the problem so that you can fix it.
Another factor here is enforced helplessness. If only Fred understands
page B and he's out when it's broken, then all development stops
waiting for Fred to get back. I hit this problem myself, years ago
working on a large Struts application (those words give me the heebie
jeebies now!). We had lots of code, a fragile and slow build process,
and many little code "fiefdoms". I spent too much wasted time
twiddling
my thumbs.
Nobody should "own the code"; if page B is is broken, Julie (who
normally develops page A) should be free to fix it. Julie will need to
understand the page B code well enough to fix it, but also you need an
overall environment with shared source, no repository locks (that is,
nothing that says "Only Fred can change this file"), and no management
PHB's getting in the way. Pair programming is the best way for Fred
and
Julie to share knowledge so that they can understand each other's
code.
Even if pairing occurs only part time, it's very effective at
knowledge
transfer as well as ordinary coding.
The idea that "mediocre" developers should use JSF as it is more
tolerant of errors is absurd! Tapestry 5 is designed to improve
productivity for all developers, by streamlining, simplifying, being
smart and being concise ... not to mention live class reloading and
best-of-breed exception reporting, which makes it fast to identify and
fix those errors.
If your doctor tells you to eat less red meat, that doesn't mean you
should switch to a diet of fried chicken three meals a day! Likewise,
if you have concerns with code quality from your developers, you
should
not switch to a less agile, more code-intensive, less supportive
development model and hope to catch all the bugs in QA. Sweeping
problems under the rug is never a winning strategy.
Coming down off my soap box, I should also add that Tapestry 5.1 works
a little bit differently than 5.0 in this respect, so it does (in
fact)
defer more of the page loading and validation until a link is actually
clicked. This is more for performance reasons than to shield
developers
from application problems. Even in 5.0, the loading and validation was
the "reach" from page A to pages explicitly referenced (usually via
PageLink during the rendering of page A), so it's a highly unlikely
case that a single error in a 1000 page application will keep the
application from starting up, unless the start page of the application
links to all 999 other pages.
Re-reading the above post I can't emphasize enough: you can't ignore
quality problems. Quality problems lead to development failures,
schedule slips, missing functionality, low morale and high turnover.
Saying "we don't have time to fix the quality problem first" is to
ignore the the second law of Thermodynamics. You are expecting a
miracle, literally writing it into your project plan.
Formos addresses this issue two ways: First, we use Scrum and deliver
on (typically) 4 week cycles. Thus we set real deadlines and have a
constant check on quality (we're providing working code constantly).
We
don't even try to predict what we'll be doing six months or two years
from now, we just deliver a steady, manageable stream of software.
Secondly, Formos uses Tapestry because of all the reasons that the
anonymous developer's organization rejected it, and for many, many
more
reasons besides.
--
Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
