Heard this argument a few times and mostly I do agree, but in certain scenarios I'm not willing to spend a whole day on some perfect code when I can do it in a hour with some comments explaining it.

My scenarios for this typically include: * Disposable project, eg prototyping an idea for a client * I have an impossible deadline and I'm on a fixed project rate, maybe I should have quoted more, who knows, it happens

Why fear complexity when its the only way to get something done, other than not doing it?

There is no such complex function that can't be decomposed to bunch of simple(r) functions.

Often only with a deep understanding of the complex problem to understand its simplicity. But you have to ship in 4 weeks, so why not just get something working first?

> But you have to ship in 4 weeks, so why not just get something working first?

If you do that, after the deadline is over, you will get assigned another task with another 4-week deadline. And then another. The code will get increasingly complex until you can't keep with it any more. And then you will leave the company, or they will fire you. And the people who gave you that deadline will refer to you as "the guy who left that horrible mess of code".

I decided long ago that that's not how I want to live my life.

If someone gives me an unreasonable deadline, I negotiate it. Hard. By explaining the problems, and making sure everyone understands the tradeoffs being made.

And if the deadline is really immovable, I negotiate a period to refactor after the deadline is passed, and in which I am not assigned other tasks.

And if that is not possible, then I start looking for another job. Fortunately now it's a great time to be a programmer.

But hey, if that works for you, then great. To each his own.

> But you have to ship in 4 weeks, so why not just get something working first?

Of course, this sometimes happens, but it shouldn't be encouraged. This way you are creating technical debt, which will be very expensive to pay off.

I actually work on problems that haven't been solved previously (or why not just get a dev to do it rather than a researcher). I get offended when some dev who writes web apps connecting to databases all the time says "all code should be simple." They really don't have a clue.

At what point is simple simple enough? You can simplify for a long time just by working at the same problem for a few years. But wow...not everything is a basic crud app.

> At what point is simple simple enough?

It's hard to explain. You know it by experience.

Because simpler code usually leads to less bugs, which is faster and cheaper than complex, buggy code.

I find that the better I understand a problem, the simpler code I can solve with it. But I can also understand the problem better by solving it with code, and repeat a few times for a few months to approach an ideal solution.

Writing simpler code is more expensive than writing complicated code for that reason, unless you are a genius who can simplify any complex problem instantaneously. Anyways, your argument basically amounts to "do good, no do bad."