Making Java EE Software Development Agile, Overcoming the Disconnect

David Pitt Agile, Dev Methodologies, Java 4 Comments

If you want to go surfing but you live smack dab in Kansas, it could be a challenge. (Unless you want to go paddle in a lake.)

If you want to create a new and innovative software to change the world, but your company and its bureaucratic processes are stuck in the 1980s, it could possibly take a while. (Compared to a start-up organization, for sure.)

If you want to write Objective-C, and all you have is a PC, there will be some challenges. (Buy a Mac!)

When goals and environment are not on the same page, there is a disconnect. That disconnect can cause some major problems, especially in business – You have to change your circumstances.

Your environment must match and support what you want to accomplish. That is, if you want it to work seamlessly and without bumps in the road.

For example, Agile development. Agility is the verb that has been assigned as the solution for IT’s slushiness in developing custom software. We have had great success in applying Agile processes to the development cycle to our clients. However, if the mechanism for software development is not Agile, then there will be some definite problems. It can be a waste of time, resources, and peoples’ patience as they get more and more frustrated.

So how do we fix it? Listed below are things that should be put into place in order to effectively support an Agile software construction environment:

Consistent Application Architecture

Consistency promotes predictability, scalability, and re-usability in software development. Impacts of applying new frameworks and patterns can be predicted. Consistent application structure and application of frameworks allows developers to functionally decompose their work efforts in a consistent manner for level of effort and resource planning. Additionally, consistency promotes reuse, as generalized components can rely upon an expected consuming application structure.

Convention Over Configuration

Whenever possible, introduce generalized mechanisms that allow developers to start writing code out of the box. Eliminate having to set up or visit configuration files, hunting down libraries. The developer should always produce code that is verifiable and directly solving a problem space. (As opposed to having perform setup or initialization activities.)

Continuous Integration Environment

Establish an automated mechanism that “continuously” and frequently compiles/builds/deploys/tests code committed by the team to the repository. This environment helps ensures quality, and eliminates the inefficiencies developers can have when dealing with code resulting from merging activities. Less time is spent setting up demo and prototype environments for verification, allowing developers to keep their stream of consciousness in providing a solution.

Reference Application

Define and maintain a basic application that represents your application architecture. This can then be used a medium to describe how applications are constructed with your architecture, and communicate and prove new frameworks or technologies. Scaling Agile development can also be enforced, by documenting steps required to build this application. New resources can then go through this exercise which will expedite their learning curve on their own, without taking away from existing resources.

Low Ceremony

Provide an environment in which the development team can easily install supporting software such as application servers or database instances. This of course, is limited to just the construction phase of the project, but by providing this “low ceremony” ability, agility is achieved by passing the normal IT administration protocol during construction. Things can happen quicker, and after an Agile spring/iteration verification the team will have a better understanding of the “to be” production environment. At the same time quickly deliver early working deliverables and versions of the software.

Knowledge Access

Take advantage of WIKI software, which will provide a way to communicate your application architecture and development environment. The WIKI brings agility to documentation, as it can be edited in-line allowing developers to collectively contribute to it, thereby helping to keep documentation fresh and relevant.

… Just to name a few.

If you’re going to do something, do it right! Although many make the disconnect work for their company, wouldn’t it make it easier to have a “no bumps in the road” agile software construction environment? Agile tells us to always be looking for ways to do things better– start now!

— David Pitt and Lauren Fournier,

About the Author
David Pitt

David Pitt


David Pitt is a Sr. Solutions Architect and Managing Partner of Keyhole Software with nearly 25 years IT experience. Recent projects involve speaking, writing, and training developers in enterprise JavaScript​/single-page application​ development best practices​, as well as the development of GrokOla, the Q&A-based wiki software​ for development teams.​

Share this Post

Comments 4

  1. Phil

    On the “Consistent Application Architecture” point – how do you balance that against specs and tests driving out the code and not using more code than necessary.

    For instance, if the tests don’t drive out that I need a services layer, should I include a services layer for consistent architecture’s sake, or should I leave it out because the project doesn’t need it?

    I’m not saying there’s a right answer to this; I’m just genuinely curious what you think.

  2. David

    When a project is initiated, enough requirements are usually known to establish an application architecture. High level requirements such as a web based user interface, access a relational data store, etc. is enough information to establish a reference application architecture along with identifying supporting frameworks. Consistent patterns are employed to engage these frameworks. This application architecture also supports creation of unit and integration test development if a test driven development approach is taken. In a Scrum project i would refer to this a Sprint 0.

    Thanks for the comment,

    1. Phil

      I gotcha. So, you’re not advocating reusing the exact same application architecture framework from project to project, but applying consistent patterns when you decide on your application architecture for a project.

      That, I’m much more comfortable with.

      A lot of times, I see people who are sort of newish to OOP and agile development start in on a project and, right out of the gates, they configure NHibernate and their favorite IoC container, as if these things must be present in every project. Or they create a particular sequence of layers that they just use as a default for every project.

      To me, this is waste. But I do agree with using consistent architecture patterns from project to project.

  3. Leota Traff

    I have to get across my appreciation for your kindness giving support to individuals that actually need to have support with this concept. Your personal commitment to obtaining the answer across had become truly effective and has continuously made some individuals like me to realize their desired goals. Your personal insightful advice denotes this considerably to me and somewhat more to my office workers. Several thanks; from all of us.

Leave a Reply