CODEWITHSUNDEEP
project-managementproject-planning
Stefan Sveidqvist
Stefan Sveidqvist

Reputation: 3544

How do you measure a small, big, very big project?

I am reading Code Complete as well as a couple of other programming books at the moment. The size of the project affects a lot of other parameters that you need to take heed of in planning, coding, automating tests, etc. I was wondering what people on SO generally use in the real world to categorize a project in its correct "weight class"?

Is it lines of code? Number of external interfaces? Necessary pages of documentation?

Upvotes: 7

Views: 2207

Answers (7)

meade
meade

Reputation: 23311

It could be a combination of things:

  • est. function points - size of the code
  • integration points - with external systems
  • complexity of application (web apps are typically less complex than embedded systems - compare a web site to a program for a rocket ship)
  • business groups involved - a small change needing approval from 20 business units could be a big effort

The above would determine project size - the number of people determine timeline and add complexity

Upvotes: 2

Garry Shutler
Garry Shutler

Reputation: 32698

I would say it's the amount of development effort required. Taking a team of six developers:

  • Small project - up to 6 months
  • Big project - 6-18 months
  • Very big project - 18+ months

Everyone will have a different opinion though.

Edit

I was thinking about how those values would change for a 1 developer "team". I think they would be along the lines of:

  • Small project - up to 1 month
  • Big project - 1-3 months
  • Very big project - 3+ months

This seems to suggest that for small numbers of developers the rule of thumb for project size might be:

  • Small project - up to 1 month per developer
  • Big project - 1-3 months per developer
  • Very big project - 3+ months per developer

I doubt this scales beyond 6 or so developers though as the number of communication channels starts to drag on the potential development time of each person. Effectively leading to less work done per month per developer the more people you have in your team.

Upvotes: 10

MrTelly
MrTelly

Reputation: 14865

It's a kind of left idea, but when I'm working on a project I envisage it as being

1) A house = small project

2) A supermarkert = medium size project

3) An airport = big project

You kind of know by the people around you, what you and they are doing, and your chances of success which of the three you're on.

Upvotes: 0

shoosh
shoosh

Reputation: 78914

The learning curve - The amount of time a new developer takes to get acquainted with code before he can do something useful to contribute to it.

Upvotes: 2

MikeW
MikeW

Reputation: 5922

I wouldn't begin to know how to estimate the lines of code expected on a project. Documentation... what's that ;) So for me, none of those things.

I would probably count the major functional areas, and look at a rough idea of the number of screens/pages and also a rough idea of the number of database tables. The database complexity might be a good indicator on a lot of projects I think.

Upvotes: 0

danpker
danpker

Reputation: 613

I would usually measure the size of a project on the time it would take to complete, but other people may be different.

Upvotes: 2

cgreeno
cgreeno

Reputation: 32371

I would say Time and Manpower.

Upvotes: 6

Related Questions