Have you ever successfully completed a project...

[Fallenangyl]

I have recently finished a project that included 3 teams in 3 states. We met once at the beginning of the project and that was all the face to face time we got. Of course the application we finished with wasn't even remotly close to what we started with. And as for seeing them daily? It was probably a good thing that we were in different states :)

It's not my fault you suck.

[Michael Bergman]

I had to provide code support in California for a project in the UK. Most of the time, email was sufficient method of communications. A few times I had to stay late and talk to them via instant messenger. That wasn't too bad. We were able to get the product out on schedule. I think the advantages of daily associations are obvious. One advantage of long distance communications is that the other developers don't see the problems the way you do (developers who work more closely together will, over time, look at problems the same way) and will bring a different perspective to the project. Of course, it also depends on who is the 'alpha dog'.

m.bergman

-- For Bruce Schneier, quanta only have one state : afraid.

[Gary R Wheeler]

That sounds like an awful lot of the software projects I worked on for the DoD back in the 80's. There were simulation apps back then that had been under continuous development since the 1960's and never completed. I wouldn't be surprised if some of there were still being developed.

Software Zen: delete this;
Fold With Us![^]

[homegrown]

Chris Austin wrote:

I'd much rather spend my lunch time playing trains with my son or kickboxing.

:thumbsup:

{∫∞∂x} :: have the courage to use your own reason

[Jacquers]

Yes, I collaborated with a guy in a forum to modify / add on extra functionality to some software he wrote. I'd say that the project was a success. We communicated through email and im, but I think direct face to face communication would still be better.

[urbane tiger]

did I ever - yes successful - moderately rather see them every day - not particularly more successful - not necessarily

Multi famam, conscientiam pauci verentur.(Pliny)

[BrienMalone]

Devs talking to end users is an oversimplification. Our current website was designed and constructed by a firm in San Francisco... We are in San Diego... The only people we met were the account rep and the leads for design, development, and project management. Speaking as a dev manageron the client side, I didn't need to meet any of them in person. Would I do it again? Sure. The one thing I would do differently is use a truly collaborative workspace instead of one way gotomeeting/webex sessions from them to us. I tried to explain ui behavior using still screen shots and they just didn't get it. I currently have an offshore development relationship with a vendor... And I friggin hate it. The time difference, the language barrier and the cultural barrier (that seems to encourage doing the absolute minimum with zero thought to innovation, creativity or efficiency) makes it a miserable experience.

[LenaBr]

Partially. Did a fish coop in newfoundland from halifax - but I went there to implement and train. I did a project from home for my current employer when I first started. I got pnuemonia the 2nd week there and did the entire project from home. I did do the specs face to face however. It was only 2 weeks late ( due to the pneumonia)

[envador]

Office Communicator works fine for us too. Whenever I go home and hop on MSN Messenger, the ads really annoy me. I'm glad they made an enterprise product too.

[dpminusa]

With all the conferencing tools and free collaborative development environments, is this really a problem any more. Having the contact is obviously better. Maybe it doesn't have to be face to face with or without a web cam. If the project succeeds without it, then hats off to the specification writer and the project management process. Not the best way. In short why do it the hard way when there a few impediments to some sort of interactive collaboration now. Direct answer: YES, in the past, when collaborative tools were not available, we put extra effort into the specification and the project management plan. We made sure there were lots of milestones, and interim results feedback loops. These were factored into the costs and delivery dates. Adjustments were expected and made from the feedback.

"Coding for fun and profit ... mostly fun"

[RussellT]

Vikram A Punathambekar wrote:

I feel it helps a great deal if a developer were to talk directly to the end user.

Interactions between developers and users are perilous. Quite often, said interaction can be very beneficial toward clarifying ambiguities in requirements. Conversely, this can be a principal cause of requirements creep. Such meetings could include statements by either party like, "Wouldn't it be great if the product could do [insert feature here]?" This could spell disaster for a project that is already on a tight timeline with respect to the requirements already in the queue. Strict discipline must be imposed upon these interactions to control user expectations and constrain developer promises. New requirements should usually not be permitted as a topic of discussion—even those that are a natural extension of those already defined. This does not mean, however, that developers could not or should not assist with the requirements definition in the first place. Here, their participation could be invaluable. Kind regards, Russ

[Lost User]

The short answer is "yes". The longer answer is "yes, but". I have found that in every case I have had to build in extensive hacks in order to compensate for sloppy design on behalf of the developers of the other components. For example, one critical system involved two separate computer systems. The source system managed a highly complex electrical grid spanning areas in Canada and the Midwestern U.S. This system sent flat text files every five minutes via FTP to the destination system. Because of a faulty design, the source system performed the transfer using the following steps. 1) establish the connection 2) send the file (.txt) 3) verify file complete (by file size) 4) repeat 2&3 if sizes different 5) close the connection At the destination (my) end, processing of the received file was triggered by a folder watch (scheduling program is adTempus - a terrific program that I highly recommend). The received file was moved to an archive folder after all records were inserted into a database. The problem is that there is no clear way of determining when the sending process had completed the transfer. The sending process should have been. 1) establish the connection 2) send the file (.tmp) 3) verify file complete (by file size) 4) repeat 2&3 if sizes different 5) rename the .tmp file to .txt 6) close the connection What was happening was that when the sending system was bogging, several seconds would elapse between steps 2 & 3. During that period, the receiving system would process the file and remove it from the FTP drop folder. The sending system would then compare the file sizes, determine that because the file was not there it had to be re-sent, then re-send it. Clearly, the second, 6-step process, avoids that problem because the .txt file does not appear until after the verification. I have found problems like this in every project of this sort.

[Lost User]

Did i heard successful project completion?????????? A successful project never gets completed.....it goes on.... with new requirements, change request or support...... only un-successful projects are completed(rather finished!) or abondoned..... I have never heard an successful project geting completed, unless it gets exhausted!!!

Ravie Busie Coding is my birth-right and bugs are part of feature my code has!

[Single Step Debugger]

In our case it’s very unstable, generates fatal errors on daily bases and is getting wrong the keyboard input very often.

The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.