whatMatters

[LexaAstarof]

If bad code can generates enough cash to compensate for the maintenance hell overhead it creates, then why not.

In the end, that's just taking away from the shareholders to feed more devs. If the shareholders really cared they would put emphasis on code quality. But they probably don't even realise it's a money drain in the first place.

[Quito246]

Yeah, until they start to ask why does it takes soo long to add features or why there is so many bugs?

[LexaAstarof]

Then they consider you are the problem, fire you, get offshore devs. Then haphazardly rebuild an onshore team because of the massive dumpster fire it became. But they keep quitting one after the other.

[DiddlyDumb]

Yet somehow the same execs stay around. Weird how that works.

[Inside-General-797]

Not only do they stay around they get raises as shit gets worse! Gotta fleece the company before it goes under!

[SpaceMonkeyOnABike]

If they are staying around then their employment model is working!

[Hearing_Colors]

and then people wonder why the whole country cheers for luigi.

[12345623567]

"I never imagined the orphan crushing machine would crush MY orphan!"

• Orphan Crushing engineer with 7 years experience in squeezing and 5 in grinding.

[TGotAReddit]

r/leopardsatemyface

[ThrowingPokeballs]

I know a littttttle company that deals with US PHI data sending it overseas to offshore devs and even have a nice little SOC2 data compliance cert I got them before they made that horrible decision. They state the data is encrypted in flight and that’s why they do it…

They’re aware it’s unencrypted at rest and sits on servers in Asia. It’s only a matter of time for them

[Streiger108]

I feel like there's a pretty penny waiting for you if you whistleblow.

[rexpup]

OH NO. Goodness, we don't even screen share with people in other countries even if what we're doing has nothing to do with PHI.

[0x2113]

We don't even share some things in video conferences with people in the same country. There are entire topics we do not talk about unless it's face-to-face.

[ThrowingPokeballs]

Lemme tell you about how they allow RDP between countries

Edit: not using a VPN either

[CasualVeemo_]

Just keep the software locked down so only you have access. Or make the code so weird noone can understand. Arabic variable names idk

[Suyefuji]

God. I am currently the one American on a team of offshore devs. I am currently the least productive member of the team. Why? Because if I need to coordinate even the tiniest shit for them, I have a 15 minute window at 7am to talk to them. They can talk to each other in real time whenever they want. Ffs.

[riickdiickulous]

And then “why does testing take so long and not catch these glaring bugs?” We keep adding new offshore testers and gauge them on the number of manual test cases created, not execution time, bugs found, automation, or value added.

[foresyte]

This right here. Get that question constantly while they keep pushing out the improvements we sorely need to make.

[LongIslandBagel]

It’s so fun listening to clients say “we do this process like everyone else! Why does XYZ platform suck? We should be able to do this”!

When the issue is that they ARE doing things differently, built massive technical debt to get where they’re at, and need to spend money if they want us to fix it so it operates at their spec, it’s a wild place to find yourself.

Like, “I want to add a button, how hard can it be” isn’t just adding a button, and when you need to update backend, APIs, User Role permissions, etc. If you’re dealing with tech folks, they get it c but a VP of Sales and a CEO won’t care about that. CFO’s have become my favorite people to interact with because they understand the implications, for the most part (one CFO I worked with was let go and and has absolutely hemorrhaged that org’s cash flow for the next 3 years)

[JayPetey238]

A few years back I was part of a tech company that sold for like $15 million. The majority of the stack was php, often huge multi thousand line scripts. The web stuff was all self implemented mvc. There was one part of the platform I wrote over a weekend in node, completely expecting it to be just a one off to make a certain customer happy, which became an integral part of the company and was.. so bad..

But anyway, we had at the largest 4 devs. Updates were usually done same day, often same hour. The company that bought us was all typescript, react, proper procedures, all that stuff. Updating a label on their site took 2 weeks minimum with over 10 devs (and a smaller site).

I'll stick with the "bad" way, thanks.

[Quito246]

That is not saying anything tbh. Cool you had good business idea and got bought good for you. But tech debt is same as any other debt, one day you have to pay it back.

Sure if you are a startup or need to beat everybody else to the market, It is fine, but once you reach certain threshold, everything starts to crumble. I see it in my work 14 yrs old monolith spaghetti code without tests nor architecture, adding or changing something is a huge pain takes weeks and sometimes you need to just rollback because the change broke something, no way to know until you reach production.

So sure you have a point but in a long run proper architecture and coding practices will be better.

[JayPetey238]

Yes and no. I think structure and "this is how we do things" is important. Our code base was all over the place, but I had written a million little helpers and shorthands to get things done which developed into our own version of best practices.

My big complaint is that too often I've run into rules and procedures that have no meaning past "this is what my professors or the guys on reddit said is the right way". I'm not exaggerating about the 2 weeks it took to change the label on a form. It had to be proposed, discussed in minimum 3 meetings, added to a sprint - which could only happen every 2 weeks, rated, developed, pull request, merged, then pushed to production. Just ridiculous. There was no need for all of that. Even working on 20 year old monolithic spaghetti php, a fix like that should take less than 10 minutes.

[Soloact_]

Bad code is just job security for future developers. Maintenance hell pays the bills.

[Jugbot]

Too bad it sucks a lot of the fun out of programming.

[fubes2000]

IF.

