To me, it all depends on the quality of the hack; if the design is flexible enough, it should be easy to put in a pretty hack that won’t impact on the overall structure. If OTOH hacking it means blasting fuck-off great holes in your code all over the place - redesign it with flexibilty in mind!

Before any work even begins there should be an agreement of the scope of work (otherwise, time to ponder how price was estimated) and because change is more expensive then agreed work, an agreed change procedure should be defined - typically in the form of a request for change note.

Upon receipt of a change request, someone on the team should look at the request, estimate the cost of implementing the change AND the cost to test the change (which is far more expensive then any work the developer puts in). A decision then should be taken as to whether it’s feasible under the existing contract/agreed price or whether the scope of change is large enough to warrant going back to the table with a “We’ll happily do it, but it’ll cost you AND/OR the date of delivery will change.” Again it’s important to have the re-negotiation process clear and upfront at the start of the project.

And with that all in mind, the bottom line is a hack is never worth it. At least not if your design is worth its salt.

…As I spend my life working safety critical embedded software, I might be babbling from a different world to commercial PC application software. If I am, then I’d propose that the “just hack it and get the change in quick” mentality, is the reason so many software firms go broke. And why the ones that survive, spend their lives battling instability, security and maintainability issues for all of their remaining days - pouring vast sums of revenue into a black hole.

My apologies for possibly not reading into the original article as posted. I assumed from the questions proposed this dealt directly more with business practice rather than the latter.

I’m assumming something has taken place recently that has triggered such a inquiry? Care to elaborate further - changing names to protect the innocent of course? Haha.

Fortunately -or- unfortunately, I’m not one for a hack though. Being a perfectionist at heart, I hate the feeling of building a workaround over just rewriting the function, I despise sloppy code even though every so often I am most assuredly guilty of it, and I can’t begin to describe my disgust for vague or erroneous commenting. It just doesn’t sit well with me.

Fortunately, for myself and the business I conduct, I cover my tail with a clause in our initial contract with the client and I prefer to be paid hourly (at a competitive rate, of course) as opposed to a lump sum for the duration of the project, with a initial non-refundable deposit of 25% of the estimated project man-hour cost up-front.

I make it my business to ensure they are completely aware that their last-minute changes could extend their product’s completion date - this is all defined in their contract so that they are never surprised of their obligations or consequences. The client knows that any dramatic changes beyond the initial concept/evaluation and annotated criteria, will result in a cost THEY will have to absorb - from my perspective, this means that if they have made a choice to turn the corner on the project, knowing they will incur certain fees, they’ve evaluated and made a calculated decision which might be worth the percentage of their margins and therefore I can bypass any ‘guilt’ over accomplishing their requests.

Time is money. Perhaps if I ran a media powerhouse, this could/would change, but in the freelance game, I have to make the money where I can make the money.

Does this effect the business relationship? Possibly under certain circumstances, although I’ve found that most clientele will live with the cost resulting in a tailored, superior product of sorts coupled with a can-do, professional attitude. In turn, I’ve been provided reference after reference by word-of-mouth.