4 ms·

> All the research indicates that software developers are terrible at estimating time, but are fairly accurate at estimating relative effort. I'd be interested

• HeyLaughingBoy 7y ago
  I don't have a specific online reference to cite, but the Software Engineering Institute has a lot of research in this area. Specifically, the PSP (Personal Software Process) suggests using LOC as a proxy for size. e.g., a Small task might be 50 LOC, 200 LOC is medium, 700 is large. Then you can take those T-Shirt sizes and compare them to tasks you have done in the past and use that historical data to predict completion times. I'm simplifying it somewhat (e.g., there are also Complexity inputs), but the process does work if the organization is disciplined enough to follow it.
  • necovek 7y ago
    There is a huge difference between "research" and "here's another idea" — I would personally love to hear about some research backing any estimation methodology. FWIW, I "feel" the big issue is with loosely defined requirements which shift as development progresses.
    • HeyLaughingBoy 7y ago
      PSP/TSP isn't "here's another idea." It's a research-backed software development process. And yes, while unmanaged, changing requirements is a major problem, even with proper requirements management you still have the time estimation problem.
  • lloeki 7y ago
    LOCs don’t work either for more situations than I can count in my experience. I’ve had 50ish LOC stuff that implemented a tricky algorithm that was core to a system and required careful design, implementation and testing, right next to 700ish LOC stuff that was super straightforward and basically just laid itself out.