As most professional developers are fully aware, when you start out building that exciting application for Joe Bloggs Inc, your intentions are always so honourable. You have your UML Diagrams, you have all your classes and libraries planned out and then you start writing. As you churn out your pre-defiened pattern that you lovingly spent hours drafting the client calls you "oh can we change this, and add in that?". The looming prospect of a 'hack' is on the way. However is the art of hacking code truely a skill we would all die without? Technically to your average joe, the work 'hack' refers to someone sitting behind a computer breaking into the pentagon. Of course in its truest form to hack is to alter technology. So my question and thought for the day is this: When working to a deadline and your client is particularly phobic about anything with buttons. Taking into account said client will probably change minds about what they actually want this application / tool to do many times even after sign off, is it acceptable to fill your code with hacks to get it to work? you know the situation - everything works when its stuck to the UML, however your clients thumb comes in a rubs out parts of your design with a big clumsy approach. Do I hack it? or should I rewrite the actual pattern properly and force the deadline back? The number of all night sessions I have had trying to rewrite an application design and wishing I had just patched the problem with a quick hack! The hacks create big problems later on as we know, especially if they are badly commented. So let me give you a scenario - you have two days to finish a project, your client decides to scrap an entire module of your application and change another significantly. The project is worth a lot of money and the client has the potential to earn you bunches, You can't push the deadline back but you have two options: Work 48 hours straight to resolve the conflicts and update the framework properly OR hack it and get it out of the way? Two very common options, which would you choose? discuss.
18
Aug
06
I’ve run into this by happenstance a few times regarding ActionScript/ASP in conjunction with proprietary Flash media and Intranet application. Oh the pain and torment in figuring out the simplest means of rewriting actions and arrays to attain the desired effect that the indecisive client came up with after you’ve sat down and analyzed the criteria discussed over the course of several weeks.
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.
I understand what you mean, I was actually trying to reference entire core architecture changes or patching them. Its more aimed at OO based architectures, re-writing functions in a script environment is quite straight forward - the trouble starts when you have to re-write entire classes and amend all its subclasses, or change interfaces, the ramifications are huge. Sometimes its easier to write a helper or a wrapper to patch the issue, especially if you have spent 6 months moving down one path with hundreds of thousands of lines of code.
My God, what a horrid underpinning to rewrite and although I would initially kick myself in the teeth for it, I would still have to reproduce a quality solution over a hasty resolution.
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.
If the client can just ring up and say “I wanna change….could we do that?….and I Expect it to still be delivered on time.” Then the contract is ill defined and the agreed process for change either doesn’t exist or again wasn’t defined at the contractual stage so isn’t being followed.
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.
Agreed.
great blog, keep it comming.
we encountered *very* familiar problems at a small web dev company I was part of a few years ago.
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!