When I worked salary, one of things I liked, but didn’t realize at the time, was the ability to solve a problem no matter how long it took. Granted, when it got out of control, my manager and team would find ways to bring it under control, but bottom line I’d be pointed at a challenge, let go, and I’d update my superiors on my progress.
I have a high willpower; it’s the only way I’ve been able to compete in this industry. It serves me well in solving challenging problems because the obvious is not always obvious, and you are constantly challenging your assumptions, testing hypothesis, and following stringent logical workflows… or not, depends on my mood. Typically, you are supposed to rule out the most obvious & likely problems first in any debug session. For example, some example code you try doesn’t work. More than likely, it is faulty documentation vs. the actual Flash Player not working… unless you are using an alpha build of the Flash Player.
Those 2 paths of debugging above can lead to further steps, and other test cases that can drag on your morning. Other problems can drag on for days, even weeks. A lot of times, you can only spend small chunks of random time throughout the day, never really being able to focus exclusively on the bug. Sometimes it has a lower priority, and you merely put it in the back of your daily queue, in hopes that other development will spark a reason for why it is happening.
All those things and more can either be full force, or backburner type tasks. Bottom line, you are paid whether you fix it or not, and the time isn’t really a big deal vs. the resolution. Depending on scope, the point of no return is measured in days or weeks, not hours.
Getting paid hourly, however, changes the rules. I cannot go off for days at a time trying to solve a problem. I need to document what I am doing, minute by minute, always needing to be aware of what I am doing, how long it is taking me, and how long it’ll take to get to a resolution.
Those of you who have been in software development for any length of time know that if you knew how long it was going to take you to solve the problem, then you’d know what the problem was. Debugging, however, is about finding the problem. You can’t solve a problem until you’ve found it, and if it were that simple, then application development wouldn’t always be over budget.
The solution is to keep an accurate assessment of progress, well spoken hypothesis on what the problem(s) could be, and put it in the client’s lap to decide on if you should keep going, or focus on other tasks. Before, it was, "Jesse, solve this issue, and report back to me when you’ve found it. If you don’t find it by lunch, let me know. We’ll discuss and see if we can’t try a few more ideas."
Now, it’s kind of like that, but with a lot more documentation, self-awareness, and less emotional investment. I guess that last part is what really irks me. I can no longer dive in head first. As a contractor, I’m now constantly nagged by my own psyche to remember to keep track of my time of how long I’ve spent, and being able to clearly articulate where I am at with the bug at the drop of a hat.
heh… had an immediate ‘…me too!’ reading this.
The one thing I found that made a difference (which you already do, with this blog) was documenting stuff in a wiki/blog…
Although some bugs are complete stumpers, many (for me) are more like ‘Darn I’ve been here before! and I can’t … remember .. how I fixed it… LAST TIME!’ >o(
I usually just eat the time. I’m a glutton for punishment.
Generally, yeah, I think I get your point. But I don’t know–when I’m getting paid by the hour I still just have to keep my ‘manager’ (client) informed. Perhaps more often they’ll want to know in advance how long some optional feature will cost (in hours) which is hard to say… but generally, I don’t know if there’s really any diff. What sort of salary situation is there where they say ‘solve this problem no matter what the cost’? Never heard that one when I was salary–then again, that was more than a decade ago.
I do think your general comments can also apply to the differences between product-based software and services based. I find product work is much more task oriented where they might actually say ‘this feature is core and we must solve the problem no matter what’.
Ultimately, you have to both give yourself the flexibility to over invest as needed.. and your client needs to give you that flexibility. So, some clients are better than others–and the end product usually shows it. For example, I have a client who will say ‘go ahead and spend a day making this scrollbar feel exactly the way we want’. In the end, many people won’t notice the difference but they may say one just feels more solid or appropriate. (Maybe the scrollbar isn’t the best example, but clients who give you freedom where needed have the end product to show for it.)
So, like I say, I agree… but I don’t have the salary experience to argue your points.
Think of how your perception would be if I said:
‘Phillip, you have all day to fix this. Let me know when it’s fixed.’
vs.
‘How long is it going to take to fix it?’
So you’re saying because it’s a bug it’s more ellusive? Okay, so you never know. But, you can also approach bugs is a less absolute way. I mean there are ways to workaround or modify the features in order to avoid the bug. In fact, the biggest assesment you should make before attacking a bug is identifying how much time it’s worth; what the risk of not fixing it is; and what the risk of FIXING it is. Two biggies are that it could take you forever to fix… and/or you could inject other bugs.
Sometimes I guess a client will say ‘take two hours to fix this’ but more often they want to know in advance how long it will take. Sure, it’s tougher to asses when it’s a bug.
But, I know what you mean. Here’s a great example: I had this site I was working on and it was pretty basic–an accordion sort of thing with images loaded exernally… so I was doing great with BitmapData etc.. then I added the outlines and I got this creapy bug which you’d think was caused by pre-Flash 8 non-hairline lines or curver corners or something. I swear I can’t get the lines to look right… tried pixel snapping etc. I easily took 4 hours and just decided it was nuts. Okay, so I should have just taken a walk or a nap… but the funniest thing is the client doesn’t even mind. I don’t think they noticed until I pointedit out–and they still don’t care. If I had asked if I could spend 4 hours to fix it (let alone 4 hours to find I couldn’t fix it in that time) they would have said no. So… the point is that it’s not always up to the programmer what should be fixed. (I think that’s the point.)
Agreed. My point is that last part in your first paragraph USED to be a management task, and is now a task I need to do in addition to figuring out the bug.
I want to fix things, not weight the outcomes and price structures of fixing things knowing I need permission from the client to know what I can and cannot start on assuming it’s a black and white decision on what they pick, but apparenlty you need to when consulting.
Sentence run on, I know, but it gets the point across of the emotional transition I’ve had to go through.
the other part of that ‘how long should I spend on this?’ that can get sticky is figuring out how much of the debugging time is billable.. trying to be both fair to the client AND yourself, and sometimes having to accept (as Phillip pointed out) that the client really doesn’t care that it’s not perfect.. and you have to let that bug go out into the wild…
I haven’t had EXTENSIVE experience dealing with BIG problems as you probably have. Most of the time the solutions that I provide are pretty simple.
However, for those times that aren’t as easy going where I have ran into problems. I’m usually honest.
Client: ‘How long will it take to fix the problem?’
Me: ‘Honestly, I do not know. This is a new issue for me, but I’m sure I’ll find the problem.’
Now……. depending on the client that may prompt:
‘You don’t know! You Ripoff CON!’
However, honesty is my best policy and so far the response has been.
‘Well, I trust you, I know you are going to figure it out. That’s why we hired you.’
That may sound fairy tale like, and maybe I haven’t got enough experience to get the response before that. I just try to make sure the client trust me to full extent and to expect problems before we step forward.
That’s one reason I went to lump-sum contracts. My promise is ‘the project is done when you’re happy with it’ and I get to take whatever time I need to do it. My clients are happy because they know they’ll be satisfied in the end, and I’m happy because I’m not on the clock.
Regarding whether to charge for bug fixing… provided that the client really does want the bug fixed, I totally charge for that time. I figure if I had programmed it in the first place without any bugs it would have taken longer. So, if it has bugs it’s because they saved money in the other part.
I also agree that fixed price projects solves much of this.
I’d agree on using fix pricing. That is what I do, hence the previous post. I anticipate bugs in my quote and they pay according to the agreement, not sticking to our agreement, or if they want to add to the project.
You may try the fix pricing with certain conditions. That may take some time stress off.
You are still going to have to get project done on time and be honest if you are going to miss the deadline. However, there is something about already having a set price that keeps them from being less forgiving about missing the deadline ( just a bit) :).
Good point Mr. Lee and Mr. Kerman.