How large an application can one developer build?

Gliddador

Member
Joined
Jan 22, 2023
Messages
22
Programming Experience
5-10
It is known that many, large applications were built by teams of developers, that in the time it took them, these applications could not have been built by one. Therefore, I ask you: What is the limit for the size of applications for a single developer to build them?
 
With or without access to Google, StackOverflow, and other Internet learning resources?

With or without open source?

With or without code generators?

How much time does the developer have?

How much work-life balance does the developer have?

Does the developer have to have at least 80% unit test code coverage?

Does the have to have 100% integration test code coverage?

Does the developer have to do his own integration testing?

Does the developer have to run his code through static code analysis for security issues? Does the developer have to fix those issues?

Does the developer have to subject his code to fuzz testing and pen testing? Does the developer have to fix security issues revealed by that testing?

Does the installer or deployment script count as part of the application?

Does the developer have to do the deployment himself?

If the developer does have to do the deployment himself, our the deployers allowed to bug the developer when the deployment doesn't work?

Does the developer have to design the UI?

Does the developer have to write the user documention?

Does the developer have to fix bug reports and handle feature requests from users while still doing development?

Does the developer have to report to management about their progress daily and show demos every two weeks or once a month?
 
Last edited:
Any application takes a certain number of man hours to create. If you have a team of developers, those hours are shared. If there's only one developer, they have to do all the hours. How many hours have you got? That's the limit for the size of the application you can build.
 
And as I've trying to imply with my post #2, how many of those man hours are dedicated purely to the actual shipping code, and how much of those hours go towards all the other things needed to get that code to ship.
 
I reckon me n ChatGPT could write facebook...

How long is a piece of string? :D
 
Any application takes a certain number of man hours to create. If you have a team of developers, those hours are shared. If there's only one developer, they have to do all the hours. How many hours have you got? That's the limit for the size of the application you can build.

But how do you judge, from the immensity of a program, how many man hours it would take?
 
But how do you judge, from the immensity of a program, how many man hours it would take?

Experience is really the only thing that will help with that. What have you done before and how long did it take? You then extrapolate from that. It's also hard to say how "big" an application is. One may have lots of entities but little processing while another may have fewer entities but more processing. You really just get a feel for this sort of thing as you go along. That said, I'm still pretty bad at estimating time required for things.
 
I think even the famed Grady and Booch as well as other software engineering gurus have pretty given up on how to accurately do estimation and project management on a large scale. There attempts at capturing the variables like amount of experience of devs individually and cumulatively, type of project problem space, industry averages for lines of code for similar projects, industry averages of bugs per lines of code, averages of time spent debugging those bugs, etc. Still ends up being a big crystal ball with people putting together Gantt charts.

Hence the shift to smaller scale with Agile where things are just tackled in small springs of about 2-3 weeks and only features or parts of features that will fit in that time slot will be taken on. Devs doing planning poker guesstimating how long a particular story will take to implement. And then burn down charts within those sprints to see velocity with in the sprint. And then a running average of past sprint velocities to guess at how much the team can realistically tackle given past performance.
 
Software these days is never finished anyway..
 
Back
Top Bottom