The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

One product, many different repositories

I work for a government contractor.  My particular department made most of its money from a single product that was developed with roughly 150 man-years of effort.  As the product became more well-known, several government agencies decided they wanted tailored versions.

Our solution? Copy each version of the code into a new repository (not a branch, but a new repository), and then continuing tailoring and doing new development on each independently.  It is rare to see improvements/bug fixes propagate from one repository to any other.

Starting way back in 2003 when I was a wet-behind-the-ears recent grad, I started warning senior software engineers and architects that maintaining multiple repositories would be needlessly expensive and difficult, but no one listened.  They argued that each customer had different needs, and my suggestion to focus on creating a centralized, reusable library of components was impractical.

Flash forward to last week, and now people are talking about starting a 14th repository for a new flavor of our product.

Am I completely out of whack, or is it a really bad idea for a (currently) 30 developer department to be maintaining 14 different repositories of what is essentially the same product?  Any ideas of what we should do now that we're where we are?
Mai Hedd-Hurtz Send private email
Friday, April 25, 2008
 
 
As often, good questions give rise to follow up questions:-)

First, some observations of mine:
a - your department seems to miss an architect in person.
Judging from the architects I worked with (some 20, including the uml amigos), s/he would massively push a central repository for at least accross-customer-reusable assets.

b - goverments = usually more stable requirements
From my personal observations, govermental organizations change slowlier than private ones. On the bad side this leads to a longer sales cycle but on the good side of it they don't want as many changes as private/economy customers in comparison.

c - product & project manager
Am I right assuming you have both roles embodied in one person and every customer has a different contact person? That might be the explanation why noone complained so far. Plus: I kindly disagree that there is no real reuse happening already, but there are no mechanisms to keep track of it - it might be done in the head of the single developer who reuses a trick/code he did for another customer by cut&paste.

Second, some questions to get you starting:
q1 - how much cut&paste between repositories does happen in your department?
q2 - how do the diff reports look like if I compare two repositories? (All repositories?)
q3 - what are your release cycles? Do you send updates to your customers on a regular basis?
q4 - what are your companies growth plans?  I mean, if they are happy with 14 customers and don't want more, how could they grow?

Third, don't worry too much:-)
Here's a nice story that might show your companies future (and why they keep on going like they did): http://www.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/FiveDaysoftheFishDec00.pdf
IMHO, you're right to be worried. On the other hand, most humans try to stick to the status quo if not urged to move.  And, if you find some answers to the questions you also have some ammunition for future debates & discussions.

Kind regards,
Volker
Volker Kopetzky Send private email
Friday, April 25, 2008
 
 
No, you're not out of whack, they are. I have no good advice though as your problem is how to deal with the people, not a technical one.

See if you can get them to do the 14th as a shared repository with whichever existing one they would copy - as a test case?

(BTW - great sig. Maybe you should leave your job and join the staff here: http://www.cartalk.com/content/about/credits/credits.html )
:)
sgf
Friday, April 25, 2008
 
 
To answer Volker's questions:

a) Do we have any architects?
Yes, we had one who was just promoted to "technical director" and we promoted at least two more to be "architects".

b) Most of the projects have long release cycles -- I'd say two releases a year at most.

c) We don't differentiate between product and project manager.

q1) How much copy and paste?  Last year I did a big analysis looking at the original repository with PMD and found a *TON* of copy/paste within that repository.  Huge sections, hundreds of lines long could be found in multiple modules.  I presented this data to software engineers and management several times (with slides, Excel spreadsheets, etc), but they said that it would be too expensive to fix.

q2) The GUIs and output look pretty similar across most projects.  Some projects do have additional options or abilities.

q3) Release cycles, again, vary, but I'd say no more than twice a year for the vast majority.  Customers basically just want it to "work" -- refactoring is difficult to get authorized by management because they don't want to pay for / test  the same code twice.

q4) Growth is stagnant and management states that budgets are very tight and they are desperate to get new business.  I suggested that the more modular oour code, the cheaper it would be to enter new fields -- my division manager clearly disagreed, though his boss seemed to be at least open to the possibility.
Mai Hedd-Hurtz Send private email
Friday, April 25, 2008
 
 
Our company manages about 7 OEM-specific versions from a single codebase.  Some of the OEMs have different features.  We use #defines in some places to manage the differences, and some of the differences are handled at runtime.  We have been successful in this and while I think we're pretty good, I don't think that we are perfect by any stretch of the imagination.

I think that having 14 depots with identical code is pretty crazy.  What are you using for source control?  Sophisticated systems should be able to handle enormous repositories, with multiple branches, etc,.
T Send private email
Friday, April 25, 2008
 
 
We mainly use CVS (one or two projects use subversion).
Mai Hedd-Hurtz Send private email
Friday, April 25, 2008
 
 
Central versus a distributed approach to development would depend 50% on the design and architecture of the software code libary and 50% on the depth of customization needed over time by the 14 groups. You would need to answer both of these to come up with an answer as to whether its better to clone them and let them each evolve, or whether all or part of the central codebase or libaries can sustain all 14 repositories. If the latter is found to be true in part, only then would I push to contain part of all of the codebase and builds in a managed centralized repository.

For example, if the product is one compiled system and must support allot of demands and customization, then better to release copies or clones and let these groups do what they like. If you find the project has been desgned around any sort of modular structure, then it would be possible to centrally manage say the base classes or builds, then allow each group to develop modules, while you maintain control over the framework or base code. Thats what I would look at. If there isnt any value in managing parts of the codebase this way and parsing out modules to these groups, then might be better to release it as you are doing now.

All this should have been thought through by the original architects. If they had anticipated this type of scenario, they should have built a more modular application to support a managed code problem like this.

Im not even an architect, but I always build all my products around a carefully architected library or codebase of classes and assemblies I build myself, and which allow me, over time, to bolt on modules which provide the different featuresets. Same for the UI layer. Its all separated out so I can grow the base code separate from teh modules and the visual UI. This hopefully allows my customers to get better updates and versioning and buy and even develop their own modules, as well as skins without jeopardizing the central architecture, which I maintain and who's code quality, performance and efficientcy I can control separate from all those crazy developers who in the case of many open source projects, create buggy blatware. Seems like thats kinda what you might be trying to avoid, but seems its heading that way times 14, huh?
Gemini
Saturday, April 26, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz