Channels ▼
RSS

Design

Other Voices: Staying On Track While Everything Changes


Mike Shepherd is a configuration management specialist for PureCM Software Configuration Management.


Change, then change again: It's a story familiar to developer managers everywhere. Projects are getting bigger and more complex. Developers are striving to reduce time-to-market, and squeeze releases out ever faster to keep pace with the market's demands for new functionality.

What's more, customers aren't prepared to wait until Q2 next year for a major release, to get the next batch of features built into the solution. They'd like them now, thanks very much -- while reserving the right to change the feature set at any time. In these accelerated circumstances, speed of development is not just about the coding; there's an ever-growing emphasis on how you manage your teams and the overall development process.

Keeping up with these external and internal demands means setting clear ground rules, both for individual developers and teams. For example, what should happen when a developer has finished their part of the coding? How often should new code be shared within the team? Who should review it, and when? Should the build happen every time code is checked in?

And from the manager's viewpoint, the issues go still further. There's the need to ensure the code is reproducible. To select and manage the features that will make it into the final release of the code, to set up the pre-release checklist, and perform any necessary security or compliance audits on the application.

So how do you keep serene, and keep pace? And ensure your team is working in harmony towards the same goals -- and deadlines -- without conflicts emerging, or developers getting sidetracked? The approach will depend on your development philosophy, and that of your team -- such as whether you embrace agile development or use more traditional methods. But there are techniques that can benefit any development team, and help them to be nimbler and more responsive to changing demands.

A matrix of development issues versus best practice, to enable rapid response to changes.

Here are my five suggestions on how developer managers (and their teams) can stay fully in control of fast-moving projects.

Give Developers Their Own (Work)space

A desirable feature is for developers to have their own sandbox, or workspace, so they can build and test changes before they are integrated. This speeds up development -- and so much the better if changes can be highlighted and reconciled automatically, enabling several developers to work on the same file concurrently. This approach enhances quality by allowing developers to build and test as they go along, prevents errors caused by incomplete submits, and increases productivity by allowing developers to work concurrently.

The right tool should also group individual file changes into a "changeset", making it easier to see and understand what has changed, and why, compared with the traditional approach of separate file changes. If changesets can be linked to the original change request to enhance transparency, even better.

This method gives the flexibility for developers to handle multiple tasks. For example, if an urgent bug fix comes in, developers can park their current work in a changeset, deal with the urgent fix, and then return to exactly where they left off, with all their files and changes preserved so they can re-start quickly.

Consistency Matters

As well as helping developers do their job more efficiently, the CM tool should also aid developer managers in ensuring processes are consistent across his teams -- giving the manager a top-level view of the status of current versions, who is working on what at a given time, and so on.

A key point is to have a configuration management (CM) solution that helps development teams work the way they want to -- and doesn't force them to change the way they work. Can the solution integrate with the build tools your team is using, to save time, give rapid feedback about successful or failing builds, and avoid the risk of errors creeping in from having to constantly switch from one application to another?

Track Packages, Not Individual Changes

In the same way that the task-based approach, described earlier, benefits developers by grouping related changes into changesets, it also benefits the manager by giving an automated, real-time audit trail of changes and the ability to retrieve a configuration when needed -- even when no label was created.

The changesets show the evolution of every project over time, including who made the change, why it was made, and to which files. This helps to put all the changes made in a project into context, in turn making it easier to match them to change requests. If the changesets are fully self-contained, they simplify rollbacks and parallel development,

As well as giving you better control of large or distributed teams, you get better transparency and easier status reporting. It's also a boon when revisiting older projects.

Parallel Lines

A common opinion about parallel development is that it's complex, lacks transparency, and creates an administrative headache in trying to track all the branching and merging.

But it doesn't have to be like that. With the workspace- and stream-based approach I've described, it's possible to isolate teams to work on different streams of a project, so they can edit, build and test separately. Then features can be merged back into the main code stream when ready. This also lets you decide what features you include in, or omit from, a release.

The key is to be able to keep different code streams in sync with each other so, for example, accepted changes could be shared automatically between streams. But done correctly, this means a broken build in one area doesn't stop the entire team from working. What's more, any bugs or unfinished changes stay contained in a stream, and don't spread to your whole project. So even if you're not a fan of parallel development, you can still use its techniques to your benefit.

Centralize and Share Code

Key to all of the suggestions I've made here is a central repository for all code in a project. As well as ensuring every developer is working on the same version, it also enables two short-cuts that can really save you time: the re-use of code and sharing components between projects.

The chances are that your team has worked on a project with elements that can be quickly adapted for a new project. If you're able to take a folder or component from one stream and share it with another, while automatically managing any changes or updates that are needed while the component is being worked on, then your team can capitalise on work it has already done, and boost its efficiency.

In conclusion, change is inevitable. But with the right processes and tools in place, you'll be better placed to take change in your stride, without it throwing you off course.


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.
 

Video