C H A P T E R  1

Ruthlessly Helpful

The phrase “best practices” is sometimes difficult to accept. “Best practices” is really a concept that has become a part of the software development vocabulary; however, the phrase can be troublesome because not every best practice is clearly a better practice for all situations. In fact, a practice that improves one situation might worsen another situation. For that reason, this book avoids the phrase “best practices” and favors “ruthlessly helpful practices.” That phrase embodies the idea that a ruthlessly helpful practice for you might not be right for others, which is fine. It embodies an attitude of healthy skepticism, situational relevance, and judgment. In this chapter, you learn just what that phrase means, how it relates to selecting practices, and how to apply that attitude to those areas that you feel need improvement.

The word ruthless serves as a contrast to the passion and bias in the word best. Best is a superlative; there is nothing better than the best. That word is often used to press the point that no other practice needs to be considered. Some use it to shut down discussion and debate. In reality, every new and different practice needs to be carefully considered. To be ruthless, you must discount the biased arguments and zealous opinions. You want to select practices that are right for you and your team.

The word helpful tries to put the focus on results and positive outcomes. In the end, a new and different practice represents a change that must show results. The results could be in fewer problems or faster problem resolution. The results could be improvements in delivery, quality, and relationships. The results could be in greater job satisfaction. You want to select practices that get results for you and your team.

The most important takeaway of this chapter is that this entire book is about how to choose new and different practices that are better practices for you, your team, and your organization. Feel free to call them best practices or ruthlessly helpful practices but, in the end, you ought to see them as the practices that are entirely appropriate to you.

COMMENTARY

Practice Selection

This book presents standards, techniques, and conventions that many professional .NET developers would agree are very good practices. People with different experiences or expertise might believe there are better practices. A ruthlessly helpful practice represents a point-of-view and an assertion that following the given practice is both sensible and beneficial. Common sense dictates that having a set of sound, helpful practices in place today is more useful than spending a lot of time researching and selecting the best practice. It is important to have an efficient way to select new and different practices that focus on improving outcomes.

In the book Rapid Development,¹ Steve McConnell provides a list of 27 best practices. In addition to that list, the book provides tables of many best practice candidates and a summary of best practice evaluations. This is a very comprehensive treatment of the topic of best practices. For commercial software development organizations looking to adopt best practices across the board this approach is a great way to organize the initiative. In Rapid Development, the evaluation of best practices includes five criteria:

____________________

• Potential reduction from nominal schedule
• Improvement in progress visibility
• Effect on schedule risk
• Chance of first-time success
• Chance of long-term success

Steve McConnell's analysis is very complete and clear. However, as that book notes, you need to determine what practices are appropriate for your team and your organization. This is not an easy task.

Based on the principle of triage, this section provides a way of selecting better practices for the individual, the team, and the organization. You are encouraged to use the following four criteria to guide your thinking when evaluating a practice:

• Practicable: Is the practice realistic and feasible in your situation?
• Generally-accepted and widely-used: Is the practice commonly used, understood, and documented?
• Valuable: Is the practice expected to solve problems, improve delivery, increase quality, or mend relationships?
• Archetypal: Is there a clear model with examples to follow?

The reason these criteria are helpful is that they are each indispensable and decisive factors. A practice that cannot be put into practice on a project is not a better practice for that project. Think of these criteria as a way to triage a new and different practice. Better than a list of pros and cons, this set of questions helps to discard best practices that are not right for a given situation. These factors also help to focus your attention on those practices worth pursuing.

Practicable

A ruthlessly helpful practice must be realistic and feasible. One reason a new practice may not be realistic is that the team is not ready to adopt the new practice. For example, continuous deployment requires that the deployments are automated. If the team has not established the practice of automated deployment then advocating for continuous deployments is unrealistic. Select a new practice appropriate to a near-term goal that is within the team's capabilities. Identify the obstacles to implementing those practices and focus the effort on addressing feasibility. In this example, once the practices related to automated deployments are well established then the team is open to discussing continuous deployments as a realistic next step. Assess every new and different practice against what is doable within the team and the organization.

