Lesson Learned: Single Builder

On our installation of our vehicle technology at the Alpine Executive Center, Dizzi and I both worked on things. Dizzi made the routes, which are represented in notecards. She put scripts into the cog rail and tested it and built a rezzer for it at one point. (Now that I think of it, she did most of the work. Yay, Dizzi!) But things got pretty tangled up sometimes.

I wrote most of the scripts that go in a vehicle, but not all of them. Dizzi wrote some new scripts, and found reasons to modify some of my scripts, and often the reasons were good. Sometimes I wouldn’t agree with the way a change was made, or even with the approach taken. The result of all this is that there are upwards of a dozen different scripts, many of which all appear in the locomotive or rail car, with a few showing up in rezzers or maps.

Dizzi and I can edit each others objects. On the other hand, we want the scripts to be secure, because they contain techniques that we consider proprietary. Between our own security and the fact that we were working under the AEC group, and with the help of SL’s limited permissions, we often found ourselves in a situation where one of us needed to make a change but was unable to because at least one of the elements needed had the wrong permissions.

Now I was taught programming according to the “Agile” approach, so I believe strongly in shared code and shared responsibility. That doesn’t mean that every change she made to my code made me feel good: it didn’t. Her programming style and mine are very different, and while if we had actually been programming together the results would probably have pleased us both, working separately left bumps and seams in the code. Worse yet, the permissions system wouldn’t let us quickly share and discuss anyway.

One thing I think I’d do next is to have a single person responsible for building all the objects to be placed in the installation. That individual would have all the scripts and other components, and would assemble the released objects and rez them. Other people on the project might experiment and build test objects, but when things were ready for deployment (either final or in testing mode), they would go through the Single Builder. 

The good thing about this approach is that there would at least be one person who could edit everything. As things went for us, there wound up being things that neither of us could edit alone, and in order to edit everything, it took both of us. Very frustrating. 

The bad thing about the Single Builder idea is that it puts a big burden on the builder,  because they have the administrative hassle of making things, but also because they are the only one who can jump in and get things done. 

At this point, I feel that a Single Builder approach would have kept things smoother as we got to the end, but would have been less convenient when we were not both around. Possibly during the project we could divide the work so that both could work freely and then integrate once in a while using Single Builder: that’s not clear. 

Right now, though, Single Builder is the best idea I have for this aspect. Comments are open. Help me out with better ideas.