Fog Creek Software
Discussion Board

Divide and conquer: builders and assemblers

I would like to ask this community their opinions on dividing development teams into those who build, and those who assemble.  Yes assemblers could be said to be builders, but please apply this distinction:

Builder: Builds parts.
Assembler: Assemble parts into applications/systems.

By "parts" I mean a piece of software that provides some function and can stand alone as a re-usable part.  This is different from the method of delivery of that part, which may or may not be a component (eg: COM/CORBA/Bean).

An Assembler does not build parts, just the bindings between the parts that are needed to make a whole application or system. If they require a part, they see the Builder / "Parts" team for it. 

I would like to see more organisations adopt this division.

Do you use this division in your current environment ?

Do you see any merit in this approach ?

Do you see any problems in this approach ?

If you dont do it now, why not ?

Yes I am deliberately leaving this wide open so as not to influence the replies.

I look forward to your replies.

James Ladd
Thursday, February 7, 2002

One role that seems to be left out is that of an architect: who is responsible for analyzing the problem and breaking it down into components?  Who decides which modules should be built, and in what order? 

Leaving this up to the builders, or the assemblers, or both as they go along would seemly lend itself to a hodgepodge, bottom-up, on-the-fly design where modules are created on an ad hoc basis as they are perceived to be needed.

"Builders and assemblers" seems to be useful only to a certain subset of projects: namely, those in which writing the "glue code" is as much work as writing "the code that does stuff" -- or, more succinctly, projects in which integration is as big a problem as implementation.  When no one is responsible for the overall arcitecture, integration problems like these are exactly what you expect.

I am more comfortable with a top-down "skeleton and body" construction in which the initial (small and highly skilled) team is responsible for analyzing the requirements, generating a skeleton design framework for the problem, and identifying the high-risk areas that should be prioritized.  They then break out full implementation of features into managable tasks and assign them individually to a larger body of implementors who need not be as skilled or experienced.  As each feature is completed, it is integrated into the project.  At all times the trunk is buildable, although not all of the functionality may be present.

Your suggestion doesn't seem to give this 100% visibilty throughout the lifetime of the project.  Furthermore, "builders and assemblers" in my opinion sounds like a false bifurbication between "implementors and implementors", instead of "implementors and designers" as it should be.

Friday, February 8, 2002

I can see a bunch of problems with this approach.  The main one I can see is that the builders could easily become insulated from the business goals, and go off into their own little world which may have no relation to the issues that the customers want. Too many layers might make them too far removed from customer deadlines too. (I can see the assemblers being responsible for meeting the deadlines, but not having the control they need to do the job).

I can also see that their might be a bit of a political rift between the two groups, where the assemblers will bitch about the shortcomings of the components supplied, and the builders will look down on the assemblers as glue operators rather than real programers.  This might be avoided by regular rotation between the groups (but them again it might not be).

Jamie Anstice
Friday, February 8, 2002

I really think you'd have a problem with getting good programmers to work in such isolation from the problem scope. There is nothing I (personally) hate more than not understanding where in a particular puzzle my piece fits, and it seems that builders would have to live in such a bubble if it's ever to become an efficient modus operandi.

Also, if you've hired a person for their analytical skills and ability to break down problems, I have a hard time understanding why you _wouldn't_ want them thinking about the entire problem scope and focusing on ways to develop a better solution. Yes, your answer lets you make use of lesser tallented people in possibly more roles, but honestly, do you really want to keep those people around anyway?

Alex Russell
Friday, February 8, 2002

I agree with what Jamie said, that if the builders and assemblers were cross skilled then it might be OK.
But given this requirement why bother with the split?
Just have builders who can also assemble and assemblers who can also build and do away with the differentiation.

So I think I'm anti the idea.

Friday, February 8, 2002

Although most software engineers would cringe at the idea, this is actually something of a management holy grail you are trying to find. The respsonses I've read so far indicate it, that certainly the engineers that read joel's website seem to dislike being unable to architect portions of the software. God forbid what the slashdotters would say :-P

That said, I have tried this approach with some of my software teams, with varied success. I'm still trying to figure out what the ideal set of division and ownership is for different types of projects.

I do, however, like the idea in principle, but there are lots of issues with the actual implementation. You'll run into roadblocks from both technological and political forces. This approach is inevitable and it's only a matter of time before software is "built" piecemeal. How much time remains to be seen.

