Ever since I started writing software code—over two decades ago, but it feels like just the other day—I’ve wondered whether I’m doing it the “right” way. I still haven’t figured out what the right way is—but I’m sure that I’ve done software development in plenty of wrong ways.

When I created my first BASIC program for a college project many years ago, it was a long list of “spaghetti code” hundreds of lines long, with no separation of concerns. (Although object-oriented or service-oriented programming didn’t exist in those days, I could’ve used subroutines to mitigate the problem.) After a disastrous outcome, I quickly learned the value of solving complex problems by weaving together simple pieces.

When I started to write code for a living, I didn’t think to ask clients for written requirements and acceptance criteria. I did months of wasted work assuming that I understood their stated, though undocumented, business needs. I found out that despite good intentions, misunderstandings can occur when objectives aren’t specified and expectations aren’t recorded.

When I started to manage globally distributed teams, I learned that simply reviewing status reports carries no assurance that projects are on track. I realized that visibility has to come from the state of the software and not from a report that someone writes based on conversations with developers. The tricky part, of course, was to be able to create a mechanism so that software state can be defined, measured, and monitored.

When I began working on enterprise projects, I underestimated the difficulty associated with integrating disparate systems and managing complex deployments in outsourced datacenters. The problems became more acute when organizational boundaries needed to be crossed. I learned about the complexity of modern IT environments and how optimistic assumptions about integration and deployment can lead to execution failures and even expensive lawsuits.

Let’s face it. Software development has never been easy and is not getting any easier. The technology learning curve is getting steeper; the requirements for security, interoperability, and availability are increasingly stringent; and project teams are becoming dispersed in multiple locations and time zones. While the tools have improved significantly over time, so has complexity. As a professional software developer, I don’t feel that my job is easier than what it was a decade ago. There are now more wrong ways to develop software development than ever before.

This leads us back to the original question. What is the right way to do software development? There’s no shortage of methodologies and technologies from which to choose. As a community, we’ve made significant progress based on accumulated experience. But independent studies show that the overall success rate for software projects remains stuck between 30 and 35 percent (projects that are completed on time, within budget, and meet requirements).

Perhaps there’s no universal right way to do software development. Perhaps it’s situation-specific. Perhaps it depends on project type, skill level, team structure, motivation, organizational culture, experience, and deadlines. This is what I’ve come to believe. Although we could define a small set of universal “rights” (for example, making code secure) and “wrongs” (shipping code without testing), many of the good and bad practices are context-specific. And some aren’t. The art of project management is defining what makes sense in your environment.

This realization has led me to think about adopting a flexible application lifecycle management (ALM) platform instead of trying to find a silver bullet. While I think that the right strategy is situation-specific, once you define what’s right for a given situation, you need an infrastructure to implement it.

I don’t know of many organizations that can easily create a horizontal ALM platform. Instead, people buy or download individual tools for various pieces of the ALM solution. (The few integrated toolsets available in the market have traditionally been too expensive or too inflexible.) For a long time, I used these individual tools, but always found it difficult to weave them together on an end-to-end basis. Many of the products worked fine as point solutions, but covering the entire software development lifecycle using disparate tools isn’t an easy undertaking. Nor is it efficient.

One day in 2004, I heard about a product called Visual Studio Team System (VSTS) from Microsoft. The server piece of VSTS is called Team Foundation Server (TFS). This is the component responsible for the platform’s ALM capabilities. What impressed me right away was the system’s integrated functionalities—covering the entire software lifecycle. The next welcome feature was its customizability. From that day on, I’ve spent many exhausting days and sleepless nights tinkering with TFS, talking to customers, and thinking about how the product can be used to solve real-life problems.

I wanted to share my observations by writing a book. I wanted to write based on real-life challenges—the learning that comes from the collective experience of the community of software professionals. I tried to capture that knowledge from one-on-one interviews, newsgroup postings, user group meetings, and experimentations with the product.

TFS is an ambitious product. Like any large product, many of its operational, programmable, and extensible features aren’t self-evident. Moreover, customizations and workarounds are sometimes needed to meet specific needs. I wanted to write a book that provided this kind of actionable information to the practitioners.

To me, TFS was a compelling story that had to be told.

I wanted to tell that story.