Application Architecture for WebSphere: Setting a Standard
- Organizational Standards and Conventions
- Putting the "Engineering" in Software Engineering
- Working with Logging and Tracing
- Project and Packaging File Structure
- Unit Testing Requirements
- Code Completion and Review Process Requirements
- Communicating the Vision the Wiki Way
- Conclusion
- Links to developerWorks Articles
- Reference
This chapter is from the book
This chapter is from the book
This chapter is from the book
Standards are an important concept, but achieving them is probably one of the most overlooked opportunities to improve the quality of software applications. On the surface, standards may seem like a trivial concept, but good application architecture starts with them. You often hear sports analogies about getting back to the basics; in software development these standards are the basics. This chapter covers standards and how to set the right ones for your organization or project and offers some recommendations and ideas for you to build upon with your own standards documentation.
Organizational Standards and Conventions
I have noticed over the last few years that some topics come in cycles. This may be a result of an ever-changing industry but standards are one of those topic areas that seem to come around every few years for a new set of discussions. Why do we need them? To quote myself in an article that was published in IBM developerWorks in 2007:
- “Basically, things that are shared require that everyone who uses them gets along and plays nicely. Convincing organizations that this is a good idea seems to be a constant struggle. We are all bounded by the daily responsibilities of our jobs and the goal of getting projects finished, but it is everyone’s responsibility to promote the idea that rules are a good thing. Rules help to promote cooperation, prevent mishaps and misunderstandings, enhance accountability, and enable recovery. That is, assuming we get things right in the first place....”
The industry recognizes that for any development effort, standards are very important, but achieving them is something we rarely do well. Following well-designed programming standards can result in greater consistency within the delivered code, better quality code, and code that is easier for other developers to understand and maintain. Additional benefits of well-designed and -documented code include a reduced cost of long-term maintenance and the ability to transition artifacts to another team member or team. Before we get too deep in the weeds here, let me define a couple of terms:
- A standard is a minimum set of rules for the way something has to be done.
- A convention is a suggestion for how you might do something. It is the way things are usually done, but it is not necessarily set in stone.
Be careful how you define these terms to your development team. Often we use terms like naming conventions within a set of standards. Obviously you cannot put together a list for naming components that may be developed over the foreseeable future; however, this does not mean that the suggestions you put in place are optional, either. Sometimes these terms are used interchangeably and mean the same thing to the team. This is fine as long as everyone understands the meaning.
Everyone agrees that standards are important, but why devote an entire chapter to them? Because many organizations struggle with coming up with a comprehensive set of standards that can be implemented and, more importantly, enforced by the development side of the organization. If you don’t write them down, then standards do not really exist, and you can’t realistically expect developers to follow them. You also cannot expect to write them after the fact and have developers change their code to match what you have decided, especially if they are in the middle of a coding cycle. Doing so is not fair to anyone and is definitely not a good use of allocated company funds.