Posted by edburns
on March 3, 2005 at 3:42 PM PST
A bit of pontification, but he knows what he's talking about.
Rod Johnson, why J2EE projects fail
I. Enterprise Development is Hard
May integrate disparate systems
Hard performance problems
B. hard to test
C. Hard to maintain
Software is never finished. Maintenance accounts for the bulk of
II. J2EE is not a panacea
High failure rate
Good technology doesn't guarantee success
Bad technology does guarantee failure
III. It is possible to succeed in J2EE
More mature app servers and tools
More mature developers.
Recounted anecdotes around impl problems a while ago.
IV. General reasons for failure
1. Poorly understood requirements
Nothing to do with J2EE
2. Ideology (come back to this)
What constituted a pure J2EE system
RDBs are evil
Java is the center of the world
J2EE is distributed, so everything is remote.
* Technology is more important than the problem
3. Lack of attention to performance
4. Bad team dynamics
Too big a team
Overworked team (reactive v. strategic modes)
V. Technical reasons
Too much code
Take small example and extrapolate when it doesn't scale
There are less excuses for technical failure
He emphasized the importance of communication, more important than
technical. The importance of working with your manager.
VII. Requirements checklist
Do we know what the application should do?
How it should do it?
Whether does it does it?
Also mentioned the importance of testing.
Establish Continuall feedback
Listen to business
No waterfall usage
J2EE is particularly ill suited to waterfall
Educate the business about the process.
VIII. Ideology part II
Lots of it is kinda receding, he thinks this recession is one of the
reason that more J2EE projects are succeeding.
IX. Lack of attention to performance
one of the key failure causes
"First get it to work, then optimize"
Use architectural approaches that allows a degree architectural
refactoring. Such as?
Loosely coupled layers (but be mindful of performance)
X. Team dynamics: the God-like architect
Politically astute, technically not.
non-coding: powerpoint, UML, (motivation: not enough), big picture
The prescriptive framework builder: obsessed with the small and big
picture. Cares about controlling every aspect of the programmer's
The myth of the code monkey: they exist to knock out code.
The framework builder believes that his main role is to prevent
developers from doing things. This is not how to develop
Successful Frameworks make best practice easy to do, but doesn't get
in the way of developers doing whatever they want.
XI. Team Dynamics: Consequences of prescriptive framework builder
Team morale plummets
XII. TD: Loss of communication
His view of the architect is that they can actually do any role on the
team. There must be mututal respect. Communication is essential to
success. He listed an example of bad communications
XIII. TD: too big a team
Scale the team up at a managable level. Do proof of concept first,
then grow the team. You have to know how to solve the problem before
you grow the team.
XIV. It's about working smart, not doing more work
Rod is interested in history
Higher up decisions are very important. You can't succeeded with bad
top down decisions.
Using frameworks allow working smarter
1. Big problems
Too much code. Too much maintenance
Why? Failure to use appropriate frameworks, insufficient refactoring.
XV. TD: overwork
people work less effectively when they are tired and stressed.
Cosmetic overwork is really dangerous. Impress the client with activity.
XVI. Re-inventing the wheel
No excuse to build an in house framework from scratch.
Start from existing generic framework
Lots of extension points (he feels extension points are key for a
People apply high bar for accepting third party frameworks, have total
trust in their in-house framework.
XVII. Data access framework
Need to use one. Stock JDBC isn't enough. Never use straight JDBC.
Understandding how to judge OR mapping solution is appropriate.
Understand core O/R mapping concepts
IXX. Poor productivity
Lots of little hurdles
Slow deploy-test cycles
Slow build process
Slow integration servers
MAJOR productivity hits. Increase the chance of failure
Design build process and infrastructure to minimize these delays.
Traditional J2EE development was laden with these little hurdles.
Always begin with proof of concept, or executable vertical slice. All
modern methodologies recommend this.
Establish clear metrics.
RUP (rational unified process) calls this the inception phase.
Don't trust architecture-or technologies, until you've tried it with
Unit tests don't require container (due to dependency injection)
Choose good frameworks, that allow customization