Fog Creek Software
Discussion Board




doing everything in a project yourself

Recently I was given a project to do a certain data mining and knowledge discovery task, with the spec only being
do this - with "this" being something very broad
Essentially I had to do more detailed specs, come up with the design and algorithms etc...
Essentially the whole software engineering task was left to me, from requirments gathering, design, high-level design, code and test, as well as all documentation.
Given that the company is really small, do most people at small companies (less than 10 people), find themselves
doing a whole project completely by themselves?

Sergei
Monday, July 14, 2003

It's pretty rare that I *don't* do an entire project by myself.

Philo

Philo
Monday, July 14, 2003

Sergei, what do you think the founder of the company did when the company first started? In a small company, everyone has to do more than what might be in their job description (q.v. the Barteleby thread). It's not that the people around you are incompetant, it's just that if they can depend on you to do it, it's one less thing they have to worry about.

This seems to be the antithesis of a giant corporation where people are clamboring for more responsibility to make themselves look more important. "Look, I'm manage the process."

In a sense, the way you had to do it is the way it should be done. Sure, after a certain point other people will have different kinds of expertise to bring to the table, but until then, imagine you've landed a job at an upstart company called "Ford" and they've just asked you to design & build the drive train. What do you think happens if you don't?

www.marktaw.com
Monday, July 14, 2003

I am pretty much enjoying this experience, what I mean is that it's a very important and complicated project for the company, and although I am following process,
until everything in the process is 100% documented correctly, somebody else looking at the algorithms,code etc.. might have a hard time understanding it, but if somebody followed along at regular status meetings, at what I am mostly doing it would greatly help to atleast have an idea by word of mouth what I am doing, but there is nobody for that.
I am formally documenting everything, but just reading the technical docs, won't help anyone that much, I think, eventhough it's quality is good

Sergei
Monday, July 14, 2003

Its a small company, the work is unlikely to be transferred to someone else. Keep your documentation tight & to the point. Ultimately the code is going to be the design document so to speak.

Richard
Monday, July 14, 2003

Sergei wrote, "Given that the company is really small, do most people at small companies (less than 10 people), find themselves doing a whole project completely by themselves?"

Yes, but they typically don't  go about it in the manner you are.

It has been my experience that most American programmers who work for small companies simply start hammering out code until the client accepts what they created, someone fires them, or they get re-assigned to another task. Usually, American programmers do this (code first ask questions later) because most of them don't have the slightest idea how to gather and record requirements, perform analysis, or do high level design. Even so, that doesn't stop many of these individuals from having big egos.

One Programmer's Opinion
Monday, July 14, 2003

Most of my projects, which I do almost entirely by myself, start with someone saying, "It would be cool if we had a system that did this ..."

There are no formal specs. I just say, "Yeah, I can probably do that." I do it, and when someone suggests changes, I make them.

Please note that we are a small company solving small problems. I'm sure this doesn't work for a mortage company with millions of loans.

Fred2000
Monday, July 14, 2003

Fred2000 - you should come join me on the estimating thread...

Philo

Philo
Monday, July 14, 2003

Fred2000 is right on. I work at a very small company (~5 employees) and I'm only one of two application programmers. Our clients give us a rough spec and I just start building. I may add to the design as I see fit based on standard business rules and pratices... we will try to continue to the hash the spec out as the project goes along although that does not always happen because our clients are in the education sector and tend to decide everything in rather large slow moving comitees. Sometimes projects come out correctly spec'ed and others get shipped and then we get a call saying - "Oh, we need this, this and this or we can't deploy it". And still others never get fully deployed because of various red tape at the institutions (but alwas paid for mind you!). Along with these hang ups comes a great sense of freedom and accomplishment knowing that you implement an entire project from start to finish.

Jn
Monday, July 14, 2003

We also only have about 5 people, Jn.

The best part about doing everything yourself is that you get to do more than code, and writing code sucks. Marketing, graphic design, writing a manual... Those are more fun for me.

Fred2000
Tuesday, July 15, 2003

I run an international software company. By myself.

There are enormous efficiencies if you're organized.

I.e., When I've got my tech support hat on, I am paying attention to what questions we get frequently.  Then, I make note of that for program updates.

Likewise, when I've got my sales hat on, I pay attention to what features people are always asking for. I cross index this (in my head) with what features people seem to actually be using (based on followup contact).

The result?
I've developed 18 programs in the last 3 years and tech support calls are almost nil (except for the "where is the on button" questions. No fix for that ;-))

These are, admittedly, things that a bigger software company COULD do, but big ones rarely do. It seems that intercommunication b/t departments is poor. Perhaps due to politics, etc.

Entrepreneur
Tuesday, July 15, 2003

Just out of interest for those doing the design and coding - I work in a small company ~10 people. The specs you start out with do change and adapt as you get a better idea of what the client is after but was wondering your thoughts on defining the difference between what is clarification of a requirement and what scope creep. It can be a fine line and it can be difficult to clear up until they have seen something running especially if they are not too technically confident.

Gav
Wednesday, July 16, 2003

*  Recent Topics

*  Fog Creek Home