Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Experienced programmer - newbie project guy

by the_slycer (Chaplain)
on Apr 09, 2002 at 18:29 UTC ( #157817=perlmeditation: print w/replies, xml ) Need Help??

I have been approached to begin working on an application for a group in my company that is outside of the one I currently work in (somehow my name got around). I'm looking at this with conflicting emotions.

First, I am happy that I am being offered the oppurtunity to work on this, as it gets me away from my regular grind.

However, because of previous experiences, I have some concerns in how I approach this. I am asking monks that have more experience working on "projects" for some advice.

Specifically what can I do to avoid problems like I ran into last time, and just generally good advice in how to start a project. Most of my previous experience has been - I see a need, I write a program, it fixes the need.

This time, someone else has seen a need and has approached me to work on it. What can I do to ensure that this works well for me, and just as importantly, fills the clients needs?
  • Comment on Experienced programmer - newbie project guy

Replies are listed 'Best First'.
Re: Experienced programmer - newbie project guy
by footpad (Monsignor) on Apr 09, 2002 at 19:17 UTC

    Well, there's a lot of advice available and the things that will work will depend on a) the complexity of the project and b) the amount of time you want to put into keeping it running smoothly.

    One of the first things you'll want to do is get all that nasty "money" stuff taken care of up front. Make sure your client knows when you expect to get paid, how much, and what specific types of work you'll be billing for. For example, will you bill support calls? How about bug fixes? (Note on the latter: If not, make sure you define what you mean by "bug." I tend to fix bugs for free and have had clients try to classify miscommunicated requirements as "bugs." I tend to define bugs as "Things that should work properly, but don't," as opposed to "Things you decided you needed after we talked.")

    Along the same lines, use care when accepting jobs that don't pay until after they're complete. I have a friend who took a couple of these because they would pay off handsomely if they took off. The projects are still in holding patterns and you can imagine what this has done for his household budget. Personally, I prefer obtaining deposits before work proceeds--especially if I have certain misgivings about the client. A deposit gives you motivation to actually work (and helps pay the bills while you do so) and it commits the client to the project.

    That done, you'll need to make sure you both agree you know what "Done" looks like. After all, if you don't know exactly what you're building, how can you design an effective solution, manage feature creep, define schedules, or even provide a reasonable estimate? Basically, this is simply an agreement about when the project is finished, something you can both use to measure progress and success.

    I tend to do this using a variety of common techniques: interviews, note-review, task lists, etc. Depending on your experience and available tools, you can also borrow ideas from various Software Development Practices, e.g. Use Cases from UML, etc. Be sure to choose practices appropriate for the project. For example, I'm probably not going to define an ERD1 for a simple email-gateway script.

    Once you know what's needed, create a task list showing what you need to do to make that happen. This will likely be sketchy at first, but if you maintain it, you can end up with a pretty detailed list of the work you performed and the choices you made. I tend to use a word processor's outline view for this. Not only does this keep things organized, but it also helps provide automatic numbering to help communicate and refer to various parts of the project. It also helps with other elements of the project, such as devising test plans, tracking problem reports, creating documentation/training materials, and so on.

    Next, prioritize the tasks. Determine what needs to be done and in what order. Also, determine which features are "must have", "should have", "nice to have", and so on. This will help you determine what needs to be worked on first and what can be delayed for a later phase should time/budget get tight.

    In short, keep track of what needs to be done, what you've done to make that happen, what you need to finish, and what you've been paid for. Do that well and you should avoid much of the problems you ran into earlier (though some of that was beyond your control).

    In closing, here are a few links to articles covering good practices:

    There are a host of books, materials, and opinions on the subject. In practice, choose the ones that help the most, consider the others, and then use what seems to work best for you and the project at hand.

    Above all else, though...remember to communicate with your client. People can appreciate delays when they know about them and see that you're making progress. However, they don't like being in the dark...especially when they're not sure how much it's costing them.

    --f

    1 - Engineering Requirements Document, basically an oversized task list. Useful with some projects; overkill in others.

Re: Experienced programmer - newbie project guy
by dws (Chancellor) on Apr 09, 2002 at 18:51 UTC
    Specifically what can I do to avoid problems like I ran into last time, and just generally good advice in how to start a project.

    I'm guessing that the problems you ran into last time were in large part because you worked solo and came in under everyone's radar. If the project you're being asked to join has visibility, this shouldn't be an issue. However, you know have to worry about visibility within the team. People who pull surprises within teams can destabilize a project.

    As for starting the project, my best advice is to listen carefully and gather information. What are the goals of the project? Who is the project sponsor? Who is the customer? How will the project benefit them? Who are the end users? What are their expectations?

    When working on the project, manage commitments and expectations carefully. Don't bite off more than you can chew and swallow, and keep the team updated on what you're doing.

Re: Experienced programmer - newbie project guy
by Fletch (Chancellor) on Apr 09, 2002 at 18:50 UTC

    Mythical Man Month (ISBN 0201835959) speaks more to teams of programmers and is (in some ways) a bit dated, but still a very worthwhile read. You might also look at some of the extreme programming books and web sites for information on the current fads^H^H^H^Htrends.

    (That's a tongue in cheek jibe at XP. It has good points and bad points like all methodologies. Personal experience showed mixed results, but then we weren't doing everything the XP way. Definately worth taking a glance at, at the least. Your Milage May Vary, of course.)

Re: Experienced programmer - newbie project guy
by trs80 (Priest) on Apr 10, 2002 at 04:21 UTC
    • Requirements, Requirements, Requirements
    • Break the project into phases with a sign off by the person that developed the requirements at each phase. (aka CYA)
    • Don't do the requirements yourself and be involved as little as possible. This may sound strange, but from my exprience in an environment such as the one you describe in your "rant" post, you need to make sure they don't make you the scapegoat at any point. If they want you to write the requirements yourself then get someone to sign off on them that is senior to you.
    • Manage Expectations. Know what person (team) X wants that doesn't go in the requirements. For example, if you know that "Fred" is a stickler for all the fonts to match, don't let an odd size font slip into any of the demo/testing processes. Little things can and do throw people completely off track and can lead to lose of confidence. So know what the person you are reporting is looking for that they didn't put in the requirements.
    • NEVER ask what they will be looking for, most likely they won't be able to put into words and some people have new pet peeves daily. (this is the hidden stuff like the fonts, not the information in the requirements, the requirements should be detailed enough that you don't have to ask what they will be looking for app wise)
    • Always look beyond today.
    • Use flexible datastructures
    • Don't write COOL code, write readable (maintainable) code (aka have pity on the poor bastard that has to maintain it)
    • Do exception testing as part of your everyday work.
    • Document anything you do (unless requested to make something elaborate, just keep a couple of text files or daily text files of what you did) and make sure the requirements include the server setup and any restrictions as far as OS, location, does it need SSL (you already knew that one :), etc.
    • Don't take anything personal. So when responding to comments, keep your focus on the code and the task. Even if they DO attack you personally don't reward them with a counter attack.
    • Keep your eye on the prize. (good code that works)
    • Did I mention requirements?
Re: Experienced programmer - newbie project guy
by tjh (Curate) on Apr 10, 2002 at 16:07 UTC
    There is plenty of good advice in this, and other, threads. My experience is that these communication-related issues must not be underestimated.

      dws's: "...manage commitments and expectations carefully"
      footpad's: "...make sure you both agree you know what "Done" looks like"
      trs80's:  "Requirements, Requirements, Requirements" , and, "Manage Expectations"

    It is very easy to assume you understand what they said, or assume that they said what they meant. Likewise it's often ridiculously easy to assume they understood what you said, and wrote, and agreed to.

    Work Very Diligently and Obviously to be sure you've each duplicated the other - throughout the project, not just at the beginning.

    And do everything possible to document all agreements, changes, conversations, followup confirmations, etc. You will all be better off for it. They'll more likely get what they wanted and know it (even if you 'adjusted' their wants during the original scoping conversations), and you'll know that you delivered what you promised.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://157817]
Approved by dws
Front-paged by FoxtrotUniform
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2020-06-01 14:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you really want to know if there is extraterrestrial life?



    Results (2 votes). Check out past polls.

    Notices?