Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Finding the Source Perfect Source Structure? Handling Change In the Platform

In the southwest United States, Native Americans refer to the combination of corn, beans, and squash as the "Three Sisters." The crops were grown in close proximity because they complemented each other and balanced the nutrients in the soil. This way all three crops could be planted year after year without rotation. Software engineering has its own Three Sisters—source-code management, build automation, and human factors—which are as important to the engineering process as nutrients are to soil, and provide the basis for repeatedly shipping excellent software.

Gaining insight into these aspects of the engineering process can be a make or break situation for a team. The Three Sisters take time and effort, but yield big results in quality and developer productivity. Having recently led an effort to reconstruct and revitalize the software configuration management process within my company (for our e-commerce website), I can attest to the value that is attainable at many levels of the software engineering process.

In this article, I present strategies and insights for source-code management, build automation, and human factors—including tips on how to handle significant project change, regardless of platform. You won't find the theoretical here. Instead, I present real-world pragmatic practices that have worked.

Finding the Source

Taking charge of your source code is integral to software engineering. Before I started the design activities for the new build system, I addressed two glaring issues—an antiquated source-control system and a confusing source-code directory structure.

All source code lived inside of Microsoft's Visual SourceSafe, which didn't provide any benefits beyond a library-like file check-in/check-out system. Replacing this software became a priority and Microsoft's Team Foundation Server (TFS) was brought in as a replacement. Although there are many good available source-control systems—Subversion, Perforce, and SurroundSCM come to mind—TFS provides seamless integration with the Visual Studio.NET IDE on every developer desktop. The introduction of TFS provided a new and improved platform for development and build engineering to expand upon.

Next, the source structure needed refactoring—the website code was mingled with other company code, using namespaces as a folder naming convention. Even though namespace-based folder structuring can sound appealing to .NET and Java projects, it can get out of control and lead to nesting problems. This is not always the case, as namespaces in either language are meant to span physicality. But without being very careful and having a core team responsible for the structure, complexity can sneak in. There's usually enough complexity in the actual application design that it's wise to keep the physical source structure as simple as possible.

A flat-folder structure applied itself well to resolve the folder structuring problem. Each project composing the greater website solution received its own renamed project folder and lived adjacent to the other projects, eliminating all project nesting. Now project groupings happen at a logical level instead of the physical folder level, making the structure less brittle; see Figure 1.

Figure 1: Project groupings.

1 Finding the Source | 2 Perfect Source Structure? | 3 Handling Change In the Platform Next Page

RELATED ARTICLES The Distributed Agile Team Pain Relievers for Continuous Integration and Agile Development Next Generation ALM: Automating the Entire Build and Release Process Complex Requirements On an Agile Project Newsflash: Agilists Write Documentation!		TOP 5 ARTICLES No Top Articles.