[paulhauggis]

I had to write bad code because sales and management usually dictate the timeline of the project.

As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented.

My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneath, they often times don't see the difference and when they explain to the boss that they might lose money, it's almost always option #2.

I hated being forced to do this so many times in my career, I started my own company.

[mesozoic]

Observationally this seems why sales driven organizations might have trouble keeping good developers. They force the build up of so much technical debt and never give the time to fix it that the good developers just leave rather than maintain the nightmare of code they've had to write.

[themodelplumber]

This weakness in sales-driven organizations applies to other types of employees, too. I used to be a graphic designer for one such organization, and it was next to impossible to create marketing collateral based on design standards; they'd rather buy it in a template kit from an office supply store than wait for a better plan to unfold. I later watched as they completely missed a huge opportunity to go upmarket with the proprietary hardware technology that the product staff developed. They were so obsessed with what was right in front of them that they became embroiled in tactics without strategy, and only the amazing breadth and depth of the market allowed them to continue making a profit without punishing them too severely.

[0xdeadbeefbabe]

Are you implying logic driven companies exist?

[derwildemomo]

yes, they do. I'm contracting (in germany, if that's important) and about a third of the companies that hire me have high or very high standards when it comes to avoiding technical debt, adherence to sane development cycles and clean code. So yes, there are those companies.

[pjmlp]

Sadly offshoring craziness seems to be increasing here.

[fragsworth]

> I hated being forced to do this so many times in my career, I started my own company.

It depends a lot on what your company is doing, but for the most part, you'll probably discover that cutting corners to save your short-term time is often the right thing to do.

[angersock]

It depends, right?

It's right to the biz side of the house, because they have no idea what the costs of those cut corners are. They just know that they asked for shiny feature X, and then that shiny feature X was delivered, albeit with a complaint that the codebase was now Y harder to work on.

Rinse and repeat, and their interface is still "Oh, well, if I ask, the engineers will make it happen".

As this goes on, though, the engineers incur costs and suffering in order to keep delivering. And for any developer worth their salt, there is a very real cost--I almost want to say psychic and emotional trauma--associated with working on bad code.

And these engineers? Odds are, they have no big stake in whether or not the feature works. They're paid (badly) the same way either way, and don't get any benefit whether or not the new feature works.

So, they'll just leave when the continual cost of dealing with a shitty codebase outweighs the benefits of staying at that company. And they'll probably be rewarded with more money for switching!

The incentives are all wrong, and then one day your sales folks realize that any request suddenly takes waaay longer than is acceptable.

[amag]

This all depends of course of the definition of "cutting corners". Sometimes one person's "cutting corners" is another person's "striving for excellence" and sometimes it's "run project into oblivion".

All too often the short-sighted "quickest" way forward is through copy-paste some code that does something remotely similar and massage it into giving the desired output. Sometimes this is necessary, but a lot of times it is not. And every time it leads to technical debt. I've worked on a lot of code bases like this: "Copy file x, rename copy, add copy to project file, rename global names, massage into y, rinse repeat". And then you find a bug in x.

Developers are typically too far removed from customers to ever know, but often the customer is just using time as a bargaining chip. Everybody wants all their needs filled right this instance but most people are reasonable enough to know that the universe doesn't work that way. You just need to gently remind them of it and they will respect you all the more for it, at least if you then deliver quality on time.

Of course this is harder with customers who believe they know a thing or two about development. In their mind it's just change the output of x, but what they don't know is that because you cut corners in the past, you'll need to change the output in y, z, x2, x3, y2, z3 and zz as well...

[mathattack]

Indeed. Very frequently "getting it out the door" can mean enough money to hire a great developer vs just a good one. There are salespeople whose over-promising causes more harm than good, but it's not black and white.

[arenaninja]

This is definitely true in the interest of shipping anything. The problem is when new features are added to the thing that shipped, small refactorings should make it a manageable beast. Instead, <rant>you end up chasing bugs across six different files and fixing the entire thing will take a week and a half of your time because it involves moving things out and straightening the screwup that went on for three days before anybody noticed, so they insist you live on with the bug and keep chasing bugs down as they occur</rant>

[s73v3r]

Bullshit. Most of the time the corner cutting is done solely because shithead sales drones make promises without consulting engineering in the slightest. They get a huge commission for getting the sale and go home at the end of the day. We have to put in more late nights to cover for their asses, and we barely get anything for a raise because of that one time we weren't able to meet sales physically impossible promise.

[davidjnelson]

I wonder what going into sales would be like. You could try the other side of the coin.

[paulhauggis]

If there is an emergency situation where I need to apply a hack, of course. But, I always go back and take the time to fix it with an engineered, long-term, solution.

I also don't over promise features in an un-realistic amount of time.

[silverbax88]

I will tell you, as someone in the same position, that even when you get all of the time you need, and you write elegant, beautiful code, in five years that code will probably seem clunky and outdated, and someone will ask you what the heck you were thinking when you wrote it.

[ploxiln]

So, there's no such thing as good quality code that saves time in the long run? So we should just give up and hire some cheap overseas contractors because the result will be the same?

To anyone except an MBA running a software project for the first or second time, that's pretty obviously not true. (Some people, when they realize this, do "additional process will be mandated until quality improves".)

[silverbax88]

I'm not clear what your last sentence means at all. You write the best code you can at the time, but a dogmatic approach - even the one that you think will save so much time in the long run, will likely be completely useless within a few years. It sucks, but that's what happens. This has a positive spin, too - you will be much less likely to adopt flavor-of-the-month programming tactics until you really vet them, unless it's incredibly obvious as an improvement.

This is usually one of the fastest ways in an interview to tell how experienced someone is. Younger, less experienced programmers are dogmatic, but their view is extremely limited - they believe defiantly in the current coding practices, but haven't yet learned that their dogma is just the latest, and will be replaced in short order.

Hey, I was once one of those dogmatic kids, too.

[Falkon1313]

Not to speak for someone else, but the last sentence was clearly a reference to "The beatings will continue, until morale improves."

You're right though. And it's a balance between technical debt incurred having not enough time (hacky shortcuts) vs technical debt incurred from having full freedom (overengineering of unnecessary layered abstractions and indirection).

It's a tightrope and we're always going to stumble somehow. In retrospect, we tend to focus on the stumbles (wouldn't do that now!) rather than the fact that we actually got across the canyon and delivered business value. A natural bias - we discount the fact that we're making new mistakes even as we look back and criticize our past mistakes.

[juliangregorian]

After five years, you'll probably ask that of yourself! But if I was really given all the time I preferred, I'd have brought the code current with my ideals.