Team Development: release higher quality apps faster while your competitors crown the next boy band

[dturchin]

Every Boeing 767 has 3.1 million parts of which about a million are screws. Developing enterprise software makes me yearn for simpler pursuits like building airplanes. Let's just say the mechanics union would mutiny if every screw's shape and size was determined at runtime, drill bits were spread around the world with manuals in seven languages, and using a flat-head instead of a Phillips could lead not just to defective planes but to planes compiling into Cuisinarts.

In a frustratingly recursive kind of way, enterprise software is so complex because it starts with nothing and requires layering infinite, variable increments of work on top of that nothing. Then each layer spawns its own infinite, variable increments of work. It's like those kids stuck in that Escher painting in the Take on Me video (children of the eighties unite).

We've spent more than forty years theorizing and modeling and proposing and fixing how to organize teams to organize code to ship great software. Even so, we're as far from having achieved consensus as ever. In recent years, the agile movement led to continuous integration for release management and DevOps for cloud architectures. They're all useful but we know the next wave of ideas will soon crowd them out. In fact, strip away codeland's version of the boy band and what's left is teams of developers, architects, and designers collaborating to write and manage code.

At ServiceNow, we don't know who will replace McFly (or even DevOps) but we do know making it easier for teams of developers to work in parallel leads to shorter development cycles, increased predictability, and higher quality code. That's why we're introducing Team Development, a radically simple way to manage software projects that marries the sophistication of a modern, native cloud app dev platform with GitHub-like familiarity and ease of use.

Team Development creates relationships between ServiceNow instances that let teams working on the same features, releases, or code work in tandem without needing to manage conflicts manually. By establishing a development hub as the parent of children, each developer working on a child instance can push changes upstream while Team Development watches the state of every child instance to make sure the parent remains free of conflicts.

Here's how it works: let's say we have four instances for development, staging, testing, and production. Production and test are on version 1.0 while stage is on 1.1 and the development hub is on 1.2. See diagram. When production needs a bug fix it can parent with test so the fix can be made then pulled from test to parent. Meanwhile, the main development thread, version 1.2, remains on the development hub and when it's ready for staging and testing those instances can parent with it and pull down 1.2. No need to incrementally patch and manage changes at a feature or file level.

Individual developers have quick access to the version they need and they can't push changes upstream without first pulling downstream. As a result, conflicts are proactively managed, parent instances always remain conflict-free, developers no longer need to schedule tasks to avoid working on files concurrently, and release managers no longer risk delays due to unresolved conflicts.

What I like most about Team Development is it transcends the boy band debates about development methodology and addresses the real problem: developing enterprise software is hard and the best way to make it easier is to help teams collaborate.