Pointing to a lack of practicality is one way that change is opposed. Once a better practice is seen as realistic and feasible it is important to take the next step and apply the practice. Practical application demonstrates what the new and different practice involves and gives people hands-on experience using the practice. For example, it is not enough to advocate or mandate that unit tests be written. Developers need to be shown practical examples of how to write proper unit tests. The practical application ought to focus on five topics: expectations, standards, resources, acceptance, and consequences.² Table 1-1 provides the practical application topics and a description for each. In addition, this table provides an example for each topic by using the practice of unit testing as an example.

These five topics help eliminate vagueness and engage self-supervision. Individuals clearly see that the new practice is backed up by information that supports their ability and motivation to put the change into practice. In many situations the application of a practice falls down because of a deficiency in one of these subjects. Without acceptance and accountability the practice is irregular and inconsistent. Without resources, developers often do not know how to get started or can get stuck.

Working through these five topics also reveals self-imposed limitations and skepticism. The hidden obstacles that are based on implicit assumptions are drawn out for discussion. For example, a common assumption is that time spent unit testing will reflect poorly on a developer's productivity. That concern can be addressed directly by explaining how unit test coverage and test code review are now part of the change in how a developer's productivity is measured.

____________________

Generally Accepted and Widely Used

A ruthlessly helpful practice is based upon more than just a good idea. Adopting a better practice that is a good idea for one team or organization is certainly commendable. However, if a practice applies only to a specific set of circumstances and is counter-productive in another set of circumstances then it cannot become a widely accepted practice. General adoption is important. Widely used practices have broad application that either reveals that the practice is helpful in many circumstances or describes the situations where the practice is not helpful. For example, in a high-trust environment, where communication and cooperation are good, adopting Agile practices is often successful. In contrast, in a low-trust environment, where there is very little trust and a lot of finger pointing, adopting Agile practices can lead to missed expectations and a lot of bad outcomes. Agile is only a better way of developing software for teams and organizations that share the values and honor the principles outlined in the Agile Manifesto³. When the preconditions exist, generally-accepted and widely-used practices are useful to those project teams that are ready to benefit from the improved practices. The circumstances and preconditions for common practices are better understood and more extensively discussed, which allows you to decide if the practice is appropriate and beneficial to your situation.

The more projects that have adopted a practice the more experience there is to support the practice. You should get a sense of how widely a practice is adopted. The difficulties and objections that block the practice's effectiveness are better understood and documented, and you can benefit from this experience and information. As practitioners write books and blog postings a lot of thought goes into how to properly apply the practice. These are often important retrospectives. Many times the practice starts as an experimental approach that develops into a more generalized approach with deeper understanding and more support.

Take, for example, the practice of continuous integration (CI), which started with discussions about automated builds and a master build script⁴. The automated build server brought down the latest code and ran a build script, making it easier to find integration problems early. Today there are many CI server products that are widely used to run the master build, automate tests, perform code analysis, and automatically deploy the software. Clearly, early adoption of CI practices was beneficial to those projects. The risk for other projects, however, was that early CI practices could have caused significant diversions and distractions. Now that CI is a generally-accepted and widely-used practice the disruption is minimal and the benefits are quickly realized.

Taking a conventional approach has a few additional benefits. One such benefit is in attracting and hiring new developers that have experience and skill in that practice area. Another is that conventional approaches tend to have stronger management support and are easier to gain buy-in from the team members. Overall, generally-accepted and widely-used .NET practices and principles allow you to benefit from the knowledge and experience of others.

Valuable

A ruthlessly helpful practice must show value with respect to achieving desired results. Value is subjective. What one developer values in a given situation is not what another values in a totally different situation. For the developer with complete, clear, and consistent requirements the time spent in an exhaustive review meeting is wasted. For the developer struggling with overly complex requirements, adding in that review meeting to remove unnecessary or overly complex requirements is very valuable. In the second case, the desired result is to help the developer cope with over-specification. This practice helps to achieve that desired result. The key concept is to look at the results the individual, the team, or the organization is currently getting. If you want better results, a change is needed. Any practice that provides more or better desired results is a more valuable practice.

____________________

