C H A P T E R  5

Strategy

This chapter is about new and different practices that have strategic implications. The definition of strategy that this chapter's title refers to is “a plan, method, or series of maneuvers or stratagems for obtaining a specific goal or result: a strategy for getting ahead in the world.¹” And so, ironically, this chapter provides you with tactics to help you focus on strategy.

In this chapter we focus on three strategic areas related to better development practices:

• Awareness: Make changes that improve perception and consciousness.
• Personal process: Make changes at the individual level.
• Leverage: Make changes that produce big results.

Even software projects that have every advantage can fail to deliver the desired results. The project can have the latest tools and technology. The team may be very well qualified. Everything might appear to be set up for success. However, the strategic questions are short-changed. In a rush to get the developers to the task of writing code, something important is missed. The developers do not know the strategy. Big questions remain in the developers' minds, such as

• What are the objectives we are trying to meet?
• Why are we trying to meet those objectives?
• Who wants us to meet those objectives?
• How can we best meeting those objectives?

The developers need to know the answers to these questions—clearly, correctly, and completely. Many projects dive quickly into the day-to-day, focus on technical minutiae, and waste time on other unimportant topics. Opportunities to focus on strategy are missed because they are pushed out by proximate, pressing issues. What is truly important, like answers to the strategic questions, is neglected. The practices listed in Table 5-1 are intended to move the focus back to strategy to the benefit of the whole project.

__________

COMMENTARY

Awareness

The development cycle is full of opportunities to see important information as it emerges. Many of us miss this information, which could be a missed objective, an inadequate design, or a misunderstanding. This lack of awareness leads to future problems. Being able to see things clearly, especially when disconnected by distance or time, is strategically important. The strategy of raising awareness is about elevating the team's ability to perceive and be conscious of key aspects of development, such as

• Patterns: Things that repeat in some predictable way and present broad solutions to these common, reoccurring issues
• Events: Occurrences of some significance that are worth considering with regard to preventing problems, resolving issues, or improving a process
• Conditions: The state of things that point to instability, degradation, or a general need for improvement
• Failure Paths: Known causes of failure or processes that are likely to lead to failure

Perception is only one part of awareness. The other part is consciousness. You have to think about what it is that you see and hear. The thought process develops your reactions and choices. Information about code quality, for example, could be a warning sign that points to a real problem that is important to address immediately. On the other hand, the information could be unimportant. Both knowing there is an issue and knowing how to react to the issue are key elements of awareness.

There is individual awareness—that is, those things you are aware of or another person is aware of—and there is the group's awareness. Both are important. You may know there is an issue and believe it is significant. However, the rest of the team might not believe it is important. Generally speaking, communication is the way to handle differences in awareness. Through one-on-one and group dialog, knowledge and understanding improves for all. Perhaps each person perceives the situation differently because each has different experiences. You might see a pattern because you have read about the pattern. The important point is that effective communication is the strategic practice that raises the alertness of the whole team.

Brainstorming

There is something about the human brain that often makes it hard to do two things at one time. Talking and listening seems to be one of them. Understanding a significant, complex problem and solving that problem is another. For many tricky issues it is not until after you fully understand the problem that effective solutions present themselves. These problems have many variables, a lot of interrelated components, and hidden implications. To solve the problem, you must be aware of so many different things. Brainstorming opens the mind and engages the imagination. Ideas are spontaneously created and captured. Creativity takes over. The practice of brainstorming raises an awareness that allows people to see and hear new information.

No matter how intelligent or experienced a person is, everyone benefits from collaboration. It is one of the principles behind code reviews, pair programming, and the Coding Dojo.² Our ideas and thoughts are complemented or challenged by the ideas and thoughts of others. When you learn about the relevant experiences of others, the depth and quality of your thinking improves. Brainstorming is a way to facilitate this collaboration of ideas and experiences. Performed in a group setting, brainstorming techniques elicit new opinions and understandings that often help make the entire group more effective.

