should developer be charging for fixing bugs during development?

[nelsonm]

Hi all,

For the first time I hired a web developer to create from dispatch board on a web site i'm developing. We are at the end of the project and from his correspondence, it appears that he wants to include billable hours for what he calls "bug hunting".

In February we were at 35 of 38 hours, as per the quote, with yes 25 hours paid to date. I will eat the hours I promised and the many hours to revamp the object oriented jQuery code (a source of pagination performance issues), but I do have a goodly number of hours involved in adjusting to the redesigned PHP script, database, and associated changes plus bug hunting. At this point I'm willing to call it a full working day (8 hours) as billable.

While he appears to be giving me a break on all the hours he's spent on the project, Should be charging me for fixing bugs during development?

[bunltd]

It's not always a cut and dried answer - depends on your agreement with the developer, really.

But as someone who has been on that end of things on a custom project: You can't always predict what issues will crop up in a custom project. It's not always something you can anticipate exactly, especially if the scope changes during the project. Troubleshooting/bug hunting are necessary parts of development. If it is beyond what was budgeted for the project, then it's billable time. But that should be communicated, no surprises.

[nelsonm]

We just agreed on an estimate of hrs and a rate to develop a finished component. Specifics about what would be considered billable hrs where not discussed.

I fully understand that reworks due to changes i instigate would be billable, and while i'm willing to be flexible, i question billing the client for hunting down programming mistakes during development.

[rocknbil]

I've been up and down this ramp hundreds of times over the years. I don't have straight answers, but I have some insights:

We just agreed on an estimate of hrs and a rate to develop a finished component.

See, this confuses me. Was the written agreement for a transaction at an hourly rate or was it a project fee? If it were a flat project fee, I'd have no recourse to b***h and complain about how many hours it took, or how many more it's taking. UNLESS . . . . .

Specifics about what would be considered billable hrs where not discussed.

BANG. Bad, bad, bad, for both parties. The proposal should clarify what IS and what is not "beyond project scope and billable at an hourly rate," and define the project functions and tasks entirely. If these weren't present and clear to you, you should have asked for a rewrite.

Even if it's hourly, if I'm taking longer than what I expected, it's on me. Learn for next time: estimate what you think it will take, then triple it. Seriously. Double it never works out, triple might break even.

But this is now complicated by this:

I fully understand that reworks due to changes i instigate would be billable...

My proposals always stated clearly how much is changeable. Reformatting output of a layout, for example, should be part of the game. Adding functionality is something else entirely, and it means one thing: stop the project now and rewrite the proposal. Which leads us to . . . .

i question billing the client for hunting down programming mistakes during development.

Bugs do not always equate to "mistakes in programming." Look at an example: write me a CMS to edit five pages." So we do that, it works. "Oh if you could add one thing: I want to be able to upload pictures." The picture uploads are one project, the page edits are another. Getting them to integrate may produce bugs. Would you have me scrap the project, and start over knowing we'll be doing picture uploads? Because if you did, I'd have done the CMS part in a completely different way, rather than "patching" the uploads onto something else that was never intended to do uploads.

Is this making sense to you now? Many see the web as as series of drop-in elements that can be collected by observation: "take that effect from this web site, add this other thingy from another web site, integrate this do-hickey into it all, and as you can see what I want is really quite simple." (Often finished by "should be easy for someone who knows what they're doing." :-) ) Often there are conflicts between the widgets and programming across areas of server side programming, Javascript, and CSS, and what do we call these conflicts that we need to resolve?

Bugs.

An opinion, it sounds like the proposal was too loose, which allowed you the room to modify the agreement on the fly, and now both sides are getting frustrated with what's shaking down. Put the brakes on everything and communicate, and take what is learned to the next project.

[edited by: rocknbil at 6:00 pm (utc) on Apr 25, 2012]

[BeeDeeDubbleU]

I am afraid that programming mistakes during development are virtually impossible to avoid. They possibly could be avoided but the process of testing as you go and ensuring that they are avoided could take longer than the debug.

[bunltd]

programming mistakes during development are virtually impossible to avoid

It's not so much that they are mistakes as much as they are unforeseen consequences. Sometimes when you change one seemingly small thing you end up with a cascade of changes in other parts of your programming, and you have to make all of those changes to get it all to work.

[nelsonm]

Thanks for all the input guys. I can see know that the best way to avoid problems is to setup a solid contract that:
1. spells out the type of project; a flat fee or hourly rate project.
2. spell out clear specs and expectations.
2. cover the main issues that can arise during and after development.

