Chapter 13. Keeping the momentum
- Balancing refactoring and new features
- Knowing (and pushing) your team’s limitations
- Fitting refactoring into the schedule
- Moving to a culture of quality
It’s been quite a journey. You’ve worked your way through source control, automated tests, object-oriented concepts, user interfaces, and data access. For the final chapter, we’re going to set aside the code and circle back to some of the softer aspects of brownfield applications that we mentioned in chapter 1 and make sure you can keep the enthusiasm of your team high.
So, for the last time, let’s talk about pain.
13.1. Pain points
It may seem odd to talk about pain points when the chapter won’t be discussing utilities or concepts. But waning enthusiasm is probably the most important pain point you’ll experience if you don’t work actively to avoid it.
It’s common to start a brownfield project with a lot of enthusiasm. The existing team is heartened by the fact that the code they’ve been mired in during the last 6 to 18 months will finally be fixed. New team members bring a renewed energy. Perhaps even the client is onboard with the promise of an app that will be “even better.”
Six months into the project, things look a little differently (see figure 13.1). Yes, the application might be in a slightly better state. The code is probably a little cleaner in the version control system (VCS), and maybe there are unit tests and even a continuous integration server. Perhaps some of the forms have been refactored to an MVP pattern.
Figure 13.1. Without a consistent and conscientious effort to improve, a brownfield application reverts back to its old self very quickly.
But watching the team’s day-to-day efforts, it becomes clear that they’re no better off than before the brownfield project started. A looming deadline early on forced them to cut corners. The client changed requirements at the last minute. One of the team members didn’t see any benefits from the early work and went back to his old cut-and-paste habits. Another latched on to the latest framework without considering whether the team had the cycles or the core knowledge to maintain it, so certain sections of the app look vastly different than others.
In short, although there may be minor improvements to either the ecosystem or pockets of the code, the project has reverted back to its previous path. So it’s critical that the team maintain the early momentum it builds up. Maintaining any momentum gained can involve drastically changing your course.
13.2. Changing your course
Consider a young boy running down a hillside. At the top of the hill, he points himself in a vague direction, but after that, his course is pretty much set by gravity and physics until he hits the bottom. He barrels down the slope barely able to get his legs under him as he runs, let alone consider what direction he’s going.
A brownfield project is a lot like that—but instead of a cute, uncoordinated little boy, it’s a large, lumbering, three-ton beast barreling down the side of a mountain at the speed of a freight train.
And it’s your job to change its course.
You have two options. The first is to throw up a roadblock in an attempt to stop the beast so you can start fresh on a new course. If the roadblock is high and strong enough, the beast will stop with a thud and knock himself silly. If he manages to get up, maybe he wanders around in a daze for a little while before tearing down the mountain again on a different path—the correct path, we hope, but there are a lot of ways down a mountain and only one is the correct way.
If the roadblock isn’t strong enough, the beast will crash right through it because of the momentum he’s built up. He may stumble or flinch a bit, perhaps veering off in the right direction for a few steps, but eventually he reverts back to his original path of destruction (see figure 13.2).
Figure 13.2. Once a large project has built up momentum, it’s hard to make drastic changes. The beast will crash right through most roadblocks you put up.
The second way to change the beast’s course is through small nudges at regular intervals. You look at the end goal: where you want him to end up. Every so often, you give the beast a little push in that direction and he changes his course slightly each time. By the time he reaches the bottom, you’ve provided enough tiny course corrections that he ends up exactly where you wanted (see figure 13.3).
Figure 13.3. Nudging a project to change its course slowly and steadily over time provides a smoother transition than an all-at-once, or “big bang,” approach.
With this method, there’s no expectation that the beast (your project) will quickly go the direction you want. Instead, you need a clear goal in mind and a plan for how to reach it—not just “We need to make things better so let’s add unit tests.” Our suggestion is to continually nudge the project so that you end up as close to your desired endpoint as possible. Throughout the book, we’ve repeatedly suggested the use of incremental change techniques. Incremental changes are the implementation of those nudges that your project needs.
One of the most important things you can do is manage your team’s expectations. Good intentions alone won’t sustain a brownfield project. What you need is a dedicated, directed, and, just as important, long-term effort by everyone involved. There must be more than a vague “We’re going to do things differently from now on” resolution made in a fit of year-end budget planning and justification.
All too often, development teams dive into a brownfield application expecting to see instant results. When those results don’t come as quickly as expected, a team can get frustrated and revert back to what they feel are tried-and-true methods.
Despite your head brimming with all the possibilities we’ve spent 12 chapters outlining, proceed with caution. In our opinion, each of the topics that we’ve covered has an excellent improvement-to-effort ratio. Each will take time both to implement and to realize the benefits. It’s imperative that the team realizes this going in.
Now that you’ve held your horses, let’s talk about how to walk before you run.
The importance of setting expectations
We can’t stress this point enough. If you’re creating a specific goal to make your codebase more maintainable, it’s vital that everyone be in for the long haul.
The reason is that a failed brownfield project can be dangerous. As discussed in chapter 1, morale is a factor in brownfield applications. If you think the morale of your team/ project manager/client is low at the beginning of a brownfield project, consider what it’ll be like if you lift their hopes, then fail yet again due to unrealistic expectations.
It’s difficult to recover from a failed brownfield project. In many cases, your project manager or client may be leery about spending time to clean up what, to them, could be a working application. If you spend good money with long-term promises of maintainability and you don’t follow through on those promises, you’ve doomed not only your project but all future brownfield projects.
Clients expect results for their money (they’re funny that way). If you don’t deliver, they have a good case to be cautious the next time some young upstart asks for leeway so they can “make things better.”
13.3. Setting the pace
When planning your path, the dynamics of the development team is crucial. Not everyone works at the same pace or has the same experience (and the two aren’t necessarily, or often, correlated). Perhaps the eager developer can race through code but often forgets edge cases. The senior consultant spends a lot of time at a whiteboard before putting finger to keyboard. Two others are productive when they pair together but aren’t nearly so effective on their own.
The point is, you must evaluate your team’s current velocity before you can commit to making the changes outlined in this book. How much solid work can the team do under normal conditions? Does the team work at a steady pace? Does the code often have bugs? Are existing bugs being squashed regularly or do they give rise to more bugs? If your company is located near Banff, does productivity drop off drastically in the first two weeks of snowboarding season?
Furthermore, the team’s underlying capabilities must also be taken into account. Take on only what you’re capable of. Although your collective heads may be brimming with possibilities, it’s vital that you curb your enthusiasm until you’ve spent enough time researching each new concept.
The good news is that each chapter in this book talks about a stand-alone concept that can be implemented when the team is ready. For example, you can start by researching VCSs and how to use them effectively. When you feel you have a good grasp on the concept, try implementing (or moving toward) a more efficient folder structure in your existing VCS. If you aren’t happy with your current system, consider moving to a new one.
Once you have a handle on your version control, start looking into continuous integration (CI). Then move on to the rest of your ecosystem. After that, you can investigate ways to layer your application and try refactoring the UI and the data access layer. Many of these topics build on earlier ones (see figure 13.4), but none of them needs to be done in tandem with another.
Figure 13.4. Each topic lays a foundation for the one above it. Make sure you have a good grasp of each one before moving on.
The important thing is to work at a pace you can handle. Yes, the code will still be in a bit of a tizzy in the early stages, and you may feel physical pain looking at it. But consider the alternative. If the team tries to do too much, too quickly, you’ll be worse off than you were before. You’ll have an application with incorrect versions of third-party libraries in version control, a CI process that does only half of what you need it to do, tests that are ignored, dependency injection used in some places and not others, and some parts of applications in appropriate layers and others in their original state. In short, it’ll still be a mess, but this time it’ll be an inconsistent mess.
The dangers of “too much, too fast”
It’s possible to cripple a project if you take on too much at once. Sometimes this happens when one small refactoring leads to another slightly larger one, then to a larger one, until you are re-architecting the application just so you can populate a list box in a maintainable way.
These cumulative refactoring binges often leave the project in a dysfunctional state. We’ve been on both ends of the conversation that ends “I just need to finish up one small refactoring, then we’ll be good to go” while the rest of the team waits patiently for an application that works.
So to borrow from Aesop, slow and steady will win this race, especially at the beginning. Make sure the entire team is comfortable with the state of affairs before introducing a new change into the mix.
Another important aspect is a regular review of the work you’ve done. Whether or not you’re doing this now, it’s a good idea to get together as a team periodically to make sure everyone is still comfortable working with the code (or, at least, no less comfortable than before).
The purpose of the periodical review isn’t necessarily a code review (although code reviews can be beneficial in certain scenarios). Rather, it should be a discussion of overall changes to the codebase since the last meeting and what’s planned before the next one. Team members can also voice their successes, failures, and concerns.
Here’s a list of sample questions that could be addressed:
- What major shifts in architecture have been introduced?
- Is everyone familiar with (and happy with) the check-in process?
- Does anyone have questions about the ORM you’re in the process of adding to the project?
- Are you at a stage where you can introduce an MVP pattern to the UI?
- Does anyone feel they need some mentoring on the recent changes made to the code?
- Is everyone convinced that real value has been added with the new concepts?
This meeting is also an excellent opportunity to review any code metrics you’re tracking. Chapter 5 talked about how to use code metrics to get an overall sense of your project and what areas could be improved with a minimal effort. Your brownfield progress review meetings are an opportune time to review those metrics to learn how to address the problem areas and see whether the practices you’ve implemented have made a difference.
These meetings aren’t meant to be formal. They’re round-table discussions to make sure you’re on track and still delivering value. It’s okay—and even encouraged—to rely on gut feeling.
By the same token, don’t leave anything unsaid if you’re uneasy about something. As the adage goes, there are no stupid questions. For example, perhaps you don’t feel comfortable implementing an IoC container this early in the project. Maybe you aren’t clear on the concept yet and need more time to try it out in a controlled environment. You might feel a lunch ‘n’ learn session would help get the team on the same page. It is incumbent on you to mention this at the progress review meeting.
Time box the meeting
Brownfield review meetings can get out of hand for many reasons. Team members could disagree on an implementation of a design principle, there may be different ideas on what areas of the application to clean up next—heck, your team may just plain not get along.
It’s important to recognize when a discussion isn’t furthering the goal and needs to be set aside. (It’s also important that you follow up on the issue, something that’s often forgotten in the heat of a discussion.) Be sure you leave enough time to address the major points of whatever agenda you have set.
In the next section, we’ll take a common mind-set to task: the “spring cleaning” phase.
13.4. The “spring cleaning” iteration
When a brownfield application gets to the point where the team decides direct action is needed to get it back on track, there’s often a tendency to initiate a “refactoring iteration”: for the next iteration, no new features will be added and no bugs directly addressed. Instead, the team will spend all day, every day, simply refactoring the application to clean up this mess. The intent is that future iterations will be that much easier because of the work you put in up front.
This approach is the “too much, too fast” issue taken to the project level and isn’t what we generally refer to as a good idea.
There are several problems with this approach. First, it’s naive to assume you can fix all, or even some, of your brownfield issues in a single iteration. If you can accomplish this, we’d question if what you’re working on is a brownfield application at all. You’d be hard pressed to implement even half the topics in this book in a reasonable amount of time, especially if the team is not well versed in them. Like the basket of cleaning products in figure 13.5, the number of options you have can be overwhelming.
Figure 13.5. No one likes spring cleaning. So don’t do it.
Second, we feel that a spring cleaning iteration is a little insulting to your client. You’re essentially admitting to them that the application is in such a sorry state that no further work can be done on it until the code is cleaned up. Whether or not that’s actually true, you shouldn’t hold the client accountable for it.
Finally, very often areas needing refactoring are found in the normal course of work. If you take out the day-to-day interaction with the code, you’ll lose sight of what made the application hard to work with on a regular basis.
Instead, you should fall back on an idea we’ve mentioned before: changing the team’s culture. A better approach than initiating a refactoring iteration is to look at your development process as a continuous process. Indeed, this is why the process is often called continuous integration. From this day forward, your team is making a collective effort to do three things:
- Add new code that’s maintainable
- Make any old code you touch maintainable
- Eliminate pain and friction in your processes
Essentially, you’re making a pact with your team. This pact states that you’ll continue to work on new features and bug fixes but that you won’t stand for any process or code that causes you pain or friction. Any time you can’t do what you want to do easily, you promise to take a long hard look at why that is and make every effort to fix it.
Chapter 6 talked about introducing a culture of quality in your team to fight your defect backlog. In that process you instill the ideal that you won’t tolerate defective code. This objective is worth reiterating here because much can be gained by achieving this goal. A developer who will make a genuine effort to remove duplication, reduce friction, and eliminate pain points has skills that extend far beyond the current brownfield application.
Tales from the trenches: “We can’t do it”
A common defense against changing your culture to use many of the techniques we’ve discussed in this book is “Our team won’t be able to absorb that much information.” In our experience this claim is usually false. Sure, we’ve seen situations where some people on the team are either so resistant to change or so uninterested in augmenting their skills that they can’t make the transition. But more often we’ve discovered that the team as a whole can make the leap to a new culture.
On one project, none of the developers had experience with any of the practices outlined in this book. Some had heard talk of things like unit testing and test-driven development, but none had ever attempted these practices. That was about to change.
Initially the learning curve was steep, painful even, and littered with lessons that needed to be learned, repeated, and instilled until they were as natural as riding a bike. In the span of 6 to 8 months, the development team had converted its practices to be in line with what you’ve read so far in the book. That team is proof that it can be done and that no past experience is needed to make this transition.
Furthermore, by the time they wound down and left the project, the developers on the team were strong advocates of the practices presented here. They may not have had all the knowledge and experience necessary to head off and teach others, but they did have the passion. As one put it shortly after he’d moved on to another project: “It’s made development fun again.”
Remember that. Developing software doesn’t have to be filled with pain and angst on a daily basis. Make it fun by killing as many pain points as you can.
Changing your team’s culture isn’t easy to achieve. It’s frighteningly easy to become complacent and fall back on old habits in a brownfield application. Phrases like “I know exactly where to fix this. I don’t need to write tests for it first,” or “Ugh, I don’t want to deal with this mess right now, I’ll just add a TODO comment and get my work done” often run through our heads. You might feel like the extra bit of knowledge you’ve gained on object-oriented practices gives you license to forget the basics. After all, it may not be perfect but at least it’s better than the way it was, right?
This thinking highlights a common attitude when you get a few months into a brownfield application. You’ll start to recognize problem areas and even potential solutions, but you don’t feel comfortable enough making the required changes just yet, out of fear either that you’ll do it the wrong way or that you’ll take too long and launch a refactoring binge. Instead you stick to the tried-and-true method in the hope that the code will blend in with its surroundings until someone else deals with it.
What if not everybody is on board?
We’ve made a large leap of faith assuming everyone will accept the extra time and effort required to bring both the team and the application up to a more maintainable state. Anyone from a team member to a project manager to a client could poison that effort with a simple “I don’t buy it.”
There’s no way to sugarcoat it. This attitude is a problem—potentially a big one. You can’t ignore it, and if after all your efforts you can’t convert the naysayer(s), you have some tough decisions to make.
The easiest case is when the dissenter is another developer. It may seem harsh, but if the entire team is in agreement except for one person, you simply have to make that person go away. Whether that’s by moving him or her to another team or something more drastic, someone who’s working daily with the code and isn’t totally committed to improving it has no business being on the team. This is just an extension of the pain point aspect of your pact: if something (or someone) is causing pain, find the cause and remove it.
If the party pooper is a project manager or your client, you’ll have to be more discreet or diplomatic in your efforts. It’s possible to make progress on a brownfield project without support from above, but you’ll be seriously limited in the scope of the changes you can make. If the objections are coming from the client, it may be a reaction rooted in their lack of confidence in the project team due to past failures. Although it can take longer, starting by setting a track record for consistent, high-quality, and timely deliveries sets a strong stage for clients accepting your suggestions.
Or, and we’re only partially kidding, find another job. As one highly skilled developer we know says, “Change your environment, or change your environment.”
A common counterargument to all this evangelism is our old nemesis, the clock. We’ll tackle that now.
13.5. Making the time
We can hear the counterargument now: “This talk of culture and continuous improvement is all well and good, but I have to get back to the real world.” Given that you’re still expected to deliver value in the form of new features and fixed bugs, it can seem futile to fit time in to fix vast, embedded architectural problems when all you need to do is modify the validation rule for a text box.
One seemingly counterintuitive way to make time is to pull in another team member and collaborate. Almost everyone has encountered the phenomenon of “talking it out,” whereby a solution to a problem presents itself simply by explaining it to another person. And if it doesn’t, now there are two people who are aware of the problem and you can work through it together (see figure 13.6).
Figure 13.6. Pair programming is an excellent way to introduce new concepts to a team.
Furthermore, developers working in a group are far less likely to knowingly introduce bad code. Admit it, when no one was looking, you’ve checked in code you weren’t proud of. Would you’ve done it if a peer had been looking over your shoulder while you wrote it?
When talking a problem out with someone, you’ll often discover a simple solution. The act of learning together will help you both further your understanding of design principles, unit-testing techniques, object-relational mappers, or what have you.
It could very well be that you decide the code isn’t in a good state, or the team isn’t quite ready, to refactor it completely. This is perfectly acceptable. In the early stages of your efforts, you’ll need some trial and error to balance refactoring and new features.
But it’s rare that nothing can be done now. For example, maybe you aren’t at the stage where you can implement an IoC container, but that shouldn’t stop you from refactoring some responsibilities out of a monster method into their own classes.
Both Martin Fowler’s Refactoring: Improving the Design of Existing Code (Addison-Wesley Professional, 1999) and Michael Feathers’ Working Effectively with Legacy Code (Prentice Hall PTR, 2004) provide excellent techniques for quick refactorings that can provide a lot of improvement for little effort. More importantly, these refactorings can set the stage for later when you can finish the work you start today.
The important thing is not to forge ahead the way you did before. Instead, make the time to analyze and evaluate the code you’re working on instead of dumping in code by rote.
In the early stages, frequent collaboration with the team will be useful. Formal meetings aren’t needed, but quick discussions, maybe around a whiteboard, about what’s working and what’s not are. Harness the power of the hallway conversation. If you find a good blog post about how to refactor dependencies, share it. If you find a new way to structure your build file and want to try it out, get together with a co-worker and start playing.
Communication between the team members, whether at an individual or a group level, will greatly improve the team’s ability to implement change and improve a floundering project. Don’t stop with sharing ideas via email or Instant Messenger. Get together on a daily basis and have every developer on the team briefly state what they’re doing and submit any potential questions or problems they may have. Keep it quick and stick with it for the duration of the project. Soon developers and other team members will see that this face-to-face method of communication really works and can keep the team’s momentum flowing.
It may seem as if bringing other people in will reduce your efficacy, but you’ll often find that the opposite is true. If two people work on a problem, many times they’ll accomplish more than if they both worked on two problems separately. And in almost every case, the resulting code will be cleaner.
Earlier in the chapter we mentioned that change will involve a serious shift in expectations all the way up the chain of command. Quick fixes may not be quite so quick at first, but you must persevere. Like learning any new skill, learning to do things the right way takes time and practice, but over time it becomes easier. And you’ll eventually become aware that bug fixes and features don’t take as long as they once did.
Before we close the book, we thought it would be fun to revisit our hapless developer from the preface of the book who had just started with Twilight Stars and was facing some dire prospects.
13.6. A milestone retrospective
A blank email form stares back at you from your computer screen. The project manager, Jackson, has asked for everyone’s input on what worked and what didn’t work for the most recent version release of the Twilight Stars flagship product. As you reflect on the experience, you can’t help but smile. The team has come a long way in a short time.
After the debacle that was phase 1, you had a serious discussion with Jackson, as well as Martin, the client. This was one of your early successes; Martin had long since stopped talking directly with the development team by that point. During that conversation, you asserted yourself more than you had in the past. Without getting emotional, you laid out the issues with phase 1, including, but not limited to the following:
- The length of time it takes to get up and running for a new developer
- The lack of a coherent defect tracking system
- Recurring bugs due to fragile layering
- Inconsistent application of unit and integration tests
The underlying theme, you said, was a lack of confidence in the application from all members of the team. Over the course of 2 hours, you made a passionate plea to Jackson and Martin to allow you 6 months to try to repair this lost confidence, not with silver bullet solutions, but with a directed effort to change the mentality of the entire team. They agreed, thanks in no small part to your claim that deliverables would continue, though with more direct involvement from Martin on prioritization.
13.6.1. Early success
You knew the road to success would require long-term gains to make the process maintainable, as well as quick wins to show progress. To handle the latter, you focused on the ecosystem to help close the feedback loop for potential problems.
To prepare for the new developers brought in to replace the recently departed ones, you reorganized the source code tree in your VCS so that they wouldn’t have to go through the same pain you did to get up and running. By the time the first developer arrived, she was able to retrieve the latest version of the code from the VCS and compile the application with no further steps.
Once that was in place, it was almost trivial to add the project to a continuous integration server. Initially, all it did was retrieve the latest version of the code and compile it, but that was enough to start the shift in mind-set for the team. Once email notifications started appearing whenever the application wouldn’t compile, developers quickly learned the value of following the check-in dance before each check-in.
To counter any possible trepidation in the process, you added a bit of levity to the CI process. Whenever a build failed, you configured the CI server to play the chorus from “Broken” by Evanescence over a loudspeaker in the team room.
Don’t go overboard
Despite your good intentions, we don’t suggest playing a song over the loudspeaker for very long. It will quickly become a huge distraction to anyone who is heads-down in coding mode. There are other, less intrusive, ways to keep the team informed of the build status. For example, some teams use a large screen in the team room that displays the build status at all times.
An application such as Big Visible Cruise (http://code.google.com/p/bigvisiblecruise), which provides an easy visualization for projects that use the CruiseControl CI product, would also help.
After adding CI, you introduced a test project into the mix so that any failing tests would also produce a failing build. Coupled with the CI environment, this was an important step in the project; it meant that the team would put a much greater effort into not only testing their code but automating those tests.
13.6.2. Introducing and maintaining a culture of quality
The ensuing weeks were a tough ride. The existing code was highly coupled and nearly impossible to test. The team’s frustration was palpable as they constantly peppered you with questions about how to add tests for new features in code, a step that was traditionally done in a web page’s code-behind file against a static data access class. It required a few lunch ‘n’ learns, several one-on-one/pairing sessions, and regular code reviews just to get many of them to the point where they were confident enough to check in code more regularly than once a week. A careful review of the current application’s architecture and a discussion of how the various layers should look was necessary in order to move things forward.
And although one or two of them took to it very quickly, a couple resisted the move to automated tests and continued the way they normally had, writing untested code. It wasn’t until you incorporated code coverage into the automated build to report any major drops in the percentage of untested code that they began to take the idea seriously.
When the team members started to get the hang of automated testing and were familiar with some of the common object-oriented principles (especially single responsibility), you instituted weekly meetings to review the defects and code statistics. It was another uphill battle convincing team members to take defects seriously, and you had to lead by example. You chuckle when you recall the look on Jackson’s face when you outright refused to take on a new feature because three new bugs were logged against the most recent milestone.
After that, it was much easier to get the team on board with the same line of thinking. When, after 4 weeks, the defect list shrank slightly, you’d have thought your team had won the Super Bowl.
13.6.3. Every rose has some thorns
Despite your successes, there were some bumps in the road. Productivity in the early stages dropped significantly, causing the team to miss deliverables for the first two milestones. The client, Martin, was initially critical of your performance because of this. Yes, you were able to demonstrate that the deliverables you did achieve had fewer defects reported, but given the project’s history, he wasn’t sympathetic to your plight. Now, with the release behind you, relations are still tense but Martin has admitted, tentatively and grudgingly, that he is on board with the new focus on quality. Your team’s near-feverish disdain for defects has helped in this regard.
Then there was the now-infamous ORM debacle. Having enjoyed much early success setting up the ecosystem and teaching the team about layering, you got cocky. One afternoon, you introduced an ORM into your codebase in an attempt to rid yourself of the bug-ridden data access strategy that currently poisoned the application.
The move was met with an almost instant and universal pushback. The development team, still reeling from many other new concepts, had no idea how to debug issues that arose in classes that used the mapper. And the DBA steadfastly refused to grant appropriate table-level permissions you requested to implement your data access strategy.
Although you still believe that moving to an ORM is the correct path for the project, you now realize what social and political barriers you’ll face when you next try to make this transition. The end result of this effort was only an afternoon of lost code, but a valuable lesson was learned.
13.6.4. Increasing confidence
Still, you had to admit the progress was tremendous. One needed only to look at the deployment to production. For the previous release, the team needed a weekend-long outage with several infrastructure people on call. For this one, it was almost a nonevent. You created a build script to deploy the relevant components to the appropriate servers. Included in the release were database update scripts and configuration files.
Before the release, you began practicing the deployment on a test environment. When the kinks were worked out, all that needed to be done was to create a build configuration for the production environment. Once that was done, deployment was, literally, a single command in the console. The ease with which you deployed the application went a long way to improving relations with both the project manager and the client.
Now you’re facing a blank email message on your screen, thinking how you can summarize the previous release succinctly. In the end, you focus on the confidence gained: confidence the team has in its direction and confidence that the client has gained in the product. There’s a greater sense of code ownership from the developers and an improvement in everyone’s standards. Successes have been steady, and failures have been reversible. Much remains to be done, but you feel confident that this brownfield application is on the right path.
13.7. Summary
This chapter has been a departure from the code-centric ones of late but necessarily so. A successful project is more than the sum of the ecosystem, architecture, and design of the application. As developers who are more comfortable with code than in meeting rooms, it’s all too easy to ignore the fact that real people have a stake in the application and have different goals than you do.
In this chapter, we returned to the softer side of brownfield projects to explore ways to keep the team motivated over the long haul. Remember that during an extended development process, which most are, falling back into the old practices that originally tainted the codebase can happen. Fight that possibility by setting expectations at all levels of the project stakeholders group.
When setting expectations, try to enable working in small, indiscernible ways that all contribute to the larger goals. Although the temptation will be to make sweeping changes to achieve the stated goals, remember that you still have to deliver software to your clients. Don’t let the desired work effort interfere with that delivery, but also don’t allow the delivery to interfere with the goals of the work effort. It’s a fine line that requires you to ensure that you have clear and frequent communication occurring between the development team and the rest of the project stakeholders.
Our journey is over. We’ve taken the walrus’s advice from Alice in Wonderland and talked of many things. It’s our sincere hope that you’ll be able to take at least some of the techniques in this book and apply them to your brownfield project successfully. (We won’t begrudge your applying them to your greenfield projects either.)
Better yet, we hope we have piqued your curiosity enough to look into the topics in more detail. Although we’ve tried to focus on fundamentals, which are less affected by the technology changes that define our industry, new ways of approaching old problems constantly arise. We wish you luck and success in your application and feel certain that you are now able to approach obstacles with confidence.