I still think Sikuli is neat. I think I have to be clear. It's just that this is becoming a much more complex thing than I am comfortable with.
This is why, when the boss appeared over my right shoulder, I was working on the other one. It's web work. I like web work. It's mostly Perl. I like Perl. I wrote everything involved, from the SQL tables to the Javascript interface bits. I get all of the things I wrote. It is a comfortable place, which means it's a job I can get done and feel productive. I felt I could git 'r done, check the thing off, and then deal with the confusing time sink.
Nothing quite like the boss showing up behind you to tell you that, no, your priorities must change. There's a whole bunch of .DAT files to be munged, and what we have isn't cutting it. So, when will it be done?
No clue.
No clue on several sorts of issues. I started this as a programmer who never did much more than recursive and iterative Fibonacci in Python, so I am not familiar and comfortable enough with the language to really say I know how to do anything fast. I'm still on the learning curve there.
Plus, I don't really know what all the problems are. I don't know how to solve the problems I don't know that exist. We're combining two machines and two Java applications with ssh, X11 and other things. It is a complex thing.
But those things are relatively minor. The more fundamental thing is that I do not think of tasks in time terms. How long a task takes is how long it takes. I don't want to think about the time aspect. It distracts from thinking about how to actually do the task. If I come up with the clever solution, it's done. If I don't, it takes forever.
Is this a common thing for programmers? Or am I the odd duck?
it's endemic. "project managers" think an arbitrary task can be estimated. but you can't estimate something that you haven't done repeatedly.
ReplyDeletethe time for arbitrary tasks can be estimated but you need a large enough sample size of people providing estimates to come up with an fairly accurate estimate. about 20 people with diverse backgrounds to avoid bias. I've done so in training exercises and in practice (I am not a project manager but received some training on managing projects)
ReplyDeleteThere are several methods that work with some degree of accuracy. Splash mentions a method that's called "wideband delphi" in project management literature; it works okay as long as you take Hofstadter's Law into account. The way we manage time where I work is typically, we break down the tasks into atomic parts and sum up estimates for each of the parts, then add a significant (20-40%) margin. If you do that a few different times, using different experts, you get fairly close, but it's more art than science. Then, we track progress as the project goes on, so that when we've spent 50% of the money but only made 40% of the progress, we can go back to the customer and say "It wasn't as easy as we thought it would be, here's why, can we please have more money."
ReplyDeleteI shall have to look into some of splash's and patrick's into account. I think I'll either have to start keeping track of such stuff so I can say something with some confidence, or start saying "two weeks" like the guy in "Money Pit".
ReplyDelete