4 ms·
It would be interesting to see some other metrics with regard to this data. Cost and schedule are the first things that managers look at, but as a client I wou
by ohyes 15y ago
It would be interesting to see some other metrics with regard to this data.
Cost and schedule are the first things that managers look at, but as a client I would also be looking at stuff like SQA, code quality, completeness of my specification. There's also the 'bus factor' (if one of these guys gets hit by a bus, is there someone else who can work on and understand my code?) What additional documentation am I getting with the code? How is the customer service, is there someone there who I can call and talk to?
We also don't know how this 32 person team was comprised. If it was 4 programmers being supported by 28 other people who worked on the project off and on (management, sqa, marketing, documentation, requirements) these results are not surprising.
As a programmer I want to know things like: how many 16 hour days did the devs work, how maintainable is the code, did the programmer salaries increase commensurate with the additional effort that they seem to have put in? Am I confident in the reliability of this code, or has it been simply thrown over the wall with the promise of support.
I know we all want evidence for 'just Me, Steve and our Emacs buffers, is most efficient. Going it alone like Clint Eastwood and Arnold Schwarzenegger in a buddy comedy about programmers.' But studies in the social sciences like this one are incredibly difficult to get right and should be taken with a grain of salt.
- nasmorn 15y agoIn our industry million or sometimes even billion dollar projects eventually get cancelled for cost overruns while getting nowhere and people worry about soneone getting hit by a bus. The probability of staff suddenly dying is vastly over rated in my opinion.