Java Developers on Ulitzer

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.

Keep calm and carry on
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.

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

#1: 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.

#2: 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?

#3: 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.

#4: 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.

#5: 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.