Take some time to consider what the team needs in order to achieve desired results. For example, a developer who is trying to resolve a defect might need the steps to reproduce the defect or some other missing information. If defects that cannot be reproduced are a systemic problem for a project, a valuable change in practice improves the situation. That practice might regularly provide better steps to reproduce a defect, or involve changing the developer's debugging environment. You ought to value new and different practices by finding the important needs and addressing them.

The gap between the current results and the desired results is another source of value. For example, the team leader might like it if the developers started to follow coding standards. Assuming the coding standards are sensible and beneficial, the team leader wants to find a way to enforce the coding standards. The practice of code analysis, described in Chapter 11, is helpful in this regard. Specifically, the StyleCop tool helps developers adhere to a coding standard and provides a way to automate monitoring. You ought to value new and different practices by finding ways to get the results you would like and wish for.

Archetypal

A ruthlessly helpful practice must provide clear examples that serve as a model to follow. Concepts are usually not enough for individuals and teams to follow. Most developers want and need examples that turn the concepts into real and actionable information. By providing examples, new and different practices communicate the specifics of how to implement the practices. As a team leader, it is important that you find or develop the archetype for team members to follow. The act of creating the archetype helps iron out and prove out the approach by narrowly focusing on any specific impediments.

As an example, let's once again look at the practice of continuous integration. The first step to creating the archetype is selecting a CI server. Chapter 10 provides a list of CI servers worth evaluating. The next steps might involve installing the CI server software, establishing the version control settings, writing the build script, and setting up the notification mechanisms. A narrowly focused test-bed project proves out the CI practice to establish for others a way to learn and understand how all the pieces come together. This project also provides a way to conduct walkthroughs and tutorials aimed at demystifying the continuous integration practices.

One of the greatest benefits of an archetype is that it concentrates on isolating and removing obstacles. The archetype is tangible proof that skeptics cannot deny. For every raised objection or imagined barrier there is now a proven resolution. Because moving from the current status quo to a new and improved situation often requires a tangible demonstration, the archetype helps move toward better practices. In the example of the CI server, general questions like notification options or security or cost are answered with specific examples that allow people to see the new practice both modeled in the proper way and in terms they can appreciate.

Before endorsing a better practice or implementing a new practice, spend some time putting together a prime example that demonstrates the practice. If the practice is ruthlessly helpful then you ought to find that the archetype is complete and clearly supports the practice.

Target Areas for Improvement

There are many ways to improve software development. Some managers suggest an improvement in development costs by having the programming done offshore. That decision can have huge negative implications to delivery, quality, and relationships. In fact, these three aspects are at the source of worsening or dysfunctional software development. A very common complaint is that projects fail to deliver a software product that meets the business need. Others include poor quality and late delivery.

A ruthlessly helpful practice focuses on targeting one of three important areas for improvement:

• Delivery
• Quality
• Relationships

Within each of these target areas there are two general ways by which to show improvement. One is by addressing and reducing problems and the other is through initiative and creativity. Solving problems can generally be thought to include detecting, diagnosing, addressing, and reducing problems. In most situations, it is a lot easier to see problems. People are aware of problems and are willing to acknowledge that an issue is a problem. Innovation can generally be thought to include initiative, novel approaches, ideas, and creativity. Innovation brings change and change is not always easy or welcomed. Consider new and different practices as either solving problems or bringing innovation. People find it less risky to adopt better practices that solve problems. Better practices that innovate frequently offer greater long-term rewards and advantages.

A ruthlessly helpful practice shows improvement by helping to resolve problems with less total effort. For example, a change in practice might help a developer debug, isolate, and diagnose a problem faster. Figure 1-1 is a conceptual diagram that illustrates the impact of better practices on the total effort spent on problems. In the early stages of the project, significant time and effort is devoted to dealing with questions, issues, delays, defects, and other problems. After a few sprints, better practices reduce the total effort devoted to dealing with problems. Later on, introducing additional better practices further improves the situation. Less effort dealing with problems means more time to devote to other important matters. This is growing capability through better problem solving.

Figure 1-1. The impact of better practices on the total effort spent on problems

A ruthlessly helpful practice might show improvement through innovation. For example, a new practice helps a developer write code more efficiently. This means the developer can implement new features faster. Figure 1-2 is a conceptual diagram that illustrates the impact of better practices on the productivity in achieving desired results. In the early stages of the project, results are produced during each sprint. The team believes the productivity can increase with better practices. A new or different practice increases productivity and more is accomplished. Later on, additional changes to practices continue to improve productivity. This is growing capability through innovation.

