1. 28
  1. 16

    scc is a pretty neat tool to count the lines of code; it also prints the COMOCO estimation by default.

    Here’s a small side-project project I worked on for perhaps two weeks (full time) at the most (probably shorter):

    Estimated Cost to Develop $1,282,396
    Estimated Schedule Effort 15.116892 months
    Estimated People Required 7.536604

    $1.2 million!

    Now, this is cheating a lot since this includes the Unicode dataset as a Go file which gets counted. But even if I exclude that:

    Estimated Cost to Develop $64,479
    Estimated Schedule Effort 4.852825 months
    Estimated People Required 1.180440

    5 months and $65k for 2 weeks? Not bad. Either this tool is wildly inaccurate or I must be one of those 10x developers I heard so much about! I’d prefer it if it was the latter, but it’s probably the former.

    The main project I’ve been working on for the last year or so:

    Estimated Cost to Develop $978,057
    Estimated Schedule Effort 13.638056 months
    Estimated People Required 6.371295

    This is also wildly inaccurate; the time estimate is roughly accurate, but 6.3 people? lolno. Just me. And this doesn’t even include all the parts I released as separate libraries (16 of them) which aren’t counted in here.

    COCOMO is a joke, and even the most casual of glances will show that. A bloody horoscope would probably be more accurate most of the time.

    1. 6

      tbf if 10x programmers exist you’re probably one of them

      EDIT: or more precisely, if someone asked me “are there any 10x programmers on lobsters”, I’d think of you first

      1. 3

        I am not sure about 10x programmers, but I have seen 0.1x programmers several times. Like that time they have submitted an app that was totally broken and printed “dick” on the stdout. Then they asked us to pay.

        1. 3

          If you have seen 0.1x programmers, then you have seen 10x ones - as I understand it, the “10x” term was coined to describe the difference between the worst and the best performers, not between the average and the best ones.

          1. 1

            It’s a different way of looking at it though; instead of saying “this is normal and these are exceptionally good”, it’s “this is normal, and these are exceptionally bad”.

            Given the supply/demand of programmers, these people keep landing jobs. But in a healthier work force a lot of them probably wouldn’t. I’ve worked with some people that were quite frankly just hopeless, but not quite hopeless enough to not get nothing done at all; just at a 0.1× rate (or even lower).

        2. 2

          I wish. Until somebody comes up with an effective technique for measuring programmer performance, we can all live in hope.

          My experience is that there is a step change between those who can and those who cannot. Measuring within those who can is difficult because of all the interrelated factors involved.

          1. 1

            You don’t need to have an exact measurement to give a roughly accurate estimation.

          2. 1

            Ow, you’re making me blush 😅 I’m really not that exceptionally smart or good; probably about average. There’s probably something in attitude that makes a bit of a difference somehow, but I’m not entirely sure what.

          3. 3

            Fitting the data shows that one of the published models is wrong, and there are relatively large error bounds on the other models (which is to be expected for a model built from 63 data points)..

          4. 15

            I think the main thing people get wrong about estimation is the onus gets put on the developer to guess correctly, and they’re damned if they do, damned if they don’t get it right.

            Estimation should be inverted. It’s not “how long do we want this to take”. Instead it should be asked “how long do we want to take on this?”

            The former just handwaves away massive variables and externalities and puts the developer in a tough situation where they’re either erring on the side of caution and could be perceived as underperforming or they estimate too optimistically and look like they can’t deliver. Management can say they don’t judge but subconscious bias is impossible to remove.

            1. 8

              This is a big deal.

              Estimates often tend to get more optimistic as they work their way up the reporting hierarchy. The team lead says six months, the group lead says five, the director says four, and so on until the C-level execs are told that it’s pretty much already done and the release is imminent (exaggerated, but the point remains) [1].

              One problem is that this puts the onus on developers to set conservative initial estimates if they want what gets filtered up to be even close to reasonable. But then, as you pointed out, they may appear to be underperforming, or just plain lazy.

              [1] I ran across this idea in a writeup from SGI in the early 90s and, at the time, it was viscerally true in my own professional life… http://www.alexmeyer.com/code/irix.html

              1. 4

                The team lead says six months, the group lead says five, the director says four, and so on until the C-level execs are told that it’s pretty much already done and the release is imminent (exaggerated, but the point remains

                Probably off-topic but all communist dictatorships worked like this. This is why I think glories of capitalism are grossly exaggerated when both are equally driven by supplicating to delusional clowns. I think it is decentralization that makes capitalism accidentally work.

                I think one way to see estimates would be to see them as a trade off between quality vs time. Another way I like to think about estimates is how many iterations does it take - like how novels are written. I think on an average a novel takes 5 drafts at least.

              2. 5

                Instead it should be asked “how long do we want to take on this?”

                Estimation as negotiation is the best way to approach things, and I’ve received surprisingly little in the way of push back when I answer the “how long” question with a question of “when do you want it?”

                Everyone already has an idea of when they need it – perhaps they have an angry customer they want to placate, maybe they have already sold the feature and need to recognize some revenue soon. And management also always is aware of constraints developers aren’t that may change the design. It might be as simple as “the BA who knows the feature is going on leave so we have to move fast”, or it might be “we’re closing on an acquisition in 2 weeks and need to clear the backlog before things get really interesting”.

                When you treat time as a constraint you negotiate up front rather than a one-time estimate that a PM converts to hours and multiplies by 1.6 and plops on a project plan, you’ve got a chance to get some of the context and constraints you don’t otherwise see and can do better planning,

              3. 10

                I used to work with some guys from IBM, and I still have a stack of books and papers on their software engineering research from the 1980s. Most of this research came out of their operating systems and database development groups, which employed thousands of engineers working on huge code bases. It’s really fascinating stuff: ways to estimate lines of code based on feature points, ways to estimate the number of bugs per 1000 lines of code, ways to estimate person-hours per bug, etc. Unfortunately, most of this is stuck with the software engineering practices of the 1980s: huge monolithic projects with thousands of engineers, little interest in sharing components between projects, a lot of repetitive work that amounted to fighting with the tooling available at the time.

                Today the “predictable” stuff tends to mostly already be done. Back in the old days, a database might have had to implement 10 different join strategies, so you could have a team implement one of them and then extrapolate out to how long 10 would take. Today, not only do we not write join strategies, we just download the entire database in 10 minutes and don’t even care about the internals. The predictable work is mostly done already, and we’re stuck with unpredictable tasks like gluing components with two totally different APIs together.

                1. 3

                  This is exactly right. The kind of programming I do is not like a production task of making a car or a house when you’ve already made 10 of them roughly similar before. The programming I do is research. It’s things no one has ever done before. And once it’s done and put on github, no one ever needs to do it again – certainly at minimum I never need to do it again.

                2. 3

                  Excuse the plug. I offer a free analysis of software estimation data, provided I can make an anonymized version of the data public.

                  Here is one I did earlier.

                  1. 3

                    …Wow. Anyone who seriously tries to run machine learning on double-digit counts of data is either incompetent or willfully committing fraud. As the article points out, it’s not like this data is that hard to get.

                    1. 1

                      I have a strong feeling the whole industry of “process” consultanting whether it be SAFE or whatever is largely just made up. They love to cite a large corporate director who decided to transition as “evidence” their methods work. It would seem, like with many things, academia is not producing usable research that can actually drive knowledge translation.