When you ask for a Drupal developer to change code that he isn't the maintainer of, the way they change it is just as important to your project as what they change. Careless changes are cheap up front, but expensive down the road.
It's important to point out that this article does not apply to custom development in modules or themes that are specifically written for your project. We're only talking about "contributed code" here. Let me explain.
Drupal is an "open source" project, meaning that anyone can go and view the source code. When a developer builds a Drupal site for you, they've copied that code to your server and have installed Drupal. After the basic installation, it's very likely they downloaded some extensions to do jobs outside of plain vanilla Drupal (often referred to as Drupal Core). An extension can be a theme (the look and feel) or a module (code that does a specific job). It's this code that we're interested in for this article.
Here's where things start to get interesting.
The developer may be asked to change something that Drupal does on its own to better match your needs. A simple example of that would be some messaging on the site. Maybe a module was installed for e-commerce, and some messaging during checkout doesn't make sense for your site. You've asked the developer to change it. The developer pokes around the administration areas and finds, to his dismay, that the text is hard coded in the module and there's no where he can go and update it through an administration screen.
The solution the developer employs at this stage will either be a permanent fix, or come back and bite you over and over again. A good developer knows that anything can be overridden in Drupal and how to do it. This developer is new to Drupal though, and he doesn't really understand how to override it properly. They go into the source code, do some searching, find the line of text that you asked them to change, and they change it. Great! It works! Problem solved! You review it and approve the change. Everyone moves on.
Not so fast.
The developer improperly modified source code! We like to refer to this as "hacking" a module. Now your version of the code is unique. At some point in the future the inevitable happens.
The module they changed needs maintenance. Another developer comes up behind the first one and upgrades the module. The new developer had no idea about the modification. The modification gets lost in the shuffle and you spot the issue again and are understandably annoyed. Now you have to pay someone all over again to make the same change!
Maybe this time they'll do it right and override the code using established best practices. Had the changes been done using best practices for overriding Drupal, the change would not be a problem. The end result on the site would be the same, but the change wouldn't create any "technical debt".
This scenario only gets more complicated and costly in reality.
What if the site developer made a whole bunch of changes incorrectly and it's not even possible to determine what those change were even for in the first place? Even if the next developer spots the changes, they'll have to spend time futzing with them, spending your precious development dollars on something that won't have an outward impact on the site. No matter how good that developer is, it's no picnic to sort that kind of mess out and it takes time.
That's a bill no site owner can feel good about having to pay.
Changing source code using patches is ok, if done correctly.
On big projects, eventually a developer runs into a situation where he needs to participate in the Drupal ecosystem, or tell you that you can't get what you want.
Let's say the developer in this example is a bit more savvy than our first example. This developer has done some searching in the Drupal issue queues and found that the problem he's run into is a known issue. Other devs are talking about this issue and some people have written a patch for the problem. This is a common scenario.
It's actually the process through which Drupal grows and thrives as a project; people banding together to solve common problems. All this is all well and good, but your developer needs to tread carefully.
In the second example, the developer applies the patch he found in the issue queue, it works, he reports back to the issue that it works. Now his vote is added to the list, and the module's official maintainer will take it into account, review the patch himself and if he approves, he'll add it to the next release of the module.
Yay for participating in the life of Drupal!
Your site developer now needs to document that patch on your site by adding the patch file into version control and using some method to let other devs on your project know why it was added. This is critical, otherwise the code changes fall into the same category as our novice dev's changes in the first example!
Technical debt either way
In the end though, both the dev working correctly in the second example, and the novice dev in the first example have created technical debt, although patching is acceptable, and "hacking" is not.
So where does this leave us?
The lesson to be learned is that these types of changes should be done with extreme caution, after exhausting all other possible avenues. A project with both types of changes across an entire site is one which will be difficult and costly to maintain.