Figure 1-2. The impact of better practices on productivity in achieving desired results

Delivery

A ruthlessly helpful practice takes the current delivery situation and improves it. Productivity and efficiency are improved. The ability to meet milestones and deadlines is improved. The team can accomplish more with the same or fewer resources. These are ways that better practices improve delivery, which come from better problem solving and innovation.

One thing that often slows down delivery is the time it takes to find and fix problems. The quicker a problem is identified and properly resolved, the greater the capacity to deliver. For example, an important part of unit testing is boundary analysis. As part of unit testing a method, boundary analysis reviews and carefully considers the parameters of the method. A series of test cases ensures that the method works properly under a wide range of expected and unexpected parameter values. In addition, the test code arranges the class-under-test into many expected and unexpected conditions before the method is called. The goal of boundary analysis is to find problems as early as possible by testing the limits of the method-under-test. The developer anticipates potential problems as part of writing the code. The developer makes sure that exceptions are handled properly. This practice reveals potential problems for the developer to address proactively. These are practices that improve delivery by identifying and addressing problems early and efficiently.

Another way a practice can improve delivery is through innovation. Developer productivity tools are an excellent example of how new approaches have increased the developer's capacity to deliver. Many years ago the integrated development environment (IDE) brought together the code editor, compiler, linker, and debugger in what was a new and innovative way of rapidly connecting the source code to the running code. Before the IDE, there was a significant lag time between when code was written and when it was executed. For most developers this delay inhibited productivity. Today the Visual Studio IDE is commonly used and helps developers deliver better software faster. Productivity tools, such as ReSharper and Visual Studio 2010 Productivity Power Tools, offer a wide array of productivity enhancements that further improve a developer's capacity to deliver.

Quality

A ruthlessly helpful practice takes the current quality situation and improves it. The system's fitness-of-purpose, structural quality, or both can be improved by better practices. As with other areas of improvement, the change for the better comes through better problem solving, innovation, or both.

A major quality problem is the introduction of a regression bug, which is a defect that had been found and fixed but is turning up again. The quality perception of the software is damaged by a regression bug. The trust relationship between testers and developers is also hurt. Any practice that prevents regression bugs from making it to the testers solves this particular problem. An example of a solution is the writing of an automated test that verifies that a resolved issue remains resolved. The practice involves writing test code for each and every defect that is reported. The developer assigned to fix the defect must start by writing an automated test that reproduces the defect. The defect is resolved by making sure that this test code passes and all other automated tests continue to pass. This new test now becomes part of the suite of tests that must pass during continuous integration. If the functionality should happen to regress then the CI server will fail the build and the developers must resolve the issue before the defect makes it to the testers.

Adopting a new and different approach is another way to improve quality. The approach does not have to be entirely innovative; it only needs to be innovative for the team and the organization. For example, the practice of engineering analysis is well established, but some teams do not perform the basic analysis and design work before diving into coding. An indispensable step of engineering analysis is making sure the requirements are clearly and fully understood by the developer that has to implement the solution. Another important step is diagramming and describing the solution strategy so as to plan out the work involved. A further step is reviewing the design to make sure it is correct and appropriate. The practice of engineering analysis identifies gaps in requirements and weaknesses in design. In addition, it accelerates development since the proper solution is drawn out before coding starts. Once the plan-of-attack is reviewed and endorsed then the developer is able to work in a self-directed manner toward a quality solution.

Relationships

A ruthlessly helpful practice takes the current relationships and improves them. If individuals interacting are at the heart of software development then the condition of the relationships is a measure of the state of those interactions. Poor relationships lead to poor interactions and counterproductive behavior. Exceptionally good relationships lead to remarkably good interactions and incredibly productive behavior. There are team leaders who can build camaraderie within teams and excellent rapport between teams. These great relationships have everyone enthused and focused on project success. In contrast, for the teams with bad relationships, trust is all but gone and every topic and interaction is filled with misunderstandings and hot-button issues.

