Despite client satisfaction, I feel an ethical conflict.

If you're delivering what the client wants in terms of code quality, I don't see any ethical concern at all. What the client is paying for, and what they care most about, is business value. Good code and craftsmanship may be related to this, but are not ends in themselves.

I think you're assuming that clean code is the right way to develop software, which is not true.

Often times, speed and feedback is by far the most important criteria. In these scenarios, developing hacky, spaghetti code may be the exactly philosophy. Unless you have a direct conversation with the client, I would not assume that these "shortcuts" are bad.

If there's a certain level of reliability or testing that is being promised to the client, and your manager is encouraging you to skip on that, that starts to be an ethical conflict.

In the end, being a software engineer is just a job. We put in X time for Y value (usually money). Every job is like this. And the company is effectively a collection of people working for the same job, so the same equation applies at a company level.

Good craftmanship does matter. But our time is limited & time's value changes based on the current context. Better craftmanship itself doesn't provide value: yes you could spend time to make something better, but how much time? Would the company be fine with 2 extra weeks of polish for a 1-off client if the client will likely terminate the contract if deadlines aren't met? What if that contract is the difference between 1-2 years of runaway and collapsing as a company? Does writing good code trump the importance of the company not dying? If the company collapses, you're out of a job.

The ease of information lures developers with its high celing of craftsmanship, but often is a siren luring your career to death by drowing it in a sea of "just a little bit better". Craftmanship matters, but sometimes. Writing better code for something that is continously changed will benefit you over time, but if the code is never changed what's the point? If it works in its current state, then it requires 0 effort to be maintain (bringing it's value/time ratio to infinite since time is 0). If you start putting effort into polishing this, time is now greater than 0 and the value/time ratio is lower (so now you're technically losing the company money).

If your ratio is too low, the company will simply terminate you. Yes, your code could be the best out of everyone else's and could have way most test coverage. But if everyone else is shipping for many more clients than you & those clients are happy despite the worse engineering quality, then who's technically providing the least value?

I do think there's an in-between solution where you don't have to write spaghetti code, but the code can be written in a way where it's easy to scale it up in the future.

Tasks as simple as naming variables in a clear way, abstracting out lines of repeated code into their own functions, abstracting logical chunks of code into descriptive named functions, separating out files logically can make code maintenance a lot more manageable. It shouldn't take that much longer.

What is the process around your work? Is it code that's handed off to the client, or do they not ever see the code? Even if they don't see the code, do you ever make revisions to it? Even if no one else sees the code, it's easier to iterate on code that's clean.

I wouldn't refuse the projects, but I would have some bar of code quality for yourself while you are doing development.

@Jonathan, @Rahul, @Charlie

First of all, thank you for answering a question that I have faced for last few years.

I've dug my brain, tried to understand myself. There are two main reasons that I feel not right.

1. Only focus on current problem/try to find light weight solution more like hard coding which will be more cost to fix or maintenance than creating it rather than considering quality, possible future problems (obviously not too deep thinking), client's additional requests which might appear in the future.
2. Many clients don't have any idea of how the backbone works, how fragile it is, and what they see is only a frontside. If we try to explain about a backbone, they simply require it to be a bold, not increasing a budget (not all the time).

Of course when working on projects like PoC, making a spaghetti is fine as client and we are on the same page.