What is the biggest project you've handled yourself?

Question

What is the biggest project you've handled yourself in terms of lines of code?

What, in general, defines a project that is too big for one person?

Answer 1

I've handled projects that were large and small (and huge) by myself. I don't recommend it.

My personal view, after quite a bit of experience, is that no project is too small for at least two people to be necessary for its success. Communication, particularly bouncing ideas back and forth between at least two people, is critical for any project to be truly successful. Yes, you can write some applications (even very large ones) yourself - and I have - but they suffer from the lack of communication in the development process.

Answer 2

I have been working on a largish webservice plus website for the past two years. I am wearing four major hats: Architect, Developer, Tester and UI Designer.

A large number of hats has it's pros and cons. Especially if i'm sick of programming it is refreshing to switch to UI design etc.

Being the single developer means you are often faced with solving the problems without anyone pointing out obvious blind spots. But it can also save time as ideas and concepts do not need to be argued about etc.

Answer 3

The biggest project I've completed by myself was a 3D game engine. I don't count lines of code, so I can't say in those terms, but it was about 25MB of code (C++) spread over 1400 source files.

Really, there are only 2 things that make a project too big for one person:

1) Areas of expertise. If you are not familiar with the entire problem domain, and are not likely to be able to learn it in a reasonably timely fashion, you'll need people that are.

2) Deadlines. Even if you're completely familiar with the problem domain(s), what you can realistically accomplish in a certain period of time is finite.

If you have unlimited time, good organizational skiis, and complete knowledge, or the capacity to learn everything that you need, then you can handle any project.

Answer 4

My biggest project has probably been a collection of personal pet projects that all interact with one another

• Passport Service - Permission based authentication usable across several disjointed applications
• File Management Service - Upload, tag and archive files. Detect duplicate files. Ticketing.
• Upload Service - To replace clumsy HTTP uploads
• Upload Service Clients (Java, C# Console, Silverlight) - Interacts with service
• Broadcast Service - Create your own MP3 internet radio station

It's still a work in progress. Right now I'm working on the last portion before I go back and refactor some of the stuff I've already done.

Answer 5

Aside from being the only developer supporting some legacy products (which are huge but don't require too much work anymore); I've not worked on any project on my own.

I think one of the greatest value that can come out of working in a team is having your code reviewed by someone else (whether through a formal code review process or indirectly through someone trying to use code that you've written). Its always good to get constructive feedback from a disinterested 3rd party (and also get to learn from reviewing other people's code!).

And so my answer to the second question is: any project that has any level of complexity should ideally have more than one developer writing code (and reading!) for it.

Answer 6

The answer is difficult as it is well known that the difference in skill and productivity between developers is huge.

Furthermore, how do you quantify size in this case?

If you have an enormous project, say 100 000 lines of code but it's all doing the same stuff, CRUD operations and such like, that could be manageable, while another project of only 30 000 lines which is far more diverse and technically more complicated might not be.

Answer 7

The project I am working on right now is 350K lines of C++ code (3386 .cpp/.h files). It is a multi-threaded, multi-platform game engine including 3D rendering, audio, multi-player network layer, graphics exporter from 3D Studio MAX, a PC and Xbox 360 hardware layer (DirectX), support for gameplay state management, 4 DSL's written in Ruby etc.

350 thousand lines of code is a bit of a mouthful but practicing continuous refactoring helps keeping the code clean and relatively easy to use. Making the code strictly layered with no looping dependencies helps as well (24 layers in this case).

I have changed the overall architecture quite a few times as I learn more about what works and what doesn't. Moving from one architecture to another can be really difficult (especially when you have more than one game in production depending on the engine) but a slow step by step refactoring usually works.

However sometimes the changes were so dramatic that I was forced to start with an empty solution and move code over from the old solution one class at a time making sure it fitted cleanly into the new architecture. That happened when moving from a single-threaded to a multi-threaded architecture.

I don't think there is a limit to the size of a project you can handle as long as the project code is well organized. Even though the whole project is big, I normally dive into a specific sub-system, do what is needed, and move on. I never feel that I am working on a big project because I only need to keep a (usually) small sub-system in my mind at any point in time.