Many brainstorming techniques are useful for both an individual and a group setting. Table 5-2 contains a list of different ways to engage the imagination and generate new thoughts and opinions. On the Internet, there are many excellent sources of brainstorming techniques; take some time to try a few individually or in groups.³

__________

Planning

The process of planning is actually a series of activities, which organize thinking about reaching a goal or meeting objectives. By planning things out, the team considers the mandatory or preferred sequencing of development activities. Thought is given to estimates of effort and timelines. Obstacles and dependencies are more apparent. Assumptions and preconditions can also be explored. The process of planning raises awareness. Everyone has a chance to see the high-level plan. The team is conscious of what the project is about and what needs to be done.

A second element of planning is the plan-of-approach. For example, the architecture of the system is the technical plan-of-approach. It is developed through engineering analysis. The planning is about considering different options and making choices based on how best to meet the objectives. Take time to map out the approach at a high-level view of development topics, such as

• Tools and technologies
• Architecture and design patterns
• Components and modules
• Dynamics and interactions
• Deliverables and deployment

Sometimes overlooked, another part of planning is the idea of motivation. A project is done for someone or for some purpose. In the end, the project ought to serve an end-user or customer. During the planning process it is important to have an individual involved who can speak with the “customer voice.” In Agile development, that person is the product owner. Perhaps the best reason to have the product owner involved in planning is that that person can speak to the priorities and objectives of the end-user or customer. The product owner helps guide the planning toward the project's goal. It is the product owner who keeps the team aware while planning.

Planning makes everyone aware of the proper sequencing and what was considered and selected. By having everyone on the same page, individuals make decisions that line up with the decisions within the team. Through planning, different teams make decisions that line up with other teams.

Monitoring

In software, things are monitored by knowing conditions or events. As events occur or conditions change, the software reacts or responds. Monitoring is the software's “awareness” of the state of the system. The same is true for the development process. With monitoring, the team is aware of conditions and events that improve development practices. For example, failing unit tests let the developer know that code is probably not working as intended.

Many of the development practices described in this book improve monitoring. The monitoring is intended to alert the team to a potential problem. However, not every condition or event is a problem. The idea is that the monitoring is alerting you to an issue. You perceive a potential problem. You are conscious of where the issue is and where to start investigating. For example, a failing unit test could mean there is a mistake in the source code, but it could also mean that the test code is wrong. The key benefit is that, whatever the cause, a change or correction is needed.

Over time monitoring becomes more and more valuable only if false alarms are rare. Each alarm ought to be meaningful. Initially, the automated tests that are written by the developers may generate false alarms. That does not mean you should stop running the tests. It means the tests need to be written more effectively. In Chapter 8 there are many specific practices that help improve test code.

Review the monitoring practices from time to time. Be sure that those practices can detect the proper conditions and events that alert the team to problems. Find ways to reduce the noise of false alarms.

Communication

Many development team leaders lament the fact that they spend so much time communicating. Ironically, under-communicating is usually the problem. In the beginning, the team lead does not send enough e-mails. The team lead does not keep an eye on whether the team is meeting objectives. Code reviews do not happen. Then, suddenly, the team lead is swamped by a tidal wave of communication that surrounds misunderstandings and missed expectations. As a team lead, if you do not feel like you are over-communicating then you are probably not communicating enough. You can find different approaches to keep it from being repetitious, but you must get the message out and confirm that it is received and understood correctly.

As a team member, there are many effective ways to ask for and get the communication you need. Ask the questions that need to be asked. You may be confused, so ask for an explanation. Another way is to send an e-mail to the team lead that both provides your status and indirectly asks an important question. For example, “I am almost done with the bug fixes for the Loan Payment Calculator screen. My bug queue is empty. Unless there is something you think I should be working on, this afternoon I will start helping Pat with the Quarterly Report.” This message has the virtue of explaining your status and making a proposal. The e-mail provides the team lead with information to act upon and lets him know what you plan to do next.