Coping with difficult relationships is not easy nor is it enjoyable. However, when individuals and teams are not interacting well, intervention is necessary if the situation is going to improve. A new and different practice ought to address the problem and produce a better outcome. For example, the relationship of the business analyst, developer, and tester is fundamental to creating great software. The practice of focusing on reaching a shared understanding of requirements is helpful: regardless of whatever other differences they might have, the features and functionality are the group's common ground. In this way, the practice moves them away from formal, structured documents and toward a dialog that gets them doing things like diagramming on a whiteboard. This more fluid process breaks down the formality and makes it harder to rigidly hold a position because the members of the group are vigorously confronting the problem, and not each other. A deeper understanding is reached and all sides can collaborate when everyone is better at communicating about the features and functionality.

There are ways to innovate when it comes to relationships. When the relationships are already good then the innovations work to make the relationships better. This is one of the key ideas behind Agile. Teams that have good interactions benefit from the short daily stand-up meetings. The information in these meetings is targeted at providing the minimal and essential status. The stand-up meetings strive to uncover obstacles and barriers to get to early problem solving. The rapid exchange of information and early identification of potential problems that Agile encourages is more efficient and productive. It is not hard to see that in team situations where problems are covered up and concerns are quickly dismissed, Agile is not beneficial. When the circumstances are wrong, the practice is not a helpful innovation. The daily scrum meeting is an innovation for teams that are comfortable talking openly about concerns, believe uncovering problems is a good thing, and feel free to ask for help and support.

Overall Improvement

Beyond any specific area of improvement, a ruthlessly helpful practice can bring overall improvement. A better practice can tie together many development areas. For example, more careful programming through unit testing reduces the system testing effort. Fewer bugs are found, written up, fixed, verified, and tracked. Other practices help strike the balance between spending too little or too much effort in a particular area of development. These practices help make sure that the necessary and sufficient time is spent while avoiding wasteful diversions and distractions.

Other ways that practices provide overall improvement is through renewal and sustainability. Positive improvements and outcomes revitalize the spirit of the team and the organization. The overall atmosphere is more optimistic and engaged. In addition, the result of better practices is a project that is more sustainable over time. Greater productivity and efficiency encourage higher levels of involvement and commitment. As individuals, each team member brings more creativity and energy to the project. These better practices actively improve and encourage sustainable achievement.

Balance

A ruthlessly helpful practice brings a balanced focus on improvement to multiple areas of software development. Inadequate focus on a development area implies that that area does not perform adequately, and the purposes of that area are not achieved. In the other extreme, excessive focus on an area means that too much time and effort are spent, and does not provide added benefit. The balanced approach recognizes the need to spend the proper amount of time and effort in that development area. This approach recognizes the risks associated with too little and the risks associated with too much. The important idea is to identify the purpose and rationale of the development area to ensure that an appropriate amount of time and effort is spent in that area. Furthermore, these benefits are seen as complementary across multiple development areas and the practices bring harmony and improvement to the overall development effort.

Five software development areas are listed in Table 1-2. Next to each area are examples of the consequences of too little focus in that area. On the other extreme are examples of what can happen when there is too much focus in that area. Between these two extremes are the benefits of a balanced approach. The best development practices help bring better results in multiple development areas. For example, the practice of unit testing is helpful to requirements, design, development, quality, and management. As the developer writes the unit tests, the requirements are reviewed, which can reveal incompleteness or confusion. This work prompts questions that are brought out and discussed with the analyst. Unit testing can also drive design improvements as new features are added. The development of tests ensures that the code-under-test is correct and thoroughly implemented. The quality improves since potential defects are identified early by the developer writing the code. Finally, unit testing raises awareness as to how the code is intended to be called by other parts of the system. Writing unit tests helps the developer plan, coordinate, and manage the work. The practice of unit testing clearly ties together many development areas and strengthens the overall process by balancing the focus across these multiple areas.

Renewal