In my case, the main problem was poor nearly one sided sporadic communication on the part of the developer.
1. I would email or phone him on monday and he would respond maybe by the end of the week or next week.
2. He would take action on issues that needed discussion before coding and produce functionality that i did not want or ask for.
3. During the last review, he huffed about my critique on the status and functionality of the project saying that this and that was outside the scop of the project. So i said, ok, just do this one thing and nothing else. I'll take care of the rest. A week later, i get an email saying all of the issues have been corrected.

In the end, he did produce what i wanted but it was a hassle getting there. The dispatch board was estimated to cost $2450 and ended up costing $3200.

[g1smd]

How long will it take you to make the extra money back?

Does the product now work as you want it?

[phranque]

i think you put the emphasis in the wrong place when quoting your developers' email:

I do have a goodly number of hours involved in adjusting to the redesigned PHP script, database, and associated changes plus bug hunting.

it was the associated changes that required additional bug-hunting that was not in the original scope of work.
as rocknbil said, you're lucky that wasn't more like a $7500 project in the end and your developer probably ate it at half his normal rate or less.

[nelsonm]

g1smd,

1. I should be able to make the money back through additions to the web site the client will ask for. The initial web site project was limited to basic features and functionality.

2. While the workorder dispatch board and un-assigned workorder list box works, they do not behave properly when you resize the browser. If you reduce the browser window horizontally, the un-assigned workorder list box drops below the dispatch board and the dispatch board begins to extends beyond the browser window's right edge. I asked that the un-assigned workorder list box stay put and float to the left as the browser's horizontal window size decreases and that the dispatch board be put into a scrollable div so it does not extend beyond the browser window, but he gave me a stink about the request being outside the scope of the project. I think in his mind, the project is only about the components and not how they behave on the page. So i decided to end the project since it does work and fix the behavioral problems myself so i can finish the job. besides, even if he did agree to fix the issue on his own dime, i may not hear from him for another week or two.

To be fair, the guy does have a full time job and is getting a degree in computer security. He said he could offer 20 to 25 hrs a week to work on the project. Also, on a good note, he has been vary helpful answering questions and doing research on system matters. He really is a nice guy.

Still, he takes too long, does his own thing, does not communicate in a timely manner and does not follow directions very well. The dispatch board should have been done within 4 to 6 weeks even with my changes that forced some reconnecting and recoding on his end, but it has taken nearly 3 months.

The thing is that he now knows how the overall system design works and i still need to get some other components done. I also don't want to wast anymore time finding someone else and getting them up speed. So ironically, now that we've worked together and i have a better understanding of how he works and how to deal with him, i think we'll be able to work together to complete the job albeit a little later then sooner.

[edited by: nelsonm at 12:45 am (utc) on Apr 26, 2012]

[g1smd]

Well, you know what they say about software projects:

"On time, on budget, works to specification.

Pick any two."

[nelsonm]

Also, life without challenges is not life.

thanks for all your comments.

[BeeDeeDubbleU]

I can see know that the best way to avoid problems is to setup a solid contract

My colleague and I rarely take on a project like this without putting a ceiling on it. Rather than charge hourly we offer the client a price range. We explain that there is inestimable work involved and we quote a min/max range, e.g. from £1000 to £1500. If we don't make it under the max then we eat the difference.

We have had jobs when a ten hour max estimate has actually taken 30 or 40 hours but OTOH there have been times when everything has gone better than anticipated. :)

[nelsonm]

BeeDeeDubbleU,

Interesting idea. Having an upper limit does have the benefit of forcing you to take a harder look at the specs and methods to implement them so that the range is as realistic as possible. It also gives the client the comfort of knowing there is a limit as long as the client understands the ceiling does not include additional enhancements and feature requests.

[dingloo]

We work on fixed cost projects only and use an approach where we split any web based project into two parts:
1. Static screens
2. Actual code

We estimate only for static screens with the client and tell them how much it would cost to develop the static screens. Once approved, we build all the static screens, that show exactly how the site will look like when launched.

At the end of this, the static screens, become the actual requirements - frozen for this version.

At this time, we estimate for completing the actual work. Once approved, complete it.

The above approach has helped us define a solid set of requirements all the time - although at times, the client comes with new changes after coding has started - but that helps us easily estimate the additional estimate (time and cost) involved to address it.

[nelsonm]

thanks for your input, i never thought the static screen/actual code idea before - interesting.

[piatkow]

My last salaried role was in testing and recalling the weekly root cause analysis reports that I had to prepare coding errors were the most common individual issue but the others totalled up to form a significant minority or even the majority on some projects.