If you have a software project, of any reasonably large size, chances are you have multiple developers working on various portions of the source code at the same time.
This means that, if you’re smart, you’ve got some good source control system in place — such as Git or SVN — that handles the merging of the various changes together from all developers involved. A system that, for the most part, works well enough to get the job done.
But can this entire paradigm be improved upon?
As work began on the next major version of Illumination Software Creator, this seemed like a good opportunity to re-think how multiple programmers can work on the same project in a faster, more collaborative and error-proof way. Here, I’ll walk through how we are approaching things in Illumination 7.0.
This is rather lengthy. But if you are interested in the topic, or in the new functionality in Illumination, read on!
Now, it should be noted, right from the start, that Illumination Software Creator is a very different beast than traditional programming languages. It is focused on visualizing the logic of your software — by stringing together Lego-like blocks of functionality — and abstracting out the underpinnings of any given target platform. So this particular approach to having multiple programmers collaborate on a project may not apply to a language such as C++ or Ruby.
== Live Updating ==
The first thing we wanted to do away with was the notion of needing to “merge” multiple versions of the same “source code” together. At least… as much as possible.
Merging typically works pretty well in most source control systems. But when it doesn’t work… it REALLY doesn’t work. The results can be pretty annoying and time consuming to fix.
The solution we opted to go with, at least for scenarios where all developers could be online, was to have a singular project that all programmers could interactive with… live. It works something like this:
1) You load up Illumination Software Creator and connect to a “Project Server”.
2) You then can interact with the project however you like — adding, modifying or removing functionality.
3) As you do this those changes are made visible (in real time) to all other people with the same project open.
This provides a number of, obvious, benefits in terms of multi-developer collaboration. It is, in essence, what Pair Programming and Extreme Programming is all about. In our testing this has proven to be an incredible boon for programmer productivity (Illumination is actually built in itself at this point, so we’ve been “eating our own dogfood”).
[That screen-shot is from Illumination 6. Imagine seeing changes from a group of developers happening in real-time. It's a beautiful thing.]
But that’s not really a complete solution. There are a few other mechanisms that need to be in place in order to make this into a truly usable system for large-scale projects.
== Dibs ==
The first is something that we call “Dibs”.
If you plan to be making significant changes to an area of a project, you simply select that area (Illumination is a visual environment, so you can simply select a given rectangular region — or specific blocks of functionality — visually) and “Declare Dibs”.
At this point all others working on the project will see that you are working in that area and are unable to make changes until you “Release Dibs”.
Pretty simple, really. But the changes that you make are still “live updated” for every other person working on the project. What if you are making changes that cause the software you are building to no longer function correctly? What if other programmers want to continue testing the software out while you make those changes?
The solution proved to be quite simple. You can simply toggle between two different states for any area that someone else currently has “dibs” on: “Live Changes” (meaning you will be testing with, and seeing, the changes as they are applied) or “Prior to Dibs” (meaning the area that someone has declared dibs on is locked in the same state that it was at until the dibs is released).
Which, in a way, is similar to how checkins work in standard source control systems. Except a bit more flexible.
== Change History Per Person ==
All changes, for every person working on the project, are logged. They can be removed (temporarily or permanently) one change at a time (such as, say, changing the value of a single variable) or in bulk (by selecting multiple changes).
This makes things similar to old-school “revert”ing. Except with more granular control.
In order to make this easier, though, changes can be organized in two ways:
1) By Dibs – So you can roll back all changes done during a particular dibs.
2) By Date – So you can find changes made at a given date/time.
== Alerts ==
What if you are working on a *really* large project and want to be alerted whenever anyone makes a change to a particular area of the project (such as specific visual regions of the project, specific functional blocks or specific variables)?
Wouldn’t it be awesome if you could get an alert whenever this happens to an area you declare is important to you? We call these, simply, “Alerts”. And there’s a lot of really handy uses for them. Most notably:
1) Tell you whenever someone touches an area that you are responsible for.
2) Tell you whenever a piece of functionality you depend on gets updated.
Alerts are delivered in Illumination itself as well as via email (optional).
== Offline Mode ==
Obviously we can’t always be connected 100% of the time.
So we implemented an “Offline Mode” that acts exactly like when you are connected. The only difference being that updates are not live and the changes are stored up until the next time you connect… at which point your changes are added to the project and you are shown the changes that others have made.
Just like with traditional programming languages and source control… the longer you are “offline” (aka “Go without updating or checking in”) the higher the likelihood that someone will end up clobbering someone else’s changes. Luckily the granularity of each individual changes, and the nature of visual programming, does alleviate this issue somewhat.
== Chat, Notes and Doodles ==
This is a visual environment. So why not play to that strength?
As you might have guessed you can draw on your project. Talking with a co-worker about a specific piece of code? Circle it. Want someone to arrange things differently? Draw some arrows. Don’t like what Randy, in the cubicle next to you, did to a piece of the project? Draw a big frowny face over his changes.
These are “Doodles”. And they can be toggled on and off (globally and per-person) at any time.
We also have “Notes” which are simply post-it style notes that you can place anywhere. Within the Illumination project itself, these are used in a variety of ways beyond simple comments. We also use them for laying out the project based on the feature backlog. The notes are also searchable, so you can find a note telling you about a specific feature or milestone. If you work in an Agile-like environment, this proves quite handy.
There is also live “Chat”. This is chat. Just like you might have with IRC or IM. There is nothing ground-breaking or revolutionary here. It’s just handy to have a secure, logged, searchable chat that programmers can use when working on a project together.
== That’s It ==
These approaches are proving to be extremely powerful in a visual programming environment. Some of them could be applied to to traditional, old-school programming languages and source control system. But many are pretty visual and would be hard to do in a non-visual environment.
These changes are all part of Illumination Software Creator 7, which is currently in closed Beta testing (being rolled out only to individuals and companies who are enrolled in the Illumination support plans). I would be a jerk if I didn’t also mention the following:
1) Illumination 7 is a free upgrade for everyone who picks up a copy of Illumination 6 (the current version).
2) The price for Illumination will be increasing when 7.0 ships. Which will be happening very, very soon.