undefined | Better HN

0 pointsHeyLaughingBoy6y ago0 comments

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.

0 comments

3 comments · 2 top-level

necovek6y ago· 1 in thread

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.

HeyLaughingBoyOP6y 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.

lloeki6y 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.

j / k navigate · click thread line to collapse