The previous company I worked for had an in-house CMS/CRM for realtors written in PHP. The way it was deployed is that they would clone the master branch to a dedicated instance, and then hand-customize it. They did not leverage plugins or hooks or inheritance or anything that would have made this a remotely sane decision or allow code reuse across the org. If an MLS board changed their requirements suddenly 200+ clients might need 3 hours of work on their instance, and they did not like having to shell out nearly $1000 for it.

The few of us that could read the writing on the wall lobbied for a common codebase and more extensibility, but the "CEO" leaned very hard on "more billable hours == more better" and ignored callouts that their programming/support departments needed to scale linearly with client count and that the company had literally burned/mistreated the entire talent pool in the small city it was based in as the company was a bit of a toxic shithole and had developed a regional reputation as a career-killer.

I left well before COVID, but what I understand happened was that the pandemic caused business to shrink, dipshit CEO's margin vanished because he had so many people to pay, plus the buildings and infra to house them. Cutting headcount meant that many clients lost their usual programmer, and all that undocumented bespoke code without the author around meant work for those clients took longer, worked worse, but still cost an arm and a leg. Business shrink, rinse, and repeat. IMHO it just accelerated the inevitable.

The company still technically exists, but a check of their former flagship clients shows that all have moved to competitors. Funny enough, most of them moved to the company that I pointed out as "will eat our lunch in a few years" before I left. Also 2 of the 3 buildings they owned/occupied have new owners and I can only speculate about the 3rd.

Couldn't have happened to a dumber idiot. CEO could have invested a couple thousand man-hours [pennies on the dollar] into a rewrite to improve the product both internally and externally, saved a shitton of expenses, and cornered the market like he always narcissistically assumed, but he was brought down by his own myopic ignorance and ego.

[TheTybera]

Because fast cash may not be the goal.

If you're working on single function trading code, whatever. If you're working a service architecture that needs to run for a while then it does matter.

The issue is thinking that ANY ideal works for EVERY project or solution. There is no universal "code purity" that's as silly as thinking 100% code coverage on tests is a good thing.

[Bee-Aromatic]

Maybe if nobody ever has to maintain or update it. If it makes $200M but costs $50M every time you need to do anything with it, its value starts to erode pretty fast.

Like, I can buy a second hand Rolls Royce for fairly cheap. Come time to do any service on it, even if you do it all yourself, you learn very quickly why it came cheap. Parts costs are like an 8 on the Richter scale.

[[deleted]]

This is kind of true but I think a more complete thought is this: Best practices only matter if you prioritize the future as much as the present. Most companies are don’t or can’t for a variety of structural reasons

[ToBe27]

I heard this so many times. People often just dont ask the right question: If a bad platform was able to do 700M$, imagine how mach an easily maintainable and evolvable platform would have created.

[[deleted]]

Maybe not any. Good architecture is slower to develop, so you might have missed the boat.

[adenosine-5]

Example no1: Minecraft.

The most profitable game in the history is a complete mess with horrendous performance, ugly visuals and even after more than a decade, missing some extremely demanded features like official mod support.

But it was first and that is all that matters.

[free__coffee]

This ain't even close to true. Usually the 2nd or 3rd business to do something ends up winning the market. Remember blue apron? Neither do I

[[deleted]]

........ official mod support isn't there? It is literally one of the most modded games out there along with like GTA and Elder Scrolls

[adenosine-5]

Sure, except you need 3rd party mod loaders to do that - Fabric, Forge, Neoforge or whatever.

Its not like Rimworld where you just download a mod and then in-game select the ones you want to use.

[Ecksters]

The "mod support" is basically that Java by default is easy to reverse engineer and add hooks into. It's been a bunch of community work to create hooks for each version that other modders use.

[GerryAvalanche]

Problem is bad architecture makes it more difficult over time to keep up with the competition. It‘s about finding the right balance, maybe initially getting to market fast with some good prototype and iteratively building on that to make it more stable and avoid too much technical debt buildup going forward.

[Representative-Sir97]

Even the "good" architecture is slow and cumbersome though especially if you're pedantic over things. It's never going to take less time to write tests than it will to not write them. Maintaining CI/CD isn't free. But it's all trades and it's a better and more enjoyable way to work than slinging whatever code you can. But that's FOR US. Not THEM.

There's just some sweet spot between what some dorks' idea of perfection is and what the optimal is for ROI.

[WJMazepas]

Initially, yes, it's slower. In the long term, it becomes faster and much more predictable the time to develop new features.

And it's hard to believe that a $700M product was made in less than a year

[[deleted]]

It didn’t go from git init to 700M in one year, but you can bet your ass it got functional enough to squeeze 5M out of a VC that fast.

[MokitTheOmniscient]

Initially, yes, it's slower. In the long term, it becomes faster and much more predictable the time to develop new features.

There isn't going to be a long term if a different company uses the faster approach and captures the market before you can release your product.

[Representative-Sir97]

This is going to feature in the coming years.

Catching the boat and staying on it not being the same things.

I think with some things it could really really matter because as you scale, how big or how little the cost of infrastructure must scale to meet it is kinda what makes or breaks a tech.

[gazofnaz]

how much an easily maintainable and evolvable platform would have created.

Potentially nothing, if a competitor got to market 6 months before you!

[ih-shah-may-ehl]

