Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Imagine the following scenario:

  • Codebase of 600,000 lines of code (C#)
  • All in a single desktop application
  • All written by a single developer (myself) over 8 years (3 years worth of actual coding time).
  • The software is powerful and flexible (obviously vague), thus there is inherent complexity in the code, even if it is modular and low in debt.
  • The software is in a niche machine control industry, so there is a very long ramp up for domain knowledge of both the machines, and the code.
  • The software will become more and more custom where individual customers get their own addons and enhancements

What would be a recommended software team size for a half million line codebase (C# desktop) like the one above? What would be ideal for a typical 500k LOC C# desktop application?

This software is not 'end to end' lifecycle. It is 'end to infinity' meaning it will continue to grow and get bigger and and more powerful and complex. Especially as more engineers are added to the team.

share|improve this question

closed as too broad by Telastyn, MichaelT, Justin Cave, Robert Harvey, GlenH7 Jun 20 '14 at 19:54

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Voting to close as too broad. There are too many questions here for this format. Some will be good, some are likely duplicated elsewhere, and some seem as though they will be too opinion oriented. Since they're together, we can't effectively address the differences. – Telastyn Jun 20 '14 at 17:43
Sure, I will edit down. I am actually looking for opinions, as the information provided is not detailed enough to give much more than opinions. – PassionateEngineer Jun 20 '14 at 17:47
Gotcha, will refactor the question then, thanks – PassionateEngineer Jun 20 '14 at 17:52
That is unfortunately not a good fit for this site. While many of the questions here will have some matter of opinion, they need to be opinion formed from evidence or a "widely held" opinion that could have evidence to back up that assertion. As soon as weasel words like "typical" come into play, it's hard to make a single definitive answer. – Telastyn Jun 20 '14 at 17:55
Maybe if you could let us know why any of this matters to your, we could be more helpful. Otherwise, I don't see why anyone needs to answer this at the moment. Hire a dev or two and see how it goes. If the business needs more, get more. Are you going for funding or selling it or do you just like doing personnel budgets? – JeffO Jun 20 '14 at 18:09
up vote 9 down vote accepted

Size of the code base isn't really the right metric for determining team size. Rather, look at the size of your backlog. If you're still handling customer requests in a time frame that makes them happy, then a team size of one is all you need. If you're losing money because you can't fulfill customer requests in time, then you add people until that's no longer the case, obviously taking the mythical man month effect into account. It will take several months before you know if a newly trained team can handle your workload.

Where exactly that line is depends on the business more than the app, although obviously there is some correlation with app size and complexity. For example, refactoring a messy code base will enable you to fulfill customer requests more quickly, but maybe not quickly enough to avoid hiring additional team members.

share|improve this answer
That is actually an excellent answer to a question that really does not have a correct answer (as indicated in comments earlier, it is an opinion based question with lacking information) – PassionateEngineer Jun 20 '14 at 18:18
+1, that's exactly what I was thinking when I read the question. – Doc Brown Jun 20 '14 at 19:10

The code size is not atypical for a single person three year project (as in, I've seen a few C++ projects with a similar number of semi-colons developed by single people in two or three years).

As with anything, the team size maintenance and feature enhancements will depend on several parameters, including

  • How much money there is to throw at it
  • How quickly enhancements need to be delivered
  • How well factored the code is
    • is there a plug-in system, or even a scripting system for domain experts to add code without having to be software engineers?
    • is the code modular so tasks such as 'tidy up the dialogs' can be done by coders without domain knowledge?
    • are there systems in the organisation for establishing specifications so expert testers can be brought it who are not domain experts?
  • How many features are required to be added?

Almost none of these actually depends on the code size, but on the quality. In my experience, larger projects developed by single authors over many years tend to be somewhat idiosyncratic and don't automatically get the features required for opening up to larger teams ( so I now try to stop getting to being the only dev on large projects ).

share|improve this answer
I couldn't agree more with this: "projects developed by single authors over many years tend to be somewhat idiosyncratic and don't automatically get the features required for opening up to larger teams" – PassionateEngineer Jun 20 '14 at 18:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.