The whole topic of communication is quite vast. There are many things to learn and understand about how people communicate, and this section cannot cover it adequately. However, one insight to gain is that, through communication, the thoughts that are in your mind need to make it into another person's mind. To make matters worse, many fundamental assumptions are often not made explicit; what is in your mind is not at all what is in the other person's mind. For example, in a discussion on upgrading the object-relational mapping (ORM) package, the team leader is planning to switch from NHibernate 2.0 to Entity Framework 4.1, but the developers are thinking about upgrading to NHibernate 3.1. The task is always referred to as the “ORM upgrade.” The team leader never explicitly said it was a switch to Entity Framework. Miscommunication is amusing when caught early. Caught late, it can be disastrous.

Good, effective communication is of strategic significance. It is something worth getting right. Poor communication leads to misunderstandings, hurt feelings, and inefficiencies. Communication is helped by drawing diagrams, asking questions, meeting face-to-face, listening carefully, and articulating concepts clearly. Much of this is common sense but not common practice. Combine many different techniques together and know not to short-change communication. Here are examples of how multiple practices combine:

• Architecture: Communicates with visuals and diagrams, at an appropriately high level, to give both an overview and multiple views of the system.
• Convention over configuration: Communicates by having the developers learn and follow conventions, so developers need only worry about exceptions.
• Archetype: Communicates a model of how the architecture works and provides software examples to emulate.
• Unit testing: Communicates detail design and how the code is intended to work in a way that can easily be run in the debugger.

There is such a thing as unhelpful communication. Inviting individuals or groups to meetings that they can skip is a typical example. Their attendance at the meeting is a waste of their time, or worse, the meeting could needlessly alarm or alienate them. Joel Spolskey offers a good description of the various forms of unhelpful communication.⁴ To avoid unhelpful communication, sort out the boundaries for the communication by considering these questions:

__________

• Who is the audience that needs to know this information?
• What is the audience expected to understand?
• How can the information be best conveyed?
• Why is the information useful or needed?
• When is the follow up going to happen?

These types of questions start the thought process regarding different communication options. For example, a blog post that explains a team convention is handy to have many weeks later when a new developer needs to know that same information. Instead of writing an e-mail, write the blog post and send an e-mail containing a link to the blog post. Examples of different ways to communicate are provided in Table 5-3. Try to combine multiple methods to provide a richer fabric of communication.

Personal Process

As individuals we each have a personal process. What we do and how we do it can make us more effective or less effective. As part of an individual strategic practice, you should work to improve your personal process to see improved results. The results you can expect are in higher software quality, greater productivity, better communication, more enjoyment, and a more successful career. An improved personal process starts by making a commitment to excellence.

The practices presented in this book align to the principle of striving toward a more disciplined approach. This approach centers on learning, teaching, growing, and achievement. Consider carefully how to follow practices that deliver results for you and for others. For example, if you are more productive in the mornings then arrange your schedule to get up earlier and arrive at the office earlier. Eliminate distractions and propose later meeting times, whenever possible. Do this to maximize your productive time, which will show results for you and the team. Take a disciplined approach whenever you can.

The early effort you put into a project can pay huge dividends later. There are often slow periods before, between, or in the early stages of projects. Although tired from the last project, this is the time to put in the strategic effort to learn a new technology or development practice. By the same token, completing a successful project requires perseverance. Sticking with a difficult task may not seem worth the stress and strain, and in some projects it is not. However, for most projects the invaluable lessons come in the final push to get the project delivered. Remember that after the project is over, you get to keep the learning and experience. Hopefully you can apply them on your next project. What you gain from the effort and perseverance is of strategic benefit to you and the team.

Commitment to Excellence

