Over a year ago, DSI embarked on a complete re-engineering of its Java software development processes and infrastructure. The way we write Java is being rebuilt from the ground up, beginning with the development infrastructure we use, the processes that guide us, the practices that we adopt and the way we communicate. Today, we are seeing the results of that effort in the form of reduced timelines, measurably higher quality output, and an enhanced ability to deliver complex enterprise-level systems. From this vantage point, we have more clearly identified the key characteristics of our process:

• Simplicity
• Productivity
• Stability

Simplicity
The drive towards making things simpler was applied both to our architecture and to our processes. We began by favouring POJO development over EJBs, and supported this direction by adopting Spring and Hibernate. Each of these opensource frameworks is excellent in its own right. Together they have transformed our Java development experience - especially in the business tier.

EJB code - particularly Entity Beans - had proven bureaucratic, repetitive and hard to test. J2EE Design Patterns, which were supposed to address these drawbacks, were really workarounds. Some of them actually restricted our ability to make the most of Java’s object-oriented approach. Spring supported a return to basics by allowing simple, testable, object-oriented code to use the kind of services that full-blown J2EE stacks promised (declarative transactions, transparent remoting etc.)

We stripped away any documentation overhead that we could do without, using tools (eg CVS and Fisheye) to monitor changes to the codebase and generate reports. We have become code-centric, so instead of doing things once on paper and once again in code, we go to code earlier and cut out the middleman. A key enabler in this change was a renewed emphasis on readable code, from which we can extract UML documentation where required.

Productivity
Late software is bad software. There is little point in having perfect quality if your client - or your entire market - has moved on. To deliver the necessary productivity, enterprise applications of the kind we develop in DSI require that the codebase be accessed by many developers at once, sometimes working towards different medium term goals. To maintain our high productivity, we have to manage this access in a concurrent way - but safely so. We chose CVS for its tried and tested functionality, and its wide range of clients. CVS’s non-locking checkouts and comprehensive branching support, together with its merging functionality, allow us to develop in parallel, secure in the knowledge that we can splice parallel changes back together with minimal overhead.

To further boost our output, we develop Java projects on rails: We’ve done it all before and we reuse that experience by classifying new projects by type (we have identified five standard types) and kickstarting them with all the boilerplate code and configuration that they need to get going. Our developers can concentrate from day one on coding the business logic. We also relieve the developers of as many repetitive and wasteful tasks as possible, by providing tooling support. Often this is integrated into our preferred IDE Eclipse as plugins.

Stability
Things change: Requirements, technologies, tools, methodologies. But the requirement for stability in the midst of this change remains a constant. If something worked yesterday, it must work today. If we could build version 2.6.2 of a project last month, we must be able to build it tomorrow. How is this possible?

When it comes to build consistency, the magic ingredients are centralization of building scripts, and rationalized dependency management. The key that unlocks each project, and creates deliverable artefacts from source code, is the build script that is stored with the project itself in CVS. Now, each of these build scripts is making use of one centralized library of scripts. Furthermore our build scripts specify the project’s dependencies by referring to centralized and versioned jars and other artefacts. These mechanisms combine to ensure that the build behaviour across all projects remains predictable and reproducible.

By far the most important elements of our process changes to date have been a re-emphasis on unit testing and the use of continuous integration. So much has been written on these subjects that there is nothing for us to add. Except this: Thanks to unit testing and continuous integration we have seen levels of regression errors drop by orders of magnitude without impacting project timelines.

View or download Technical Skills Summary PDF >>