• Lurk (unregistered)

    I think Mihail won on points.

    1 - He got some early real world experience of what 90% of projects are like. 2 - He didn't have to support the end result. 3 - He got paid.

  • (nodebb)

    Well, at least Mihail gained some valuable experience: what it's like to work on a project where the requirements change continuously(1) while the code is being written.

    (1) Yes, continuously. I'm well aware of the classic 1st Ed AD&D spell "ContinuAL Light" that produced continuOUS light...

  • Hanzito (unregistered)

    I've heard of BS jobs, but apparently there are also Worse-Than-Failure jobs.

  • Industrial Automation Engineer (unregistered)

    Well, that sounds about right. Worked on a pipe laying robot once, (one that lays pipes on the bottom of the ocean.) By the time we were finished, the vessel was sold and repurposed. The complete pipe laying system was cut and sold for scrap metal, just after commissioning completed. Oh well...

  • Mike Sandbox (unregistered)

    They don't teach The First Rule in college... no matter what the customer asks for, what he really wants is Excel.

  • (nodebb)

    Time tracking is fundamental to our billing

    This attitude has caused so many problems. Unless you are doing consulting work for another company (NOT another department within one company) time tracking is useless crap.

  • (nodebb)

    Time tracking is just as dumb as counting lines of code. A programmer's productivity is measured in value provided to the company compared to cost, not how long they spend on a project. If you pay someone $100k and they provide 'x' times more than that, then they're good.

    https://www.folklore.org/Negative_2000_Lines_Of_Code.html

    Addendum 2024-12-24 09:18: Theoretically, 'x' would be 1, but companies like profit margins.

  • Industrial Automation Engineer (unregistered) in reply to Mike Sandbox

    Nah, the First Rule is: The customer doesn't knows what he/she wants, right up to the moment of delivery (and doesn't get it).

  • Dave Aronson (github) in reply to DocMonster

    Even in consulting work, time tracking is counterproductive overall (though it can be very profitable for horribly inefficient consultants). Google "Hourly Billing is Nuts" for some great stuff why.

  • (nodebb) in reply to colejohnson66

    You can only track what you can measure. "Value" is hard to measure, you only really know it well after the fact. Lines of code and time spent may not be perfect metrics, but at least they're objective, so they're used as proxies.

    Unfortunately, this leads to Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”

  • gman003 (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to colejohnson66

    Time tracking is just as dumb as counting lines of code.

    Tell that to software companies in France, where the "CIR" (== "Crédit Impôt Recherche" == tax credit for the "R" part of "R&D") requires that the company that wants to have the tax credit must be able to show that X amount of time that tax year was spent on "R" activities rather than "D" or "random other shit" activities. The only sane way to do that is a time tracking tool. Note that it also allows the company (even outside the context of stuff like the French CIR) to track the "time taken to build feature X", which is useful over the longer term.

    But counting LoC is dumber than dumb, since (a) it's largely unconnected to actual productivity and (b) it encourages the kind of LoC padding we've seen here on this site many a time, and (c) sometimes deleting a bunch of code is what you actually have to do.

    Case in point, a bunch of code I had to wrestle into submission after the original authors quit the company... It was a message queuing system (for C and C++) with hugely excessive ambitions, both in the sense of what they wanted to build and also in the sense of what the product really needed, and I ended up having to delete about a third of its code because ===> that daemon there leaked memory like a sieve while it was running, but managed to clean it all up before quitting (that is, a "soft" leak in my normal terminology(1)), which made debugging it in valgrind a source of major suckage. Since I couldn't easily track how that memory was used in the third-party component that "leaked" it, I just nuked the daemon since it wasn't remotely useful for the product, but it reduced the LoC count of the messaging system by about a third...

    (1) "hard" leak == classic C/C++ leak where we grab memory and then forget where it was instead of cleaning it up, "soft" leak == anything where we can clean it up (we remember all the pointers) but only do so on exit, including any leak in a program running on a non-buggy JVM or .NET system (with a GC).

  • Lurk (unregistered)
    Comment held for moderation.
  • (nodebb)
    Comment held for moderation.
  • (nodebb) in reply to colejohnson66

    Once upon a time (like, a month ago), I pushed a commit that deleted 76,000 lines. It was glorious.

  • (nodebb) in reply to Industrial Automation Engineer

    Worked on a pipe laying robot once, (one that lays pipes on the bottom of the ocean.) By the time we were finished, the vessel was sold and repurposed. The complete pipe laying system was cut and sold for scrap metal, just after commissioning completed.

    That must have been intensely frustrating, all ready to lay pipe and you get hit with premature cancellation.

Leave a comment on “Tracking Time”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article