There are many small ways to make a commitment to excellence. One way is to carefully double-check your code. Unit testing is a way to ensure that the code works the way you intended. Another is thoroughness. Take the time to consider every eventuality. Think through all the expected and unexpected ways your code could be called. Write unit tests to completely cover these conditions and scenarios. This carefulness and thoroughness has a huge benefit to you. It gives you confidence. You are certain that your code works the way you intend it to work. It is not false bravado; it is true confidence based on preparation and commitment to excellence.

An individual commitment to excellence can extend to the whole team or the entire project. As the developers deliver quality work it builds trust. It is a trust based upon seeing the desired results delivered. There will be defects, to be sure, but they will not be defects of carelessness. If the code does not work properly then it is because there is confusion over requirements or some other misunderstanding. The team's commitment to excellence allows the team to quickly acknowledge the defect and start working toward a solution.

The relationship between teams also improves. Developers get more involved in trying to read and understand requirements. They want to do a better job, and so they ask questions, look for inconsistencies, and help uncover omissions. The requirements are clarified and explained. With greater involvement from all teams the overall commitment grows.

To many, all this talk of a commitment to excellence sounds overly optimistic and idealistic. In fact, it is optimistic, and it strives toward an ideal. Improved practices do not come from pessimistic thinking. New and different practices are not adopted by those who are resigned to the status quo. Optimism and a commitment to excellence are a strategic part of moving toward better practices.

Virtuous Discipline

This section is not about the harsh and severe discipline of punishment and control. Virtuous discipline is a valuable and beneficial discipline. It is the discipline of following conventions, improving, coordinating, and achieving. Notice how each of these is done best if done voluntarily. In individuals, this is the result of self-discipline, and for the team it is the result of leadership. In software development, there is a common negative reaction to the idea of team discipline. There is a fear that discipline limits creativity. Virtuous discipline should not limit creativity. Theatre companies and dance troupes have discipline, and they are creative. In fact, with many significant group activities, creativity is unleashed only once a fundamental discipline has been established. Teamwork, collaboration, and creativity are all enhanced once the standards and norms of the group are established. These are good development habits that are advantageous and promote project success.

Listed in Table 5-4 are topic areas to examine for new and different disciplines and examples for each. The idea is to improve the way you and your team develops software. Develop new habits that have benefits to you and your team. Add more and more with each new project.

Effort and Perseverance

In difficult projects, the development team ends up exhausted, both mentally and physically. In the final stages, morale is low and mistakes are frequent. It is strategically important to balance the effort and exertion levels so you gradually build capacity and ability, but the work never destroys the developer. This is similar to how a marathon runner should train to run a marathon. The training is hard in the beginning, but once speed and endurance are built up the goal changes to remaining both injury-free and near peak ability. In software development, effort and exertion should increase as capacity and ability increase. Plan the effort curve around the goal of increasing the capacity to produce results.

Since the effort is so often greatest near the end of a project, it is ironic that the most significant and intellectually challenging work is often left to the end. The developers are tired and drained, yet the next major feature set is bigger than the last. It is demoralizing. This is the opposite of the way things should be. When people are fresh and energetic, that is the time to engage the intellect. Plan the effort so that projects start with the intellectual and complex challenges. Save the many straightforward and undemanding tasks for later. Having more time to think and develop the best approach to challenges is important. Also, the amount of work is often greater and the exertion level higher than planned. By tackling all the complicated work first, a more realistic estimate of the remaining effort can be made. What remains may be a lot of work, but it should be uncomplicated and predictable.

After the software is built and the project is over, many managers believe that all of the value is in the source code. Most of the value is actually in the minds of the developers. They retain all the learning and skill that was needed to build the software. Much of that learning and skill is in general programming, problem-solving, debugging, configuration, and technology. One way to know which developer learned the most is to ask: if you could write the software all over again, what would you do differently? The developer who answers that question thoroughly definitely learned a lot from the project.

In the end, successful projects deliver. What you deliver is an important part of long-term success. The experience of persevering until the software is delivered makes a huge difference to knowing what it takes to see the next project across the goal line. Perseverance pays off for you and your team when the positive outcomes are finally realized. Understandably, developers are often not willing or able to see the project to the end. Those developers often miss out on the rich rewards of seeing a project completed successfully. Coping with the discouragement, opposition, and near failure is an ugly, but important part of software development. Increasing perseverance is a practice well worth improving, but it only seems to come through trial and tribulation.

Leverage

The strategy of leverage is about making a small investment of time and effort to yield a high return in increased capacity to deliver results. The practices in this book are high-leverage practices. For example, a small investment in setting up a continuous integration (CI) server delivers automated builds that can find code integration issues soon after new source code is pushed to version control. (The CI server is discussed in more detail in Chapter 10.) The automated build detects these problems shortly after the issue is first introduced, without anyone having to manually get the latest code and rebuild.

In addition to the specific practices presented in this book, you and your team should be looking for new and different high-leverage practices that may be unique and helpful to your project. Some ideas build upon or improve existing practices, while others use special tools and scripts purpose-built for your project. The CI server affords the team the ability to run build scripts, unit tests, code analysis, and automated deployments. Most CI servers can be configured to run many automated tasks, and include database scripts, UI tests, and notification e-mails. The idea is to leverage automation as much as possible.

With the CI server running code analysis, a lot of data about the quality of the software is generated. If no one regularly reads and thinks about this data, these reports are not very useful. To gain the full value from code analysis there needs to be an early warning system that processes the data and sends out an alert when important thresholds are exceeded. Building alert systems is a high-leverage practice. Look for issues, such as slowing progress or recurring problems, and think of ways to incorporate an early warning into the alert system. Search for the data and indicators that might help detect future issues and incorporate them into the alert system.

Ironically, after a major issue has been resolved, that is when you read or learn about another project that had the exact same issue. It would be nice to never make the same mistake twice. By learning about the experiences of others, you can prevent issues before they happen. Seek out the advice and expertise of other developers. Use their experience as a high-leverage way to avoid difficult, time-consuming problems.

Automation

As a general practice, convert manual processes to automated processes. For example, if after deployment the integration server needs to be manually configured, have the CI server make the configuration changes after an automated deployment. This prevents misconfigurations and eliminates the need to perform the manual steps. Look at every manual step and consider how that step could be automated.

For individual developers, there are many steps that you might not have automated. For example, many developers create a local development database. With a simple batch file and MSBuild script, the database is created and the database scripts are run in the proper order. The sample code in Chapter 8 provides an example of how this is accomplished. In larger projects, many developers manually create the database and manually run scripts to create or alter the database. Developing automated approaches does take time. However, when multiplied by the number of times the manual method is run and the cost of fixing the manual errors, automating the steps is usually worth it.

For the team leader, automation offers a lot of consistency and saves heartache. Often it is the team leader or a more senior developer who needs to resolve problems created by manual processes. If the server is misconfigured or a developer's database is incorrect then the more experienced team member has to stop and resolve the problem. This reduces the team's overall effectiveness. Instead, provide the team members with simple ways to automate their repetitive tasks. One idea is to have a command file that rebuilds, runs all the unit tests, and performs all the code analysis on the developer's workstation. In this way, the developer is expected to verify that the build will not break before they push their code. The team leader is able to enforce a convention that limits the amount of time wasted by other team members dealing with broken builds and failing unit tests.

Beyond automating the manual steps, there are other ways to automate. One of those ways is through code generation. Entity Framework makes heavy use of code generation.⁵ Microsoft is using a code generation strategy and T4 text templates increasingly within Visual Studio and other applications. More and more, the trends are to use metadata gathered through a rich user interface and turn that metadata into source code. If you think about it, that is the same evolution that took us from punch cards in the early mainframes, to console applications in DOS, to graphical user interfaces in Windows. Each is, in effect, using the computer's increasing ability to automate the input/output to change the entire experience and level of productivity. Developers need to look at new and different practices the same way and find uses for automation in more of the day-to-day development work.

