TSSJS Rod Johnson - Why J2EE projects Fail Blog
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