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
  • 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.
We're not a Software Company
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.
Large companies often contain fiefdoms that support similar businesses or problems of similar complexity. They usually have the same HR culture but operate very differently. The management teams may have completely different levels of (software) engineering background. Differences include:
  • 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
We're these Guys
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.
The Great Mismatch
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
  • Java
  • XHTML
  • Javascript
  • JSF
  • Rich Faces
  • XML
  • Spring
  • AspectJ
  • Oracle SQL
  • Coherence Web
  • Rule Engine
  • Workflow BPM
  • Spring Web Flow
  • D-Rules
  • Axis
  • MQueue

  • Maven
  • JUnit 4
  • EasyMock
  • Hudson
  • Sonar
    • Checkstyle
    • Findbugs
    • PMD
    • LCOM4
  • Eclipse Validation
  • Eclipse Formatter
  • Groovy for Tools
  • Perforce
  • Jira
  • Eclipse
  • Crazy Monitoring
  • Specialized Logging

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
We Do....
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

Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs