Development Process « Design « Java Articles

This article builds on my discussion in the JavaWorld article "J2EE project execution: Some best practices." That discussion focused on improving the productivity of Waterfall-based projects using Java EE development best practices such as a reference implementation, an effective developer's handbook, and automated code reviews. In this article I focus on the benefits of incorporating agile best practices like automated buiids, continuous integration, and test automation into Waterfall-based Java EE projects.

In this month's article, I change directions a bit and, rather than tackling a new coding concept, you will explore an idea that reinforces sound development practices and is intended to improve the integrity of your code.

There are a number of roles involved in developing software solutions. The development lead (DL) role is the one that glues together the overall architecture created by the solutions architect (SA) and the developers. Figure 1 shows the positioning of the Developer Lead within a project organizational hierarchy. The development lead is the part of the puzzle that bridges the vision of the architecture with the reality of the code. (If you've not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

Quality in general has taken a beating over the last several years as high profile software failures have made it into the media and because there is a growing awareness that viruses are possible only because of a quality slip in the software that the virus attacks. Despite a growing awareness of software development failures there's little growth in the QA role. This may be due to a variety of factors including: misunderstanding of what the QA role, the lack of understanding of the value, or simple ignorance of the need for quality assurance.

Training is without a doubt the most extroverted role of the software development process. Even the functional analysts don't have as much contact with people as the training professionals do. Key communications skills are essential to getting the role and staying in front of the best customers.

One of the major problems with a paper-based notebook system was that the information was only organized by time. Once a notebook was full, it was hard to include more information in it—you went on to the next notebook. If items in one notebook related to items in another notebook, the only way to truly relate them was via reference notes. And this was possible only if you could actually find the item that you were interested in from an earlier notebook. With an Electronic Notebook, you can always update and refine your notes.

It is possible to believe that there is nothing left to be done. That all of the roles outlined thus far is all that is needed to make the process work. However, the role of the development manager is critical to the long-term success of the software development team. The role that the development manager plays - particularly when interacting with the project manager - is essential to a continuously improving process. (If you've not been following the series, you might want to read Cracking the Code: Breaking Down the Software Development Roles.)

Outside of software development, I found myself similarly obsessed with complexity and control. For example, I had a home network setup with a Web server, my own mail server, print server, and specially configured Linux-based firewall, all of which I thought I needed because I wanted things just so, and all of which extracted an enormous toll in time and effort.

As with any role there will be good with the bad and then there will be the really ugly. The functional analyst has the opportunity to set the software development process on the right path by carefully controlling how the process gets off the ground. There are the key points for the role:

The Project Management role is the first role in the software development process that isn't on the main line. The project manager isn't a person doing "real work." The project management role is one that is designed to help ensure that the software development process works as it is intended. The project management role works closely with the development management role in order to facilitate, encourage and prioritize the process.

The deployment professional can often times experience the good, the bad, and the ugly of their role all in one day. They can see the software get deployed across the organization - only to find out that here was one application it wasn't tested with, and that one application is one of the mission critical applications for the organization - which the installation just broke. Here are just a few of the good, bad, and ugly things about the deployment role:

The loss of civility results in destructive tension, name calling, back stabbing, bozo-bit-flipping, and character assassination. As with people, all ideas are not equal. Over time, some ideas are demonstrated to be better than others. This is why I like Brooks' idea of a surgical team. In the operating room, the surgeon leads and everyone else follows. On a software project, this means the technical team lead or the architect has the final say. Consensus is for politicians and car builders, and often results in ungainly compromises and mediocrity. Consider abortion laws: No one is happy with compromise made. Another example is exhibited in some cars that don't make any sense, like that mini-van, truck, SUV sort of car that looks like an ungainly turtle; a committee designed that and every constituency got something in. I will bet that the original Mustang, Corvette, and Thunderbird were all designed by one guy.

The developer role is the core role into the software development process and is the one that there are the most open positions for. The role itself has its own set of trade offs, however, for the upwardly mobile professional it may be the way to put yourself on the path for the position you really want.

Few ideas are completely original. In some book I have read (or maybe several books), it was written by a famous person that presentation composition is the weakest for of development, data composition is the second weakest form of development, and building the core business capabilities is the strongest way to build software. (If memory serves, I first came across this idea in 1992 in Grady Booch's book on OOA/OOD.) Another way this has been stated is to build the onion in layers from the inside out—sounds like something Jim McCarthy wrote. Paul Kimmel and Larry Zippi call this "Core to Cosmetics."

Subject matter experts really fall into a few categories. The first category is the business owner who initiates the development process. For internal development this might be the manager who is sponsoring the project. For external development projects it might be the customer paying the bills. For software development companies the SMEs are most often the users of the software who understand what the product is supposed to do the most or at the very least what the product is expected to do.

It is no wonder then, why we don't improve our software development process. If we can't stop going to fast food restaurants that is quite literally killing us, if we trust the dieticians, then how can we ever hope to improve the way we look at software development. The answer is simple but just like a diet, requires some discipline.

In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Patterns are previously described and validated approaches that can be used to create portions of the solution. Patterns are released through research and can come from places such as Microsoft's software development libraries. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern.

This is the true origin of the fallacy that code is its own best documentation: The code itself is the only document which may be relied upon in any way in order to find out how the software might actually behave under this or that set of circumstances. However, anyone actually saying so only reveals themselves as a troublemaker.

There is a series of roles that exist in most software development processes. As mentioned above one team member may be filling many roles and some roles may be suppressed for a specific type of project but all of these roles exist in one form or another in every software development project:

Before we delve into the goals of each type of organization, it's important to understand that these are generalizations. There are some organizations that don't behave according to the norms that I describe here. The objective is simply to explore how different types of organizations typically have differing objectives and how some of those goals may be detrimental to the software development process.