How do you measure productivity when coding?

[nanode]

I've been working on a project for almost 2 months now at my job. I have done lots of designing and component testing, but so far don't have much that's tangible for 'the suits' to play with.

Some days I write hundreds of lines of code, and gain minimal functionality, some days the opposite happens.

How do most of you gauge your progess with software projects?

[Sterling]

General feeling - does it feel like the project is going somewhere? What, exactly, has been done and what remains to do? Remember to always have a development plan of some kind, even if its just notes scribbled out on a napkin from a restaurant hanging on the side of your monitor. (*) Also remember that exact progress is hard to judge - impossible if you're a manager. ;-)

(*) According to the various tales I've heard, although I'm not sure if they're true or not, the floppy controller for the Apple II WAS designed on a napkin.


------------------
-Sterling
-This post made with the Lizard! (http://www.mozilla.org)

[nanode]

I keep a notebook/journal of my progress. So if I were to be out sick or take a vacation, I have details about what I did most recently.

[TheLinuxDuck]

nanode:

If you don't mind me asking, who do you work for? What kinds of projects do you work on?

I'm just curious, mostly. L8r!

------------------
TheLinuxDuck
Wait... that's a penguin?!?!?
:wq

[Sweede]

hmm.. im part of a bug fix team for a webportal (similiar to php-nuke), and over the past week, i've closed about 35 of 60+ bugs and rewrote nearly ALL of the HTML (about 80%).

[nanode]

LinuxDuck:

Since you double posted, you must really want to know http://www.linuxnewbie.org/ubb/smile.gif

I work for Computer Associates in Kirkland, WA (near Seattle). It's my first 'REAL' job out of college - been here 6 months now. Our product is called 'Advanced Help Desk', although it tends to get bundled and renamed with other software suites.

The project I mentioned is a visual form editor. It allows customers to modify the GUI forms that are used in our main product. Visually it will behave a lot like other builder tools, but the format of the data is unique to our product.

So, if company X doesn't like something about a text field on a form, they can use my product to change the appearance, methods and attributes that may be associated with that text field.

Aside from that (which is in Java) I debug a variety of things and write a lot of utilities, like file parsers and test apps.

Re-reading my post, it sounds a bit like a résumé cover letter http://www.linuxnewbie.org/ubb/smile.gif

later

[slambo]

How do most of you gauge your progess with software projects?

We've got a few processes in place to gauge a project's progress. First, before we start on a project, we write a Project Requirements Document (PRD). This doc spells out exactly what the problem is that we're trying to solve, what tools we will use to solve it, and how we propose to solve it, listing all the screens and reports that will be affected by the project.

Once the project sponsors OK the PRD, we've got a good idea of what it is we need to do, and we can use the PRD as a rough checklist of what needs to be done.

The next step is to open a file in which to keep notes during development, sort of like a diary or lab journal. Each entry into this journal is date/time stamped and the contents of the journal is freeform text. In this file, we list all of the source code files and write down any notes that we take during the course of development. I've been known to write novels in mine, so I can easily refer back to it to remind myself what I was thinking about when I designed a certain piece of code.

The third process that we use here is todo lists. We write one-line descriptions of each task and check them off as they are completed (but we also add to the list as we identify tasks that need to be addressed).

The most important of these processes, I think, is definitely the journal, especially when there's enough detail for someone new to the project to understand the development.

------------------
Sean Lamb
"A day without laughter is a day wasted." -- Groucho Marx

[Dru Lee Parsec]

nanode: I may have told you this when we worked together but I'll share it with the gang anyway. An old programmer once told me that the number of lines of code a programmer writes per day is a bell curve over time.

When he's learning he doesn't write much code. Later, when he knows the language, he writes lots of code. Still later, when he's a senior programmer he gets lots of effect out of very few lines of code. SO it's a bell curve.

Companies who measure productivity by lines of code are competing in the race to see who can build the worlds heaviest airplane.

[YaRness]

it doesn't matter what i get done. as long as i'm off my lazy *** and at least trying to figure stuff out, i consider the day productive.

------------------
"Assembly of Japanese bicycle require great peace of mind."
Registered Linux User #188285 http://counter.li.org/
------------------