A ruthlessly helpful practice brings a sense of renewal to the team and the organization. For developers on teams that never improve, there is a spirit of hopelessness. The same problems resurface. There is no innovation. As individuals, each developer struggles with these problems and the day-to-day crisis. The team is overwhelmed and unable to implement the changes needed to affect positive change. Adopting new and different practices has the power to change the situation. Making even a modest change offers hope that the development environment is improving. This hope engages the team's optimism. With the implementation of one positive change comes talk of the next practice that is worth adopting. After that comes the next, and so on. Morale and productivity are greatly improved when better practices engage the spirit of renewal and hope.

Many developers are anxious to learn something new. While some are resistant to change, many like the idea of learning a new skill, tool set, or technology. The key is to find the right person to lead the effort to adopt a better practice. For example, automated deployments offer the opportunity to learn about deployment scripts and the associated deployment tools. The developer that has to iron out the problems with unreliable manual deployments is motivated to prevent these problems. That motivation can renew that person's desire to learn better practices. For another developer, a keen interest in doing something entirely new and different is the motivation. In either case, renewal comes in seeing that there is a better set of procedures, and that they are working. The end result is that the team has more reliable deployments, and the developer has a sense of accomplishment.

Adopting better practices makes projects more fun. Any practice that reduces headaches, raises productivity, or brings innovation is a source of enjoyment. Any time the team has more fun, the sense of renewal translates into higher levels of dedication and commitment.

Sustainability

A ruthlessly helpful practice brings sustainability to the team and the organization. In unsustainable situations the result is fatigue, mistakes, burnout, and failure. A poorly-planned project has too much work for too few people in too short a timeframe. The pressure and haste become the driving forces that influence everything the team does. The architecture is driven by haste, which means the high-level design is ill-considered and inadequate. The developers write code under schedule pressure and the result is carelessness, a lack of thoroughness, and poor judgment. For any significant project this constant diet of pressure and haste is unsustainable. When new and different practices focus on problem prevention and more effective issue resolution then the team is less overwhelmed by crisis. Adopting better practices improves planning, coordination, and productivity. Taken together, these improved approaches offer a more sustainable development environment.

For example, projects that are driven by haste often have integration problems that are deferred until late in the project. Some developers do not perform frequent check-ins or do not get the latest code since they do not want to be delayed by integration problems. Other developers push code that breaks the build for other developers. Often the team lead needs to straighten out the growing mess. This scenario is referred to as integration hell⁵. This situation becomes more unsustainable as the code base grows bigger and bigger. One way to address this issue is to change development practices. The team leader insists that all developers check in their code at the end of the day. Early the next day the team leader gets the latest code to a new folder and rebuilds everything. If the build breaks, then the problems get ironed out and the developers figure out whose code needs to change to fix the build. This daily integration prevents the unsustainable situation from continuing, but it also creates a compelling argument for continuous integration. The better practice is to set up a CI server to perform all the same steps that the team leader is performing. Also, this practice supports what many managers value: automation, monitoring, control, consequences, and accountability. The practice of continuous integration is even more compelling if it reveals the code push that broke the build within five minutes of the check-in.

Another way that better practices improve sustainability is in the careers of the developers. Learning better practices is an important part of career development and advancement. As an individual, adopting a better practice that increases productivity and effectiveness translates into better results. For example, purchasing development productivity tools that increase the speed and quality of the code you write helps you write better features faster. That greater rate of accomplishment makes you a more valuable member of the team. Consistently demonstrating positive outcomes for the team is a boost to your reputation that has a long-term benefit to your career. As a team leader, the benefit of having every member of the team improve likewise improves your career.

____________________

Sustainability is about the long-term health of the individual, the team, and the organization. Better practices offer the prospect of reducing burnout and enhancing the overall effectiveness of everyone involved in the project.

Summary

In this chapter, you saw how selecting a new and different practice starts by understanding your current situation. A better practice has to be realistic and feasible within your situation. It is better if that practice is in common use and well documented. The practice ought to solve your current problems or provide innovations that improve delivery, quality, or relationships. A better practice is a model that others can follow with clear examples of how the practice is implemented.

Throughout this book, you will learn about many ruthlessly helpful practices. These practices have application for the individual, the team, and the organization. You can expect that the suggested practice is focused on improving your overall development environment and is targeted toward important areas of improvement. Carefully consider these practices without passion or bias. Do not hesitate to change, adapt, or discard the practice based on your circumstances. You should expect better results from better practices.