One thing to keep in mind is that specialized pieces of software are quite easy to build (Hence, the large number of Open Source "me too!" projects). The complexity in software intensive systems usually comes from the actual INTEGRATION of various pieces. This is where little (sometimes tiny!) design decisions made at different points of component design will come back and bite you in the behind. Complexity is introduced during what you are referring to as the "assembly" portion of the sofware writing, and is not as trivial as simply "gluing" the software together. This is why the software industry has resorted to iterative development. It's because it's difficult to simply "glue stuff" together. Interaction rules are often difficult to predict in a large software system, and it is precisely why software projects take so long. Hence, the mantra "Integrate Early, Build Daily."

James Wann
Friday, February 8, 2002

Most organizations already use this approach, don't they? It's just that the builders work for some other company, from which the components are purchased. Very few projects that I've seen are built entirely from scratch.

I'm not sure it makes sense to have dedicated builders on staff unless there's a steady demand in your organization for components that will be re-used across more than one project. Otherwise it makes more sense to outsource the building to companies that specialize in such things and resell the components to multiple customers.

Mike Gunderloy
Friday, February 8, 2002

I've actually worked this way on three different software projects, all of which were all very sucessful. One major, major benefit came out of this approach - it taught me how to _really_ write decoupled software components, some of which were not only "reusable", but were actually reused later on. I need to add that there were only two developers on this project, so communication between builder and integrator was optimal.

While "readability" (as vague as it is) has the greatest effect on ease/difficulty of maintenance, I believe that decoupling comes in close second. So this is a big issue (if you agree).

I bet the idea of each developer wearing an _interchangable_ "builder" or "integrator" hat at any time, i.e. knowing exactly which role they are playing, can help result in better code also on larger teams. Actually, I know that for a fact, because that is how I have worked since then.

So, I certainly do like this, not as a "methodology" or a team structure, nor as the successor to common sense, just as a way of thinking about what role you're playing that helps move towards higher overall code quality.

Johannes Bjerregaard
Friday, February 8, 2002

I've read one theory of team development (was it XP? can't rember) that said that there should be a tool builder and component builder role on the team.  I definitely like building components and tools to make my life easier. 

The danger of developing in a vacuum is always there.  There's no technological solution to improving communication.  I'm pretty sure there's no organization or process that can guarantee better communication.    It's just this painful (for some of us, myself included) thing that's totally essential to having a good team.

I'd say that if you have someone on your team who actually likes being someone who builds components, and the rest of your team wants to delegate some tasks to the component guy, then that's great.  The component builder role could work out if the team commits to communicating well.

Gordon Weakliem
Friday, February 8, 2002

In THE MYTHICAL MAN-MONTH, Fred Brooks discusses a 1971 proposal from Harlan Mills that software teams be set up like surgical teams, with specialists for each task. Brooks suggests these roles for the team:

Editor (for the written documentation)
2 secretaries
Program Clerk
Language Lawyer

The trick appears to be to keep from getting a team that consists of four surgeons, three language lawyers, and a toolsmith.

Mike Gunderloy
Friday, February 8, 2002

Firstly, thankyou to those of you who replied to my question. I have found the discussion very valuable.

I still see this division working. I see an architect as a pivitol point in the scheme of things.  I would see builders and assemblers changing teams as needed and, I would see requirements as the communications between these divisions, vetted by the architect.  I would hope that this would improve quality and productivity.

Thanks again for replying, and I hope I can provide usefull comments to any questions posted.  Thanks to Joel to.

James Ladd
Sunday, February 10, 2002

Meh. I'm an assembler.

I've been using Dreamweaver Ultradev.

Dreamweaver Ultradev makes simple little ASP and ColdFusion, and JSP (and PHP if you download the extentions) pages. You just slot the things into the page. The things it doesn't do by default you can make an extention for, or download and extention.

At the end of it, you can look in the Server Behaviours box and see all the behaviours that make all the non-html code in the page. All seperate components, all clear and simple.

It's like Duplo... or a jigsaw. Or something.

The beauty of it, is that if you think it builds crappy code etc, build an extention that'll do it your way, and do it for you - handy.

The only thing that can be boring is feeling like you are just putting Duplo together, but I've realised I can play around with extentions a bit more, have a bit of fun with it making things...

Monday, February 11, 2002

*  Recent Topics

*  Fog Creek Home