Well put Howard! I've bookmarked this post in the case I meet a PHB...
Olle 2009/6/17 Howard <hls...@gmail.com> > 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 -- Olle Hallin Senior Java Developer and Architect olle.hal...@crisp.se www.crisp.se
