Multi developer Excel projects

Has anyone else worked on a spreadsheet development project where more than one person was developing the spreadsheet part?

I know most of us will have integrated our work with developers of other components, here I’m thinking about you do 1 sheet (or range) they do another?

If so what was it like? how did you run things? did you use source control?

I did one project where there were 2 of us working on the grid part and the VBA. It was a real PITA.

We split up the worksheets and worked on different parts and re-integrated regularly. re-integration was something we dreaded, and over the months a few bits of work just sort of disappeared, or got overwritten with old versions.

We tried having one master copy and taking it in turns to work in that, and to work off-line. We still had to integrate, it was still a pain. We tried pair programming, but basically that was one person typing and one person being very bored. Pair programming works great for complex things, its pretty boring though for the non-driver when the work is fairly mundane.

We both agreed that either one of us could have done the project faster on our own. I would actively avoid this sort of work in the future, unless there was a clear workable way to break down the work so we wouldn’t be tripping over each other all the time.

The best part of our multideveloper spreadsheet project was when the other dev was on holiday and you knew you had the master all week.

The difficulty of multiple developers is one of the real drawbacks of spreadsheets in my mind. Breaking up the tasks to share them out and so reduce the elapsed calendar time is a real challenge because integration can be tough. Unless you know different? Maybe it was just our design? Or maybe the system was too focused and too interdependent?

What do you think?



