Hacker News Reader

Comment by maxxxxx | Hacker News Reader

There are types of work where you may deliver nothing for months. I think the sprint idea mainly works for well understood tasks where there are no surprises. I often work on stuff where I can only report failure for weeks or months until it hopefully works.

View on HN

Can you please elaborate somewhat on the nature of these projects? I’d like to understand what it is about the work that makes it difficult to get interim results.

For example I have worked on a way to launch a process in Windows with certain privileges from a service. It's a little unusual but important for the way our software works and right now the lack of this capability creates the need for a lot of clunky workarounds. Based on my reading of some Windows APIs I suspected we could make this work but it took 12 weeks to actually make it work. There was no guarantee of success either and there were no intermediate results.

Great example, thank you. Sounds like you had a fun 12 weeks :-).

I would call it a roller coaster :) with going back and forth from "why the hell did I sign up for this?" To "hey this may really work".

I always tell people that any good project has to have a time of deep depression where you deeply regret getting into it.

Any kind of research into a novel solution will basically be failure until it is suddenly success. If you can see that success coming from very far away you're not doing novel work.

This is really what I was trying to get at below. The sprint model or even the marathon model just doesn't work for certain types of projects.

Reply on news.ycombinator.com