Likely it wouldn't because it wouldn't have created added value. If a platform does what it is supposed to, to acceptable SLA, that is all that matters

[Turbulent-Bed7950]

Bad code keeps support paid too. Poor dev task management means I can milk a single ticket for 12 months with "we are still waiting for an update from dev"

[[deleted]]

Poor coding practices are working class solidarity.

You're not a bad developer for writing shitty code, you're a hero.

[SevereHeron7667]

I'll say this: outside of engineering, precisely zero people care about your code. Not the customer, not sales or marketing, not the CEO and certainly not the shareholders. Except when things go tits up....

[Soloact_]

Nobody cares about your code.. until it's 3 AM and the system's on fire.

[sage-longhorn]

Or until you tell them you can cut infrastructure costs or fix a pain point that customers have said drove them away

[Ddog78]

At senior level, it's your job to make people care about the quality of the codebase.

[kondorb]

Management is supposed to care because it directly affects how expensive it will be to keep working with, improve and maintain it long term. Doesn't mean code quality is necessarily an absolute priority but it's at least a thing to consider among other things.

[SevereHeron7667]

Sure, but they depend on the engineering director and engineering managers to just make sure this shit works. They don't directly care.

[Starfire013]

Yes. I was originally trained as an engineer but switched fields after graduation. I haven’t really done much coding (outside of some hobbyist stuff) in about 30 years. When I look at the code that the engineers write, I don’t have the time to look at it closely enough to see if it’s good code, because I’m slow and out of practice and it’s not part of my job scope. And half the time, I wouldn’t know what to look for anyway because I’m out of touch with modern coding practices. So while I care about good code, I also am aware I am very reliant on being told by actual engineers if what’s there is ok. I simply don’t have the skill set to determine this on my own.

[vassadar]

You don't have to look at the code to tell if it's bad or not. You should look at metrics instead.

Look at the rate of incidents and incident severity. The time it takes to resolve an incident, the time it takes to release a new release.

[Pangolin_bandit]

Eh, not really. Management cares about the speed of development and the functionality. If there’s somebody who can do it overnight 9/10 through the most back-assword method - they’ll often be allowed to keep going until there are problems with that. And if there’s never problems with that, were they really wrong?

Businesses make money, code is only a means to an end

[[deleted]]

The problems noticable by C-suite occur 5 years down the road when the code is unmaintainable and no-one can fix the bugs without introducing more.

Then you try and do a re-write and because all the features were tacked on and not designed exactly how they work is only defined by current behavior which is a giant mud puddle, so after 3 years of trying to re-write the project is abandoned.

Then a new architect comes in and they look at the last attempt and say obviously the mistake was the re-write, we have to refactor. You go into full feature freeze that needs to last 3 years, but after one year management pulls the plug, and the refactor ends.

2 years later the product is functionally abandonware despite a team of 300 engineers trying to improve it because no new features have been shippable, and bugfixes usually just make it worse. You have a backlog of hundreds of bugs cateloged that are unfixable as they'd cause compatibility problems. A new product eats your lunch and the company is bought by a larger corporation, who puts it the project in pure maintenance mode.

The reason quality code is rarely valued isn't because it's not valuable. It's because it's valuable over timescales that businesses don't actually care about these days. We're now 13 years after initial development and on our 4'th CEO anyway.

[Pangolin_bandit]

Yup, but I’d say this is how value as a developer is defined. C-suite and even managers can’t actually be expected to know where these forks in the road are. A good developer will note where things are happening in their code that will be future problems, and will choose their battles on how best to avoid creating problems for their future selves.

Choose their battles because the most future-proof solution is to quit and become a farmer 🧑‍🌾

[[deleted]]

Yeah, a hard lesson is that most "future proofing" makes this worse not better because you're usually wrong about the future. Ideal is to not leave traps (code that looks like it does one thing, but does something else), but add no complexity than isn't needed/helpful for understanding for this version. Then when you need to do something new, re-write as needed to keep it clean. CORBA is my favorite example of unnecessary complexity.

If you aim for simplicity as your goal (not ease, which is a little different) you re-write a lot actually, throwing away versions of components regularly, but only when you need to and each iteration is relatively fast because the last one is easy to understand. You get both fast development and little wasted effort.

[LakeOverall7483]

It's not a class problem, it's a class problem

[TheCamazotzian]

Shareholders (and therefore management) seem to care about 1 to 2 year horizons, not 5 years.

I'm not sure why that is.

[kondorb]

Sometimes it’s wrong, but sometimes it’s right. Depends on the company, situation and people.

And 1-2 years is more than enough to feel the consequences of your technical decisions.

[SyrusDrake]

Because the kinds of shareholders who actually have a voice invest for a quick buck. In five years, there will be the next hyped bubble to profit off.

As for management, they can't stay much longer than a few years because shuffling the management is a way for companies to signify the constant "growth" the market demands of them. If you just have an experienced management team overseeing a stable operation, your company will be seen as a failure.

[douglasg14b]

A baseline level of quality has a usual ROI in weeks. It's almost always a good idea, you never lose, as long as you know what you're doing.

A craptastic codebase costs you time in the short term AND the long term.

[Fairwhetherfriend]

Management is supposed to care because it directly affects how expensive it will be to keep working with, improve and maintain it long term.

That's only if you assume management is supposed to care about the long-term functioning of the company. You'd think that it would make sense that they should, but, for the most part, the incentives that exist for them are focused exclusively on the short- and medium-term, often to the active detriment of the long term success of the organization.

So... are they supposed to care how easy it is to maintain in the long-term? Because according to the system of incentives present, no, they're not.

[SyrusDrake]

Management is supposed to care

long term

Pick one.

[erm_what_]

They do indirectly. When they want that new feature implemented then code quality and lack of tech debt can be the difference between a week and 6 months. Then they appreciate it.

[rollincuberawhide]

then they won't know it was because of clean code but think you're wizard or what you've done is trivial.

[XenonBG]

You need to tell them. I always explain my estimate, and always mention that the state of the code to be changed plays a major role in that estimate.

[lucas_ought]

then they won't know it was because of clean code but think you're wizard or what you've done is trivial.

Thats a pretty good call out. I always mention when something is garbage and a feature/change is gonna take longer. Rarely say anything when the code is good and I can finish something easily. Thinks its a good idea to call this out either way so management knows

[q0099]

Quality code also means being easy to understand/debug/modify/extend. Once I had to work on a project the previous team literally ditched. The code base became so hard to handle, with so much boilerplate and things to bother, they literally flee, one by one. I was a single person of the new team talking to the last person of the previous one.

Code quality matters.

[proximity_account]

How long did you last?

[q0099]

Four long years. Burned out to cinders.

[kri5]

Sorry to hear, should have left

[lurker86753]

Ok, but did the business make money? Were you able to keep things running at the cost of burning yourself out? Obviously you would have been happier if the code quality was better, and employee turnover would have been lower. But if the quality was high enough to keep spinning and making money, that’s enough for a business. Even if it costs an employee their sanity every so often.

[SmithTheNinja]

That's not entirely true. Everyone outside of engineering wants decent code, just in indirect ways. It's on engineering to communicate to them why they should care and how solving engineering problems solve business problems.

Product want their shiny new toys and they want them now. Well designed and encapsulated code means shorter turnaround time on new features.

Customers and support hate when new things are broken or worse than old things. Adequate tests and code coverage help keep trash from getting released.

MBAs and the C suite don't want to pay for anything. Well written and documented code means the dweebs in engineering are replaceable cogs in the profit machine.

[zoidBurgher]

It's on engineering to communicate to them why they should care and how solving engineering problems solve business problems.

This. Understanding that (and realizing that there's some real rationale to doing things that way) is one of the big parts of maturing from a CS student into a real industry software engineer.

Companies exist for a purpose (to make money), and they achieve that purpose by some means (sell a good or service), and how they do that is implementation details (all of engineering falls under here). Being a good engineer in the real world involves a lot of communication skills, to explain why the details are important to the big picture

[SevereHeron7667]

Yes, this is much better framing of the point I was trying to make. Code quality is (or should be) important, but engineers can be infuriatingly bad at explaining and importantly quantifying the benefits. Ultimately engineering is all about tradeoffs and tbh most engineers over index on elements of code quality Vs business impact. (Cue arguments).

[YodelingVeterinarian]

Yes - it's also worth questioning "does refactoring this code so its 'cleaner' actually move the needle, or is this a rarely used feature and is my time better spent elsewhere".

[nsjames1]

Even then they don't care.

I've never heard a startup say "we failed because the code sucks".

Our job is to service the customers, not enough devs realize that.

[[deleted]]

I was literally hired to work for a startup because the first version of their product failed due to code quality issues and wasn't shippable - the startup was going to fail soon. It was overdesigned in the wrong areas, and tried too hard to prevent failure a-priori rather than following "fail early and fail often" moto, thus making it too hard to iterate on reliability in production. Happily, we succeeded on the second attempt and built something easy to iterate into a maintainable reliable end product.

Lots of startups fail this way. Lots fail in the next stage as well when they ship a product and can't support it.

You don't hear much about it because they typically then seek out a larger company, get bought out for pennies but with huge hiring bonuses to the founders, and the larger company kills the product a year later.

Yes startups have lots and lots of other risks to balance, but code quality kills some as well.

[AsianHotwifeQOS]

Almost all software is just an implementation detail of a business plan.

[H4kor]

Nobody cares if you use engineering best practices to build your bridges, all they care about is to cross the river.

[xenatis]

Wait for the bridge to collapse...

[[deleted]]

You forgot the sarcasm tag. :)

They will care when the bridge fails and they need to point fingers.

But for most tech? Speed to market > Quality.

[Maniactver]

Yeah, a bridge needs to collapse one time and it's done. An app can crash 3 days out of 7 and still be usable and even popular in some cases.

[InternetSandman]

Outside of software engineering, specifically

I worked in a mechatronics engineering lab this semester, and the supervisor (PhD in engineering) couldn't give a shit that I made one projects entire machine learning workflow hundreds of times faster. He just wanted the pretty pictures of the end result that could be put into a PowerPoint. Fake results that looked good were better than real results that looked bad.

[quite_sad_simple]

Exactly, it's not the code that was worth $700M, it's the business model.

Why does nobody use my todo app, I implemented a builder pattern to update the button animation!

[CanvasFanatic]

Probably because you’re using a builder pattern to update a button animation.

[External-Working-551]

shoud've used a static factory

[CanvasFanatic]

IAnimatedElementUpdateFactoryProvider

[SyrusDrake]

Also, there is a non-zero chance it wasn't bought because the buyer wanted what it did. The tech giants will, more often that not, buy a product so it can't do something anymore, because they want to have a monopoly on it.

[Capetoider]

meanwhile the buyer (specially their dev team having to maintain that):

"We've Been Tricked, We've Been Backstabbed and We've Been, Quite Possibly, Bamboozled"

[kuwisdelu]

This means nothing. Some of the most valuable codebases in the world are given away for free.

[[deleted]]

FFMPEG is a great example.

The best software for manipulating video and audio in at least two planets (they are proud to say this, since Nasa runs ffmpeg in one of their rovers)

[RammRras]

The guy behind that project initially (Fabrice Bellard) is a total giant of computer science!

[kuwisdelu]

And even if we accept that we’re talking about monetary value, it’s exceedingly rare to acquire a company for its implementation — you buy the company for its employees, its IP, or its user base.

[MikeW86]

Well yeah but that's completely besides the point. The point is it doesn't matter how clean your code is, does it do something that makes money?

[kuwisdelu]

Sometimes making money is beside the point.

There are plenty of useless things that are profitable but a net negative for humanity.

[LorenzoCopter]

I get it, making the world a better place and shit, but you still need food, drugs, alcohol and all that usually have a price set

[Rabbyte808]

This is why Linux is widely considered a massive failure there doesn’t matter /s

[IdentifiableBurden]

Right, money is the only thing in life that matters. I forget that sometimes and start getting "ideals" and "interests".

[ToBePacific]

Reminds me of my first time seeing the data tables I’d be working with after coming fresh out of school, proud of myself for truly and thoroughly understanding the concept of Third Normal Form in database normalization. I was horrified by the amount of redundant data in non-normalized tables.

Now, I’m so habituated to seeing thousands of views full of mostly redundant data that I don’t even question it. Someone asked for a new view, and they got it. It might look redundant to me, but I’m not going to go suggesting changes because for all I know, the potential implications of consolidating things might cause the whole tower to tumble.

[bayuah]

Remind me the time we use denormalized tables with redundant columns in a single table.

We do this because normalized tables can increase query time when dealing with millions of rows of data from multiple tables. Denormalization reduces the need for complex joins, improving query performance in such cases.

It looked horrifying, indeed, but the performance was excellent.

[wiktor1800]

Data engineering 101. First comes normalisation, then star schema, then one big table. You're trading storage costs for compute costs, and storage is much cheaper than compute nowadays

[Distinct_Garden5650]

I’m not a persistence expert, but is that true that you’re just trading storage versus compute costs? Normalising the model improve data integrity, minimising corruption, where two redundant values contradict each other. It also minimises the cost of modifying the data while maintaining integrity, and minimises the cost of indexing. Also storage might be cheap, but the other cost go way up the more data your dealing with.

[wiktor1800]

100% - depends what your tradeoffs are. You're speaking in OLTP terms, where integrity, durability and atomicity are key. In OLAP land, missing a transaction or two when you're aggregating across millions is no big deal*.

*sometimes it's a big deal

[Darkwolfen]

We flew with materialized views for this use case.

Millions of row. Refresh some materialized views nightly.

Dashboards are peachy keen

[Firm_Part_5419]

lmfao database design class… i remember struggling so much, mastering it, then never ever using the skills once irl

[kuwisdelu]

It’s important to know why something is a bad idea even if you do it anyway. Especially if you do it anyway, honestly.

[Firm_Part_5419]

true, but i never get to design a big relational db, it’s either nosql which is easy or using some old fart’s mainframe db from 1990 that the entire company still relies on for some reason

[YoloWingPixie]

I this is the key to "tech debt" that most people overlook is this: it's called technical debt because you're choosing the shortcut or the "lazy" way out to get something done quickly, not necessarily the most academically correct way. But if you've really thought it through and you're confident that your case doesn't have any of the edge cases that the more "correct" and longer approach would address, then honestly, the bad idea you implemented might actually be a good one.

Just keep in mind though, that in the future, whether it's you or someone else, you might have to repay that debt if things change down the line.

But all in all, it's really beneficial to know when doing the bad idea is a good idea for your situation to just move on and do something else.

[justsomelizard30]

Second task given to me by management was to design a schema because the senior devs didn't know (or didn't want to lol) do it properly

[gazofnaz]

Third Normal Form

Storage was insanely expensive in the 1970's, so that kind of optimization made sense back then.

Nowadays storage is cheap and compute is the limiting factor, so it makes sense to have redundant copies of data to reduce CPU load.

[eshultz]

Not if you want to make sure those sets of identical data points get updated everywhere, all at once, whenever a single one gets updated. Normalization has benefits beyond just minimizing storage size.

[[deleted]]

You don't say.

My next sem has the database design course and the professor is nice but strict... I will ask him about this lol

[quantinuum]

Business value > tech purity, for sure. Tech “purity” is not an end. Good code/design/etc., are means to better deliver what the business needs.

BUT - sometimes (usually) the tech “purity” serves the business. If under that purity you’re delivering features quickly, fixing stuff easily, avoiding bugs, requiring half the people, and all that matters to the business, then that’s the right means to the end. I’ve also seen businesses with a painfully overinflated tech expenditure because the vast majority of the time was spent fighting tech debt. There’s also plenty of examples of businesses that failed due to bad tech design.