15 Responses to “Multi developer Excel projects”

  1. Ross Says:

    Just use Grove Simon!? ;-)

  2. Harlan Grove Says:

    I think Ross meant use Groove. At least I hope he did.

    I’ve had the pleasure of doing this two times. It requires all the precision of specification of interfaces between the pieces that any other multiple programmer project does. Even then, it really only works when one person handles the worksheet layout, formatting and formulas and the other writes macros/udfs. And EVERYTHING needs to be done using defined names aside from nearby cell/range references in the formulas.

  3. Dennis Wallentin Says:

    It’s easy to work with other professionals in projects where we have a mixed profiles. As for genuine Excel projects my experience can be summarize with the following:


    Kind regards,

  4. Biggus Dickus Says:

    Impossible !! Maybe that’s more of a statement about me than of the issue at hand, but NO WAY !!

    I have yet to find anyone who would design either a database or a spreadsheet exactly the way I do. The only person that I could work with would be a clone of myself (scary thought) – not because I particularly like myself, but rather because development is such a “personal” thing for me.

    It is MY skills and MY techniques and MY library that allows ME to do what I do for the cost I can do it for. Maybe if I had unlimited time and money I could make it work but that’s not likely to happen…


  5. Marcus Says:

    I’ve only worked on a multi-developer project once. There we’re 2.5 (one was part time) developer’s and myself. Most of my time was probably spent simply coordinating and avoiding conflicts (technical not personnel).

    As this was an add-in, each developer could be delegated a single screen to work on. However there was always the issue of maintaining a constant base of common code. One developer would add an element to a global enumerators or tweak a standard function and forget to tell others and add it to the central repository.

    I’m one in a team of three in one project I’m currently working on. There’s a SQL Server guy, an Informatica guy and I do all the VBA/VB6 stuff. The process flow is linear and we never play in each other’s sandbox. Much better. Importantly, we all sit next to each other, so communication flow is fluid.

    Regards – Marcus

  6. Jon Peltier Says:

    I’ve often had difficulties with multi-developer projects. The habits that make me efficient are incompatible with those that make someone else efficient. We declare variables differently, design classes and file structures differently, etc. I had one coworker once go through my code and add hundreds of comments, the redundant kind, like

    ‘ set bVariable to False
    bVariable = False

    I’ve had another unilaterally change which text files held which information, after we’d already hashed it out and written specs, then not tell me until the demo kept crashing.

    I don’t do a lot of interactive projects like this, since I’m a one-man dev house. But sometimes the client is doing some parts and has engaged me to concentrate on others. With decent specs and mutual trust, it can work, but a lot of time is needed for communication and coordination.

  7. Ross Says:

    I did mean Groove!

    I’ve never worked with another programmer at the same time on a project. I have asked people to work a bit of it out, like can you do me a formula that does xyz, or write some code to handle this, then take that and bung it into the one project.

    I don’t know how it works out in non office developments, what makes excel so different. We looked at various SCM bits a while back when there was talk of doing some project here, but it never really came to much. There seems to be some good info here:
    Is the workbook not a bit like a collection of forms? What is it about Excel that makes it so hard?

    Dick>>Impossible !! Maybe that’s more of a statement about me than of the issue at hand, but NO WAY !!

    Jon>>With decent specs and mutual trust, it can work, but a lot of time is needed for communication and coordination.

    Is it a process thing or is it the underlying technology?

  8. MikeC Says:

    To agree with everyone else, no @!#? way. Once, on a very minor item, was more than enough for me.

    I frequently work in similar projects to the one described by Marcus, where we’re all handling different areas, and that’s fine & dandy.

    I find that part of the problem – to my mind anyway – is one that’s been touched on by the others. It’s a question of style. Not “Cosmo” style, like we spend all day arguing over who has the best hair, but style of working.

    VB/VBA/Excel is “creative”. It’s not as regimented in the same way as e.g. SQL. The way of doing things varies so much from one person to another that it seems impossible to reconcile the differences – or, if not impossible, then more effort and frustration than it’s worth.
    When you’re spending more time talking to each other about what you’re doing than actually doing it, then you’re in trouble…


  9. sam Says:

    I had the same problem. Teamed up with another guy to increase no of avaialble manhours… less than a weeks time we decided that rather than sharing the booty on a project each one us work on independent projects and increase the number of projects we can handle…..

    As already mentioned by Jon and Mike its boils down to Style…what works for you doesnt necessarily work for the other….

    As an eg : I tend to avoid the Offset function to define dynamic names using Index/Counta instead….my colleage has no problems with Offset so we spent a lot of “manhours” arguing ……on who’s right…


  10. Marcus Says:

    It appears that one of the buggest hurdles in multi-developer Excel/VBA projects appears to be the continuous “be reasonable; do it my way” syndrome :P

  11. Jon Peltier Says:

    Even when you’re working on separate items, there is the issue of getting the pieces to work together. Like how’s Excel going to call the other guy’s program in that non-Office, non-VBA app. And how is the Excel data going to get across the interface, and how’s it going to receive the processed data in return. If I’m doing the project, I can tweak the file format, or switch from a worksheet to a CSV. If I’m working with someone, we have to have a phone call, or better yet a GoToMeeting (the best of these collaborative programs I’ve used), and it takes an hour to debate what’s gotta go where, in what order, in what format, in what directory, and who has final responsibility for it.

  12. Dick Kusleika Says:

    I’ve only worked on one collaborative project, but I think it’s do-able. The key is to have one person in charge who defines the layers, inputs, and outputs. For instance, you could assign me a userform. You tell me what information I’m getting and what information I need to spit out and I create a black box. You don’t care how I name my variables because all you see are the properties I expose to you (that you defined). If you do care about my variable names, maybe we shouldn’t be working together. :)

    When I’m done, I export my form and send it to you. You import it and write the interfacing sub.

    I don’t think it’s as easy as that, but with good upfront communication and encapsulation, it seems to be workable.

  13. Harlan Grove Says:

    Problem is the ‘one person in charge’ is all too often clueless about how to develop anything and the result is that the 2 or more people who do know how and would be doing the programming would need the clueless PHB to resolve technical disputes, which means it’d be expedient to dispense with the ‘manager’ and just agree to flip a coin when any disputes arise.

    In nonspreadsheet development projects, it’s possible for different programmers to work on different modules at the same time because the final product, .EXE, .DLL or whatever, could be built from separate source code files.

    OTOH, Excel workbooks, either .XLS or .XLA, are single files. and building them from separate pieces isn’t nearly as simple as compiling a lot of source code files and linking the object modules into a single .EXE or .DLL. Building an Excel workbook from pieces is a manual process, and checking that the pieces all connect to each other correctly is much more difficult. And if you don’t build from separate pieces, you run the risk of one programmer deleting rows/columns from SheetX, for which they’re responsible, and thereby fubarring formulas in SheetY, for which another programmer is responsible, that refer to those rows/columns in SheetX.

  14. Simon Says:

    The code side is very do-able, I meant the spreadsheet grid part. I don’t think more than one person can do the grid side of things without a lot of pain.
    I’ll post a bit about why I think that is.

  15. Dick Kusleika Says:

    Like when you said “more than one person was developing the spreadsheet part?”? Yeah, I don’t read too good. And from that perspective, I agree. One deleted row can reek so much havoc that it’s probably never worth it.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: