Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Building a Robust Development Environment


Stephen is a software engineer at CDW focusing on web scalability and best practices. He is also a founder of the Chicago Architects Group and can be reached at [email protected].


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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.