TSSJS Rod Johnson - Why J2EE projects Fail

Rod Johnson, why J2EE projects fail

I. Enterprise Development is Hard

  A. Why

     May integrate disparate systems

     Hard performance problems

     Complex domains

  B. hard to test

  C. Hard to maintain

    Software is never finished.  Maintenance accounts for the bulk of
    effort

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

  Sound fundamentals

  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

    God-like architect

    Too big a team

    Overworked team (reactive v. strategic modes)

V. Technical reasons

  Missed deliverables

  Too much code

  Take small example and extrapolate when it doesn't scale

VI. Requirements

  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.

VII. Solutions

  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.

  Two varieties

    non-coding: powerpoint, UML, (motivation: not enough), big picture
    only

    The prescriptive framework builder: obsessed with the small and big
    picture.  Cares about controlling every aspect of the programmer's
    life.

      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
    frameworks.

   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

   People leave

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

  Spring

    Lots of extension points (he feels extension points are key for a
    successful framework).  

  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

XVIII. Testing

  Test first

  Integration testing

IXX. Poor productivity

  Lots of little hurdles

    Slow deploy-test cycles

    Slow build process

    Slow hardware

    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.

  

XX. Recommendations

  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
  your needs.

  Automate everything

    Unit tests don't require container (due to dependency injection)

  Choose good frameworks, that allow customization