As a developer of custom business webapps, I have been in this situation many times and I desperately wish I could take this advice. Really, I do.
But when a client makes a request like this, often unaware of what may actually be easy or fast or simple or consistent, I can't say no to it. Saying that we need to take more time to write tests and document it properly would likely come across as similarly unprofessional and reflect badly on the company. And the consequences are every bit as bad as you say they are: the code rots and becomes volatile and obnoxious to maintain.
That's why it hurts to read this post--it feels so painfully true. I'm lucky in that at my company, my project managers are coders themselves who understand the programmatic constraints and the danger of software rot--but my clients usually aren't. I have no solution for this; it's a fine line to walk.
The answer to this is educating your clients. This is an important part of running a company. You need to be able to tell your client in their language why something is hard to do. it's best to do this via metaphors or analogies concerning their profession.
You wouldn't believe how good a relationship with a client will be if they understand ehat you do ;)
Short-term technical debt can speed development, but like credit card debt, it quickly accrues interest. If you let your technical debt accumulate, then eventually you're spending all of your energy servicing the debt instead of improving your software.
It would be neat if there were some way to make this "debt" more visible to non-developers. At the moment it could be easily forgotten (by non-developers) after the initial deadline is hit, leaving no time to pay it back before the next "crisis" emerges.
The hardest part would be having some way to quantify the debt. But you could, at least, make a record of the corners cut, and make any accumulation extremely visible to management. Does anyone know of anything like this?
(estimated time - implentation) time over the course of the project + an interest rate. Older hacks tend to cause more hacks, so interest rate would be necessary (and more scary, which is a good thing )
We could have a pretty accurate debt precision in time, that time could be used to fix things ?
Unfortunately, most of the time, we are not the decision maker, especially if the requestor is of high rank (either from internal or external user with ranked M - SM,GM,MD etc). Even though I explain this and that, in the end, they will just say "Can do? When will you deploy it?"
Agreed. There's a difference between "ugly hack" and "blatantly unprofessional", and the OP makes it sound like the two are equal. In actuality, they are not and in fact, many times people mistake the former as a personal affront for the latter, claiming some moral high ground when there's none to claim.
The reality is that the "fine line" is the more reasonable and correct approach. It's case by case, every time. If there was a black-and-white rulebook, Joel Spolsky, Jeff Atwood, or Patrick Mackenzie would have blogged about it by now.
It's certainly "case by case, every time", but in every case the first thing should be customer education. If your customer wants a feature done in an unreasonable timeframe, don't say yes, don't say no, educate your client how long it takes to properly implement the feature.
Not educating clients is the worst thing we can do as software professionals.
Why do most people not ask for a house with a rushed foundation or frame? Because most people know that that's asking for serious issues later.
Why do most clients ask for key software for their business rushed out the door and delivered ASAP, sans testing and without proper spec? Because most don't know that they're asking for serious issues later.
You need better PMs. A PM that can say no is a hugely valuable resource.
My guess is that you either don't have PMs that say no or there is a really poorly structured chain of communication (ie - you have clients contacting more than just their PM for changes) which is changing the PM/Client relationship.
It is largely about drawing a line in the sand. If you let your clients overrun you with requests, then they will keep doing it. Why wouldn't they? Get billed the same for more features? Sign me up. Luckily I have PMs watching out for me.
But when a client makes a request like this, often unaware of what may actually be easy or fast or simple or consistent, I can't say no to it. Saying that we need to take more time to write tests and document it properly would likely come across as similarly unprofessional and reflect badly on the company. And the consequences are every bit as bad as you say they are: the code rots and becomes volatile and obnoxious to maintain.
That's why it hurts to read this post--it feels so painfully true. I'm lucky in that at my company, my project managers are coders themselves who understand the programmatic constraints and the danger of software rot--but my clients usually aren't. I have no solution for this; it's a fine line to walk.