__________

Alert System

The project's alert system provides an early warning for issues, problems, and the need for correction. The continuous integration (CI) server is a foundation upon which you can build an alert system. The CI server collects a lot of data from the build configurations. There are also code quality reports and metrics that the CI server generates. This information can be used to determine key indicators of potential problems. For example, if the number of passing tests drops from 1400 to below 1330 over a two-week period, more than a 5% drop, that drop could be a significant sign. Perhaps one developer is commenting out unit tests rather than fixing them. Code coverage cannot reveal if the logic is properly tested, but it does point to where new code is recently added without any unit tests. The alert system is often most useful to the team lead and the project manager.

The alert system can also help the individual developer. When the CI server gets the latest source code and fails to rebuild, the developer is warned not to get the latest source code until after the build is fixed. Similarly, developers who run the entire suite of unit tests can find issues before pushing their code. This is the alert system identifying a potential problem early enough to prevent disruption and inconvenience to others. For the developer, the various alert systems also include code analysis, quality metrics, and test code coverage.

Like a compass or navigation system, the alert systems help the team to stay on course by making the proper adjustments. Minor issues are dealt with near to when they first occur. The alert system can keep new problems from creeping into the software and help prevent problems from compounding and perpetuating. Also, the alert system helps the team establish a regular practice of following up on issues. By addressing integration issues and failing unit tests early, the monitoring and notification of an alert system improves the entire development process.

It is important that the alert system does not generate a lot of false alarms. It is important to not ignore a failed build or failing unit test. It is much better to resolve the build or failing test than risk ignoring the alarm. Also, when it comes to code analysis metrics, the values that trigger alerts need to change over time. Often, as the team gets better the thresholds are set higher and higher. The alert system is a strategic part of making sure practices stay improved and continue to improve into the future.

Experience and Expertise

Experiential learning is the kind of understanding that comes from encountering and working through the material. Many things can only be understood through experience. New knowledge is gained through involvement in or exposure to a software technology. Skill is gained through practice with the technology. What is described in writing is enhanced and reinforced by the experience. This is an important part of any person's process. Individual team members need time to incorporate what they have learned into their development practices. An effective strategy for any project is to allow time for new tools and technologies to be practiced.

It is interesting to note that people's attitude improves with experience. Initially, a new practice may seem awkward and unproductive. The same is true for a new software tool set. However, with practice and skill development the attitude starts to change. This is because most people do not like the feeling of incompetence they experience before gaining a comfortable level proficiency. During that early period it is common for people to complain and resist. That resistance does not mean the new or different practice is not a better practice. It means that the person is still learning. Provide enough time and space to allow people to try it, learn it, and develop a level of mastery. If the new practice is a better practice then the skeptic will likely become the advocate.

Developers with expertise have acquired a level of technique and skill. Working with these developers affords you the opportunity to learn from their expertise. Look for ways to tap into that expertise to elevate and improve development practices. As a team leader, look for experts who can consult with and train team members. Propose and promote ways to bring that expertise in to work with the team, either through direct mentoring or training. Many projects adopt better practices once a credible expert takes time to share their experience and know-how. Valuing and benefiting from the judgment and wisdom of experts improves and informs development practices.

Summary

In this chapter you learned about better practices focused on strategy. You learned about the importance of brainstorming as a way to engage the power of imagination and new ideas. You learned how planning prevents significant problems and aligns teams with objectives. In addition, you learned about the strategic importance of building capacity and increasing ability, leveraging automation, and developing early warning systems.

In the next chapter you will learn about important .NET Framework guidelines and conventions. These include widely-accepted standards for .NET applications, and guidelines that encourage developer productivity and consistency.