Eclipse in the Enterprise
Eclipse in a Large Company's IT Shop
Many say that the optimal development team is 5-7 people but that isn't how larger Enterprise software projects work. Those projects have dozens or even hundreds of developers using multiple technologies and Languages. Eclipse's plug-in architecture makes Eclipse more than an IDE. It is a developer desktop environment that many enterprises cannot take full advantage of because of they don't standardize their configurations and toolsets and because they require human intervention for setup.
Supersize Me
Big projects are often taken on to support some non IT or computer oriented line of business. This leads to internal conflict and problems.
A typical mid to large IT shop might be
Statisticians and sociologists say that people fall into some type of standard distribution
Software companies and their really smart engineers create tools for really smart, motivated engineering types.
Both those groups are wrong. The average large company has a different mix that changes over the life of the project.
This will sometimes change because of some massive culture shift or some financial change. But, even projects that start off differently often fade into this model as more mainstream employees fill in after the initial push.
Cogs in Our Machine
The smart thing to do is to take this staffing and management reality into account when making choices. We always want to push , to provide opportunity but we (possible) capabilities drive choices even when training and mentoring.
Tooling and Skills Affect Decisions
Modern development tools increase the quality and scope of people's work. Eclipse is so good that it can drive language and toolbox decisions. Cool technologies without great tools support and integration are not worth whatever other benefit they provide. A fancy "super language" with no "reference search", refactoring support, system integration or code analysis tools cause problems over the life of a project.
Eclipse Delivers More with Less Investment
Our Team
Technologies? Yeah, we got those
Goals
Attempt to automate as much as possible. Current configuration saves over 1000 minutes per month when taking into account the number of Eclipse workspaces created due to the number of source branches and the number of new staff or machines.
We Shy Away From
Use Eclipse to Improve Your Product
We also use Eclipse's advanced plug-ins and features to drive our code quality and structure/shape. We've found that people will fix things earlier if the system points out issues early on. People focus on what's measured.
Eclipse has a set of plug-ins that monitor and analyze code. It also integrates with Sonar to show the results of sonar's code coverage static analysis tools. This can drive all developers in the right direction. Our project made the following changes in a single year.
It is more than an IDE. It provides a Framework for Enterprise Development for all sizes of projects.
Many say that the optimal development team is 5-7 people but that isn't how larger Enterprise software projects work. Those projects have dozens or even hundreds of developers using multiple technologies and Languages. Eclipse's plug-in architecture makes Eclipse more than an IDE. It is a developer desktop environment that many enterprises cannot take full advantage of because of they don't standardize their configurations and toolsets and because they require human intervention for setup.
Supersize Me
- Complex problem that often seems simple to the outsider or new team member
- No one person knows the whole business problem
- No one person knows the whole technical implementation
- No one understands how each technical layer works
- A lot more effort is put into staffing the initial build than the ongoing maintenance
- Some work will be defensive in nature protecting from future mistakes
- All applications are legacy applications as soon as they ship. You can't just tear them apart to fix stuff.
- Someone calculated a big ROI so there is real money on the line.
Big projects are often taken on to support some non IT or computer oriented line of business. This leads to internal conflict and problems.
- The software exits to support the business.
- The group is often geared towards production support and infrastructure.
- The company doesn't view the software as a product even though it has all the characteristics of a software product
- The project is staffed with standard large corporation skills mix and motivation
- Contracting resource are often released after the first major release even though the maintenance phase has lots of development.
- Different developer workstation management
- Different CM processes
- Wildly varying IT management experience.
- Different software development processes and requirements
- Different branching, release and code control strategies
A typical mid to large IT shop might be
- 150 developers
- 3 business units
- 10 main apps plus production support
- 15 managers
- 2 Million+ lines of source code
- 250 Production Application Server VMs
- 100 Network Cache VMs
- Single VCS with completely different branch and control strategies.
Statisticians and sociologists say that people fall into some type of standard distribution
- Desire
- Skills
- Instincts
- Experience
Software companies and their really smart engineers create tools for really smart, motivated engineering types.
- "We create tools we want to use"
- "We create tools for our friends"
Both those groups are wrong. The average large company has a different mix that changes over the life of the project.
- Some folks like hard problems
- Some folks are just there for the job
- Some folks can't be fired
This will sometimes change because of some massive culture shift or some financial change. But, even projects that start off differently often fade into this model as more mainstream employees fill in after the initial push.
Cogs in Our Machine
The smart thing to do is to take this staffing and management reality into account when making choices. We always want to push , to provide opportunity but we (possible) capabilities drive choices even when training and mentoring.
- High End developers all think they know how it should be done. "Everyone is an artist"
- Mid tier developers just want to finish their tasks
- Others
Tooling and Skills Affect Decisions
Modern development tools increase the quality and scope of people's work. Eclipse is so good that it can drive language and toolbox decisions. Cool technologies without great tools support and integration are not worth whatever other benefit they provide. A fancy "super language" with no "reference search", refactoring support, system integration or code analysis tools cause problems over the life of a project.
Eclipse Delivers More with Less Investment
Our Team
- 50 Developers
- 8000 Java Classes
- 580 XHTML Files
- 95 Core Model Entities
- BPM: 126 Flows, 209 subflows, 137 UI touchpoints
- 60 Rule Services
- 200 Lookup Services
- 30 Eclipse Projects
- 28 Minute build with 15,000 unit tests
- 6 week release cycle
- Super complex business rules including state, customer type and date effectivity
Technologies? Yeah, we got those
|
|
Goals
- Increase Quality
- Reduce Defects
- Reduce configuration costs and overhead
- Remove need for manual configuration
- Standardize plug-in configurations
- Trade off performance vs sophistication
- Standardize static analysis configuration
- Reduce cost of creating new workspaces
- Use best of breed plug-ins where available
Attempt to automate as much as possible. Current configuration saves over 1000 minutes per month when taking into account the number of Eclipse workspaces created due to the number of source branches and the number of new staff or machines.
- Rely only on dev team resources.
- Support mass migration to new IDE versions
- Store all configurations under version control
- Include fully configured eclipse
- include all 3rd party plug-ins
- include SCM plugin
- include all metrics settings
- include all server and infrastructure configuration
- Provide samples for any files that must be loaded and desktop shortcut options
- Force folks to move from of old versions, after some migration period, by deleting old versions of Eclipse from SCM.
We Shy Away From
- Monolithic Eclipse bundles ad baseline
- reduces plug-in flexibility
- Network file-systems for IDE/executables
- We want everything on the local disk
- Manual Configuration
- Manual setup document for whole environment is currently 80 pages
- Plug-in configurations that run against the whole codebase
- Some analysis tools don't support "on save" or "on change" scanning.
- Some advanced Eclipse plugins
- Some Eclipse projects are cool but can't spin up a high enough percentage of developers.
Use Eclipse to Improve Your Product
We also use Eclipse's advanced plug-ins and features to drive our code quality and structure/shape. We've found that people will fix things earlier if the system points out issues early on. People focus on what's measured.
Eclipse has a set of plug-ins that monitor and analyze code. It also integrates with Sonar to show the results of sonar's code coverage static analysis tools. This can drive all developers in the right direction. Our project made the following changes in a single year.
It is more than an IDE. It provides a Framework for Enterprise Development for all sizes of projects.
Comments
Post a Comment