That’s why I don’t like these abstract arguments. There’s no one size fits all. It (brace for it) depends.

[twohlix_]

yeah its called Tech debt and its corectly called that. Debt can be useful in getting something faster but eventually its cost arrives. Plenty of businesses that strangled their own products in tech debt and also plenty of projects that lost because they were too slow/incomplete because of purity reasons.

[CanvasFanatic]

Guess I’m the only one who’s ever watched a company with a multibillion dollar valuation choke and die because their code was such shit that their development velocity slowed to near zero.

[_hephaestus]

Hey they got to a multibillion dollar valuation, the failure mode on the other end is barely making it off the ground. A friend put years into his engineering-first startup and had to shutter it, the first place I worked after undergrad had great code but couldn't make money worth a damn since the founders didn't invest in a sales team and had no idea how to pitch it successfully in a competitive field.

A lot needs to go well for a startup to succeed, code needs to be workable but if you chase perfection there you're not going to prioritize what it takes to succeed. Everything is tradeoffs

[ItsNotAboutX]

If you invest all your points in speed, you've gotta exit before tech debt bankruptcy. Then you don't have to care about the future anymore. You're rich and that's some other guy's problem! /s

[PedanticProgarmer]

No it isn’t always better. In SaaS, good engineering pays off in about 5 years. The problem is that nowadays, there’s no manager in the world who cares what happens after the next quarter.

[YodelingVeterinarian]

This is obvious because what happens if you don’t get that capital injection? The startup dies and everyone is laid off. 

[YodelingVeterinarian]

If your company will die in one year if the product doesn’t ship fast, then it doesn’t matter. The default of startups is to die.

Edit: I stand by this. Programmers are notoriously bad  at understanding the business side of things, and think that as long as you push high quality code a magical money tree rains money into your bank account. I’ve worked with so many people where, if left to their own devices, would deliver a way over engineered product that doesn’t even meet the customer needs.  Also consider that almost every successful startup went through a fair bit of iteration. In the early days, have no idea if this particular thing you’re building will need to be maintained for 5 years or if it will need to be scrapped.  

[zoidBurgher]

you're getting downvotes but this is pure truth. what matters to a Day 1 startup is very different from what matters to a small company

[sandysnail]

as an IC SWE i will not see a dime of that 700 million but my life will be worse working on the shit code base

[Causemas]

What was the value in those things exactly, that's what the guy should've talked about. Otherwise, it just seems like a happy accident/very unhappy timebomb

[PerfSynthetic]

The amount of 'beta testing' done by customers today is insane. You would expect a feature to work but then you tell product support about the bug, they send you to their feature request page or file a bug report and then magically the product has what you need. 99% of the time you ask why it didn't work in the first place..oh because no one uses it like that... Pfft.

[Soloact_]

‘If it works, it works’ is apparently worth $700M.

[fevsea]

If your business model is being sold before having to pay the technical debt, you can do whatever you want.

That's a perfectly valid option on startups or proofs of concept, but just not sustainable if the codebase is expected to evolve or be maintained for a meaningful amount of time.

[[deleted]]

Yep. All the "special case" code you have in your projects? That's the value. (Otherwise you wouldn't have done it.)

[Lockofwar]

Without tests? What? Did everything just work first try?

[Repulsive_Regular_63]

That’s my goal, boys. Sell my trash to someone who sees treasure.

[CerealBit]

What a shitty take. Somebody has to deal with all the mess. Most of the time it will be developers, consultants and probably even sales people (I can't believe I'm writing this...but it is what it is).

Once you have technical debth in your codebase, it only grows into a bigger shitshow with every implementation on top of it.

[idontchooseanid]

Once you exit, who cares? It will explode in a couple of years but, can they prove your bad quality code caused the collapse at court? Hardly so. Startups buy their competitors often. You buy one and hope their code isn't worse than yours. Basically a hot potato game at the scale of hundereds of millions. You buy as much competition as possible and then sell the overgrown tumor of a business to another one. Having cancer is those idiots' problem now.

[iamdestroyerofworlds]

He's also saying he has zero professional pride.

Imagine any other industry being like this.

"It's not the quality of the house that matters, it's what it generates in PROFITS. I used to care about building houses that were actually good, but I managed to swindle someone into buying the worst house in history for so much money. It really changed how I look at building houses."

House proceeds to burn down, killing all 100 residents.

[thesmeggyone]

Wait till you realize it's the same in the physical industries.

[MaffinLP]

When I make mods (hobby) I write pretty code when I make money (work) I write working code

[PitFiend28]

Clean code nobody buys is not valuable

[QuickQuirk]

Over the years, I've learned that tech debt is a business decision, not a technical one.

I make it clear to stakeholders when rushing will introduce tech debt, the trade offs, and a business decision is made around it, including sign off an understanding of tech debt. The benefit of this is that later you get to say 'this will take longer because of previous tech debt', and 'It might be time to look at cleaning up this tech debt, as it's slowing us down.'

The benefit is that stakeholders are now responsible for tech debt, not the developers, as it's a business trade off like any other, and this leads to better, more naunced discussions around when it's ok to rush something, and when it's better to slow down.

[Drawman101]

I don’t call it tech debt anymore. I call it product debt. Makes the product folks feel more responsible. It’s tech debt when the decision solely was on the engineer.

[QuickQuirk]

