What is the optimal team size for a project?



  • @tufty said in What is the optimal team size for a project?:

    You might be able to get a testing team to build tests based on stated requirements, though.

    That is if there is any requirements docs. Frequently most of it is assumed business knowledge.

    e.g. Gambling industry I was supposed to know the legalities of the Gibraltarian Gambling commission regarding chip and cash balances.

    Not hugely complicated, but if you didn't know the industry it is assumed knowledge. So code gets rejected at a late UAT stage by legal, while it passed all Unit, Functional and Regression tests.

    Obviously I was aware about it from that point forward and actually made the point to preempt any legal problems by skyping legal if I wasn't sure.



  • @lucas1 said in What is the optimal team size for a project?:

    @tufty said in What is the optimal team size for a project?:

    You might be able to get a testing team to build tests based on stated requirements, though.

    That is if there is any requirements docs. Frequently most of it is assumed business knowledge.

    Yes, that's what happens with us. As I said, we do scientific programming so some specs are "something to reproduce the results published in such and such paper". Given how much is missing in a typical paper, and how much of a typical paper only applies to the specific data set that was used for that paper, that often amounts in practice to "find a way to do something vaguely similar"...



  • @tufty said in What is the optimal team size for a project?:

    And requiring any code release to have tests exercising new or fixed functionality is always a good thing.

    That sounds reasonable and this is what I hope we'll start doing at some point. Now I just need to get my manager to agree to free up some resources (or hire some more) to train us and set up some test framework. Easy peasy :-/

    It's all very "finger in the air". LOCs are not a useful measure for judging this.

    I know... but how else can I convey an idea of the size of what we're dealing with...?



  • @remi It happens a lot, when it shouldn't.

    You would think that the Gambling industry would have unit tests for the calculations.


  • I survived the hour long Uno hand

    @remi
    You could always measure it in units of @lucas1's cock power? 🤷


  • Discourse touched me in a no-no place

    @lucas1 said in What is the optimal team size for a project?:

    You would think that the Gambling industry would have unit tests for the calculations.

    Unit testing involving floating point is annoyingly hard. Dealing with random distributions is worse.


  • BINNED

    @tufty said in What is the optimal team size for a project?:

    You might be able to get a testing team to build tests based on stated requirements, though.

    As the start, you can do it simpler. Add code coverage, and consider negative slope a regression. Then you end up testing per line of code, it is not that bad and easily measurable. Test the functionalities when stated, mock the rest.



  • @dkf said in What is the optimal team size for a project?:

    Unit testing involving floating point is annoyingly hard. Dealing with random distributions is worse.

    Real life example, from someone I know : after changing some random number generation code, a test breaks. The test ? Generate 100 numbers between 1 and 1000 and check that no number is generated twice. 🤦


  • Winner of the 2016 Presidential Election

    @remi We had one of those tests as well. 1 in 100 CI builds would fail because some value would be outside its 99% confidence interval. Not quite as bad as your case, but still incredibly annoying.

    Expected build failures are TR:wtf:



  • @remi said in What is the optimal team size for a project?:

    I can't really believe I'm worth 2-3 devs, so are they over-staffed and doodling around? Am I deluded and my module must be crap?

    Yes and no.

    The team size is not so much about cranking out code fast, or cranking lots of code. The team size is mostly about keeping delivery at a predictable pace. You may keep up with them, but it stops once you're burned out. They can also divert a bit (to help another team, or to build a side something) without sacrificing the current project, and I believe you have developed a blind eye toward a few really ugly spots in your codebase, because there's nobody but you to review it.

    Also, you can be run over by a bus, or your gallbladder may fail, disabling you for 3–4 weeks. Redundancy rocks!

    A team of 2-3 skilled developers can cover each others' asses when one or even two of them go on a vacation or have a really bad week (a divorce? Government paperwork? A newborn baby and insomnia? A sick family member in a need of help?).

    Performance reviews. You will be judged in a context of working within a team. If one member of a team screwed up, the team made up for it and it all averaged out. If a solo developer screwed up, it's like the whole team screwed up. Which is sad. If the team performed well it counts toward your positive karma even if you were not the sharpest knife in the drawer.

    And, last but not least, I dunno if you manage to document your stuff thoroughly enough.


Log in to reply