Chapter 9

Tips for Managing Change Issues During Development

DAs with any human endeavor, there are easy ways and hard ways to do anything. This chapter provides tips on how to make development easier. These tips come from my development and consulting experiences. They are not intended to be comprehensive. Nevertheless, they just might help you with managing change issues during development.

Design as Little as Possible

If you haven’t experienced “analysis paralysis,” you are a rare member of our profession. The design of a system can sometimes seem as if it will go on forever. The best tip I can give you is to design as little as possible. It may sound counterintuitive, but most of the successful projects I have seen are based on as little design as possible. How do you do this? One way is to buy a system or use one or more existing services. Another way is to buy a model or adopt a semantic vocabulary. Any of these tips will narrow the amount of design that you must do.

Buy a model or adopt a semantic vocabulary

If there are good reasons to not buy software, you don’t need to start with a clean sheet of paper. There are data models available for purchase that are applicable to most segments of industry. Often these are referred to as universal data models. Universal data models can work with both data warehouses/master databases or with big data in the cloud. Similarly, there are semantic vocabularies designed for specific industries.

I cannot begin to tell you how many times I have seen people struggling to model the same data or vocabularies where data models or semantic vocabularies already exist. Frankly, how many different ways are there to model customers, employees, addresses, products, and so on? Yes, there are variations among companies. Nevertheless, if you look at the universal data models or semantic vocabularies, many of those variations are handled in elegant ways. In fact, usually experienced data modelers develop the universal data models and semantic vocabularies—often these folks are more experienced than any modelers you might find in your organization. Months—yes, months—of modeling efforts in an organization fall short of almost any universal model or semantic vocabulary. If you need to add something to an existing model or vocabulary, it is usually a minor addition requiring minor modeling.

The change issues you will likely encounter are:

ent Lack of training/understanding. The fact of the matter is that when confronted with a universal data model or standard semantic vocabulary, many people don’t see how it will work. Often, it is because they are stuck in their view of how the system should work, based on what they have experienced. They are often trying to “map” their understanding of the current system to the universal data model vocabulary. This can be a stretch for some people.

ent Power of the internal “expert.” Oh my goodness—bringing in a universal model or semantic vocabulary can really threaten this person. Telling anyone that these things will be better than something that this person—an expert after all—could put together is a very difficult sell. You will need to plan for significant resistance here. Chapter 8 provides some suggestions.

ent Not invented here. It is really tough to realize that other people have actually addressed many of your modeling issues. Even worse is the possibility that someone else may have done a better job.

ent Our problems are special. This might be true around the fringes of a universal data model or semantic vocabulary. In a rare case, it might be true in general. Be sure to thoroughly search before accepting that your problems are truly special.

Write as Little Code as Possible

This sounds too easy, but it is true. Time and again, I see people writing more code than necessary. Couple this with the fact that on average, professional coders make 100–150 errors per thousand lines of code,1 and you want to write as little code as possible just to minimize the errors.

Of course, buying systems, buying models, or using existing services will reduce the code you write. You should consider those options first. As Web services continue to be adopted throughout our industry, it will become increasingly possible to buy “plug-compatible” software components that you can assemble into an SOA.

If you have to write code, take a serious look at the systems you have. How many times have you written the same code to validate a customer account? I know some managers who have been able to identify the relatively few procedures they have that have been written repeatedly. Factor those out. You might be surprised by how much reusable code you have.

Reduce Project Scope

Many development methodologies emphasize reduced project scope and reduced project times. Nevertheless, it is so tempting to create big projects. You and your team need to come up with ways to minimize the scope of each project. Multiyear projects are unthinkable. Twelve-month projects should be looked at skeptically. The challenge to the manager is to create projects that can be completed in less than 12 months—less than 3 months would be even better.

Smaller projects are more focused and are more likely to succeed. Large projects are likely to fail. Since 1994, the Standish Group has conducted studies on IT development projects, compiling the results in the Chaos Reports. In 2005, Watts S. Humphrey of the Software Engineering Institute looked at the Standish Group’s data by project size. His research showed that half of the smaller projects succeeded, whereas none of the largest projects did.2

Related to reducing project scope is the idea of building an SOA incrementally. Chapter 10 provides specific suggestions in this area.

Use a Methodology

In all my years of consulting, I have only rarely encountered companies that are really using any software methodology. Sure, they may say they are, but in reality they are still “shooting from the hip” when developing software.

Any methodology is better than no methodology. Yes, you can argue as to one being better than another, but the plain fact of the matter is that if you truly follow any methodology, you are going to be much better off than when just paying lip service to the methodology or simply not using one.3

To take advantage of a methodology, invest in a tool that supports the methodology. Paper systems or drawing tools that are not integrated with the methodology often end up being not very helpful. Not using a tool lets people “cheat” or not stick to the “rules” of a methodology.

Use a Second Set of Eyes

Many methodologies involve having at least one other person look at any particular piece of work. Using a “second set of eyes” is critical. The trick, however, is really using a second set of eyes. Have you been in a group code review where the programmer describes what is going on in the program and everyone more or less nods their way through the review? How helpful is that really? Methodologies that require someone other than the author to describe what is going on in an architecture, design, program, and so on are much more effective. It requires that person’s second set of eyes to really look and that second mind to really understand.

Use Small Teams

For years I have been recommending that people should consider the communication issues in software development to be much like a dinner party. When you have a dinner party of seven or less, it is usually possible to have one conversation. As soon as you have eight or more people at the table, the dinner party breaks into two conversations and no one hears everything that was said.

This is often what happens in software development. Communication is critical. Use a small team. Put them together in a one room. Let them focus on development of their project; that means that the project is the only thing they are doing.

Summary

As stated at the outset of this chapter, these tips came from my development and consulting experience. They are meant to improve your chances of being successful with your development efforts. Chapter 10 uses three tools that address change issues.

1Watts S. Humphrey, in a Multiyear study of 13,000 programs conducted by the Software Engineering Institute, Carnegie Mellon. Mentioned in “Why Software Is So Bad… and What’s Being Done to Fix It,” Charles C. Mann, MSNBC Technology Review, June 27, 2002.

2Watts S. Humphrey, “Why Big Software Projects Fail: The 12 Key Questions.” CrossTalk: The Journal of Defense Software Engineering, March 2005.

3One person who reviewed this manuscript for the first edition of the book commented that methodologies could be used as another form of resistance. He described how entrenched experts in an organization can use methodologies as a covert means to ensure a project gets nowhere because of “the demands of the methodology.” A variant of this would be using methodologies inappropriate for an organization, thereby slowing development. I guess you need to be ever vigilant to resistance issues.