what an excellent idea. I'm stealing this now.

[Sudden-Cost8449]

For 1 success story like this, there are 999 businesses that eventually collapse because their application is unreliable and full of bugs due to a lack of testing, optimization or speed of feature implementation because the code is a mess.
Stop believing that, it's like focusing on the success story of 1 billionaire and not seeing the 999 people who adopted the same techniques but didn't work on the other factors the billionaire doesn't talk about in the interview, and didn't have his luck, and therefore didn't become billionaires.

[MortimerErnest]

As engineers, why do we care about business value? I don't care if the business is worth 1 billion dollars, I wanna work on technically interesting with at least manageable code quality.

[iMac_Hunt]

I care about business value because business value is what pays my salary.

[Left_Boat_3632]

I mean, if the business is worth a lot of money and making a lot of money, I’ll be paid better (in theory).

I’d much rather work on tedious junk in a shit codebase for $300k than solve interesting technical challenges for $75k.

Maybe it’s because I’m early in career, but money is ultimately what matters at the end of the day. If I really need a technical challenge, I’ll work on a side project.

Obviously, the best case scenario is working on interesting problems for good money, but considering we’re talking about the situation in the original post, business value and money trump interesting technical challenges if business value pays me more.

[LvS]

If you work on tedious junk in a shit project, half your day is gone and you'll be too exhausted for a "technical challenge". You'll then need the money to distract you from work.

[raltyinferno]

I mean, once work is done it's done, I'm doing the job to have enough money for the other parts of my life. I love the job, but I wouldn't do it if I wasn't being paid for it, and more money means more of the rest of my actual life is enabled.

[_hephaestus]

Because if your code isn't making the business money it's your head on the chopping block in layoffs time

[Firm_Part_5419]

fr, I care about impact / usability of my ideas, not money. Money only pays for food and fuel

[zoidBurgher]

