Is a project ever *too* big? 2

[benlinkknilneb]

Hi all,

I work for a small company; I'm the only full-time programmer. It's really been the best setup in my entire life... I've been here a year and never really *had* any deadlines to meet. As long as I communicate with my boss and work hard, they don't set any limitations on me in regards to deadlines, etc.

However, my projects have been getting bigger and bigger in scope. Still no deadlines, but I sometimes feel a little overwhelmed. My question: in this sort of environment, can a programming project be considered "too big" for one person? I know I could eventually complete it on my own; I may have to learn a lot of new stuff to do it, but they don't seem to mind that. Like I said, I'm not under pressure to perform at some outrageous rate, but when I look at the requirements for my latest assignment, it's huge in comparison to anything I've ever written.

I'm looking for opinions of more experienced people: where is the point (specifically in the scale of the project) where a single programmer is not enough for a project, or is that based on whether it can get done by a certain time?

Thanks for your input.
Ben

 

[edfair]

My experience has been on the hardware side, and yes, projects can be too big.

If you have good communications and an understanding boss you possibly could set up some mutually agreeable checkpoints for design and implementation. And at any point where you start to feel uncomfortable with those checkpoints you communicate them. And it will help if you have written documentation of timeframes and expectations.

It is not in the company's best interest to burn you out, nor yours. And schedule some breaks from the project to vacation or work on other little stuff. Does wonders to clear the fog.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[CajunCenturion]

From the software side of the house, the bigger projects get, the more the need for project management. It's quite easy to lose site of the forest when you have lots and lots of individual trees to deal with, thus it's easy to lose site of the overall objective. That becomes even more of a burden if only one person is involved. The larger the project becomes, the more emphasis that must be placed on the overall functional requirements, the design and architecture, and the ability to monitor and adjust the development process to stay in focus and consistent with the overall business objective.

edfair's comments about documentation, establishment of milestones, and communication are just as pertinent in large software projects as they are in hardware projects.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[benlinkknilneb]

OK, what I got from both of those posts was that as the project grows in scale, I should adjust my development process to fit. I (somewhat) understand the suggestions made concerning milestones and communication, but I'm really new to professional development, and I'm not sure how to put those ideas into action. My boss isn't a developer himself, so I think part of our problem is that neither one of us really knows how to work through this. We're on really good terms with each other, and he would be very open to any suggestions I'd have to offer. So how exactly do I implement edfair's ideas... what kinds of things should I be documenting (in terms of project management)?

 

[CajunCenturion]

From the 10,000 foot view:

First thing I would do is make a roadmap. At one end you have the starting point, and at the opposite end is the project conclusion. Take the project and break it up into smaller tasks.

Start --> Task1 --> Task2 --> Task3 --> Complete.

Now you can take each task, and break it into even smaller components, and you can continue this top-down approach down to as fine a granularity as you deem appropriate. The more granular your tasks are defined, the less likely that you'll leave some task out of the project. You can also go overboard and get too detailled, but go down to a level that you're comfortable that covers all the bases, and will not let any tasks fall through the cracks. I would also identify all of the tasks dependancies that exist, such as TaskB cannot start until TaskA is complete, and TaskD cannot start until TaskC is complete, and TaskE is dependant on both TaskB and TaskD, but TaskF is autonomous. That might look something like this

Start  -->  TaskA  -->  TaskB  --+
       |                         |---TaskE  --+ 
       -->  TaskC  -->  TaskD  --+            |
       |                                      |-->  Done 
       ------------------------------TaskF  --+

Once you're down to the appropriate level of detail, then establish a task development ordering so that you know what task you're going to do first, then second, and so forth. I would also take each task, and assign a time estimate of how long that task will take, being sure to include sufficient testing time. Next, build a timeline, based on the task ordering and task development time and assign estimated starting and ending dates for the tasks. Remember, that you won't be able to devote 8 hours a day on development, so use a reasonable number of development hours per day in deriving the schedule. Put this all down on paper, or use something like MS Project, or whatever as your baseline documentation. As development progresses, compare the actual numbers with the estimated numbers, and adjust the schedule accordingly and development continues. You may also ajdust task definitions as requirements change, and again, adjust the schedule and time estimates accordingly. Periodically (weekly, bi-weekly, or as needed), sit down with your supervisor(s) and show them where you are, how you got there, where you're going, what ajdustments you made and why, and the overall project status.

This is a rather broad stroke overview, and is not the only method, but hopefully it's enough to get you started down the line.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[skiflyer]

It all depends on the specifics. But the first thing I'd suggest is to break the project into logical and testable units.

You can then present the list of logical units to your boss, with a very rough expected timeframe for each, and say this is what I can do when. Some of these units may be tiny, and have completion times of a couple of days, others may be slightly larger and take several weeks/months.

The testable part is important though. Each time a new unit is finished, you should be able to run a unit test on it, make sure it's working to your specifications. This will allow you to "plug in" the new units when they're finished. Additionally, it will allow you to call upon unfinished units from the ones you're currently implementing, because you have already defined the interfacing of the two.

It's one approach anyway, applies very easily to OO projects, but still works with line code imo. It's a necessity for multiple coder projects, but adds significant discipline for single coder projects as well.

Even if you don't like that, let me stress one word... DESIGN. If you have the whole thing spec'd out before you start you are going to save tons of headaches, and I mean some significant design... take it from someone who has done it right and wrong, it's a royal pain if (for a simple example) you implement a nice beautiful function, call it a billion times, then on the billionth and one call, realize you need to pass an additional parameter in. Easy to band-aid, a pain to do properly.

Anyway, best of luck...
Rob

 

[benlinkknilneb]

Thanks guys for your input; excellent as always!

 

[edfair]

In the documentation for completing each step, document the input to the step and the output. You won't be looking for solutions in a linear fashion if you are like any of the programmers I know. They get wild ideas and jump around testing them, then come back to the mainstream when they have firmed up which idea to use. And the input/output requirements keep them on focus.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[guestgulkan]

To answer the original question, I do not think that a project can technically be **too** big.

What can happen is that the timescales for the project can be wildly underestimated or resources not correctly specified or the technology used may not be up to the mark,
or the timing of the project maybe wrong, etc..

There have been HUGE projects (both software and hardware)carried within the last century.
Witness the panama canal, the 3 gorges dam (china), putting a man on the moon, development of some of the current in design super-jumbo airliners or military aeroplanes.