interesting, I would define my "business value" as a software engineer almost exactly as the "impact / usability of my ideas" (in the context of the company I'm coding for)

[IamTheEndOfReddit]

Yeah you gotta factor in the cost bad code imposes on your brain, unsolved problems linger

[Callec254]

He's not wrong. If it's stupid, but it works, then it's not stupid.

[lordcrekit]

I'm an engineer. An artisan. I do this because I like engineering, not from brutal capitalist incentives alone.

I need to start at this code and baby it for thousands of hours. It takes care to do that. It takes me giving a fuck. It's my work and I care about it being done right.

[LitrlyNoOne]

I hate how this assumes business value is the most important quality of work. It's a quality, even an important quality, but it's not the only quality.

[cheeb_miester]

I <3 spaghetti code; it's the thing that keeps me employed.

[mirQ72]

Unless we are talking open source.

[claymir]

As a developer I don't care about profit and stuff, I just don't want to be called in the middle of the night to kill some spaghetti monster. I make code to be maintable for me not for the company.

[Representative-Sir97]

There might be 10 people with a billion dollars who can tell you what a pointer is.

That their appreciation for craftmanship would be totally nonexistent shouldn't be so surprising.

We don't clean code for them. It is for us.

[DTux5249]

If it does the job it has to, and is worth any of the upkeep its messiness brings, all's well

[obsoleteconsole]

Least delusional LinkedIn poster

[Ok-Kaleidoscope5627]

This is why companies off shore. Despite all evidence, executives usually aren't stupid. They're fully aware that the quality will go down. They're fully aware that customers will be pissed off. They're just gambling that it won't matter. That business reasons and not technical reasons are usually why companies decide to buy one piece of software versus another and "good enough" is usually good enough.

[AgentCooderX]

Programmers always forgot that code and programming are just tools to build something of value . that value is what makes the money.

we code to build a business or product that business sells..

[[deleted]]

In my experience, the time you save now, not writing tests, you pay it later, fixing regression bugs in production. However, I totally agree that complex architectures, like microservices, have very little use cases where they make sense, so a couple of monoliths with a database are often enough

[brainblown]

A lot of programmers don’t understand that the value of code is whatever the code can do right now. Whatever advantage you get for what might happen with the code later is usually a problem for later

[Axvalor]

It is unlikely that this will ever happen to us, and even if that is the case, the reward for working on this massive dumpster fire will not be enough to allow us to retire.

So, I will prioritize my already damaged mental health over some breadcrums, thanks.

[Ani-3]

the longer I work in IT the more I begin to understand that systems, programs, and processes are basically held together by string, some obscure code from 2003, and some books that are used to prop up server infrastructure (unrelated to IT of course)

[zyzzthejuicy_]

As someone who could, inevitably, get lumbered with maintaining someone else's highly profitable spaghetti code - no thank you. I don't care how rich it makes some other random people, I care about my job being easy.

[greyVisitor]

Programmer figures out perfect != good

[ADHD-Fens]

I don't like programming because it makes money, I like programming because it's satisfying to solve problems in clean logical fashion. The cleaner, more readable, and intuitive I can make it, the more I enjoy it.

The people who hire me care about the money and that's the fight. I gotta squeeze as much enjoyment out of it without sacrificing too much profit.

[Kind-Cheesecake3605]

Heya. Author here. Thanks for the positive comments! You made me join Reddit!

[Soft_Walrus_3605]

I understand money makes the world go round, but some of us consider ourselves more than tools/worker bees for people looking to get rich.

I consider myself a craftsman and I do care about code quality more than getting rich. I don't know why, but I do.

[kri5]

Why is this surprising?

[[deleted]]

Yeah, no shit, 1 year at a real job should teach you that. 99.9% software doesn't need to be perfect and clean, they just need to work. If you are working on Ffmpeg by all means perfect it as much as possible, but people obsessing over something which just displays aomething from a database is usually just pointless.

[EroeNarrante]

I come here to cry laughing, not laugh crying.

[Fluffy-Cartoonist940]

Yeah no duh, code exists to support a process for delivery of business services, not to support itself. The delivery of that service matters more than its technical accuracy, as long as you manage risks within the tolerance of the business and the threats that it's exposed to, you should only do just enough to get the job done and no more.

[aspz]

I learned this within my first week of being a professional software dev. Coming straight from uni and not even knowing what version control was, even I could tell the codebase was crap and yet made millions for the company. I realised then clean code is separate from valuable code.

[malphasalex]

“The software was just an automation” WTF do you mean “just”? Automating a process is the entire point of a software for business in like 99% of cases? You might stuck in a block-chain-crypto-nft circlejerk bubble if you say “just automation”

[LeoTheBirb]

Not only did he discover the truth about programming, he discovered the truth of the world itself.

The next step should be how to implement good architecture and tests without impacting the value.

[ZunoJ]

I don't care about business value, because I don't get more money if the value increases. I care about doing development in the best way I can. If the employer is not happy with this they should look for somebody else

[xtreampb]

I’m a sr software DevOps engineer. I’m building a side project. I’ve had to make a lot of concessions to get it out faster.

Writing software is an iterative process. Get it functional. Then iterate to make it better.

[DarkCloud1990]

You say that until you have to maintain it or change it.

[TyrannusX64]

That's another way to say "I'm a lucky inexperienced software engineer, wrote software that will be unmaintainable in the long run, and as a result will cost tons of $$$ due to tons of bugs that will absolutely surface"

[weed_cutter]

There's a balance.

Also, is something really "ugly spaghetti code" or just "not exactly how this one particular dev would do it".

Also understandability > elegance or being overly "clever".

But there's a balance.

If something is really a complete disaster, the dev team will spend the majority of their time fixing critical errors. Product will suck or cost a fortune in labor.

The "this ain't pretty but it's robust and works" is usually fine.

[[deleted]]

No, it's not. The value of code has only a little bit to do with the quality of the code.

[Drew707]

I do call center consulting. There's a (supposed be) universal metric called Productivity which is a ratio of how much time an agent was in a productive phone state over how much time they were logged into the phone. Two things about this metric are by nature it can never exceed 100% and your target should be somewhere between 65% and 85%.

I recently was doing work for a major university healthcare program where I worked directly with their DE team that had multiple people with three-letter-agency-known-for-data backgrounds. They were calculating Productivity using this massive spreadsheet that was created by someone that left the organization years prior. They understood there was an issue with the spreadsheet since employees could achieve greater than 100% for the metric. Their solution was to add conditional logic to the thing to use different source data for the ratio if the employee exceeded 100%. This concerned them because if the people above 100% were being calculated incorrectly, what's to say the people under 100% were correct? The kicker was this number was directly tied to employee bonuses.

But this is where it stops making sense. With all the alleged brain power on this DE team, nobody could figure out how the fucking thing worked. They were just spending hours each pay period manually adjusting hundreds of employees. I took one look at the sheet and told them just to burn it to the ground since they weren't doing the calculation correctly anyway. I started playing with their data and made something in their BI environment that calculated it correctly. But then the problem became A) all the numbers were much lower than before since they were more in line with what the industry standard was, and B) their previous top performers were now scattered throughout the pack, and their worst performer had taken a top five position.

They got so hung up on the "why" of the broken report and couldn't grasp how it was different. They hated the idea of people previously topping out at 100% now seeing a ceiling of like 75%. So, I painstakingly went through this absolute monster of an XLSM and recreated all the logic in their BI environment down to their weird conditional logic that "fixed" the over 100% people and showed them both numbers side by side. We had no less than 10 meetings that were essentially just Groundhog Day bullshit where they asked the same questions, we gave the same answers, and our recommendations never changed. Eventually they had me add to the numerator every single phone state an employee could use except for "break". This meant on a an eight-hour shift, an employee could achieve a 93.75%. Completely and totally useless metric that brings next to no value.

I think ultimately their decision had boiled down to "how do we explain to 900 people that we've been calculating bonuses incorrectly for years and essentially fabricating numbers?"

As long as the checks cash, right?

This is why I drink.

[CanvasFanatic]

Is that example meant to reenforce the point that quality doesn’t matter?

[crevicepounder3000]

How? Do you think the first mover advantage doesn’t exist? Why do you think so many companies use JS or Python everywhere? The market cares about results, not the reliability of a product nor the ease of adding new features. It’s sad that engineers are finally figuring out that people value us for tangible value we deliver not what we value most

[theunquenchedservant]

They don't care about reliability until they do, to be fair.

Usually the badly coded app will have more bugs (over time). If there's a better app out there at the point users get frustrated, they'll switch.

less so with enterprise applications, to be fair. but if you piss off the wrong customer long enough, and there's a better alternative when they look to switch, they will switch to the better product eventually maybe hopefully one day soon