Why is source code so crappy? May career is not the longest, buy in my 8 years I talked to so many developers and every one told me how important quality, standards, tests and architecture are - but every codebase I've seen is lacking all of it. Everything is running on constant live support.

I don't get it. It is like I live in a world where everyone does know what has to be done, but no-one does it. I suspect it is because people are lazy, lying and won't say no but that's also not a world I want to live in.

Because we don't live in a perfect world. Requierments are always changing and there is no time to change the entire design when that happens.

That's a great question actually, and I think there isn't "that one reason" that, once eliminated, allows us to only build great quality software.

Unreasonable deadlines (and devs adhering to them), inexperienced devs, our profession being relatively young, misunderstanding/mismanaging development as a production activity, to name a few. And, sure, like you said some are just lazy. 😉

@DeepSpace I think that’s just an excuse, if a new feature would require major changes to build it well you have to make these changes, building a crappy version of the feature should not be an option.

If this happens your environment and design is or will grow antiagile.

Higher ups don’t give a fuck about quality (unless they want to sack you for some unrelated shit reason). Clients want, sales guys promise, devs do the impossible and worry about it later or jump ship if the spaghetti and workarounds get too hot to handle.

Well, people talk about it as it should be standard. It's good.

What is bad - it's managers who are not even related to tech and sells unreasonable feature for the client to be made in two days. Personally, I've had great projects starting with well thought out architecture, the code was clean but then came times where:

- We had to release feature within 2 hours of getting details
- We had to rewrite features completely within day or two.
- We had a slim budget
- The client was frustrated that things take too long to move into production.

And many more... So the code base was trashed and nobody gave a crap anymore.

Why is this true? Well, because you work with a smaller business who wants everything NOW!!!!!!!! and not bigger companies that are ok with waiting at least a week for a feature to be developed.

Not to mention - all of those URGENT!!!!! labels/words that mean nothing but you still can't waste 10 minutes on test writing.

Unreasonable deadlines and unclear requirements which tend to change over time with little change in the timelines. Generally occurs when business or non-technical people decide to do the technical planning and set timelines.

@rutee07 nice wifebeater avatar, there should be beer on your shoulder.

@sciobotaru And money

@UnmutableToday Look, if you take 6 months to do it the proper way, and a competitor 2 months for the dirty way, this means that he'll get all the market share, and your company will get bankrupt. By the time your clean product appears, the market is saturated, and because of opportunity cost, people won't change.

Product delivery is the MOST IMPORTANT feature of them all.

Even as someone who spends a lot of time researching design patterns and code cleanliness techniques, I've pushed some real 💩 code to production with the intention of fixing it later.

Later becomes tomorrow, then I change jobs without ever getting time to go back and clean up stuff.

Business demand + clean code don't always marry.

@Fast-Nop the most code is not written in Start-Ups

@kshep92 that’s plain unprofessional

@UnmutableToday doesn't matter, it's the same everywhere.

@Fast-Nop it does matter, most software products are not in such a situation.

@UnmutableToday What market share does the second player have? E.g. The one after Google, the one after Facebook, the one after Twitter, the one after Ebay, the one after Amazon, the one after Wordpress, the one after Chrome? See a pattern?

@Fast-Nop in the 6 years of my career, I've literally never had time pressure due to a competitor. It's definitely not the same everywhere.

On the other hand we still had unreasonable deadlines. My favourite: "Hey dev team, that huge legacy middleware you're maintaining? You'll break that up into microservices, isn't that exciting!" - "Yay new tech!" - "You have six weeks." - "... for learning about microservices?" - "For getting it done."

(it didn't get done in six weeks)

@VaderNT Well yeah, the next factor is whether you can get anyone to pay for that. No customer pays for a refactoring just to be able to do the same as with the previous version.

That's especially bad when doing the next version from scratch to have a clean start, which is the single worst strategic mistake a software company can commit.

@Fast-Nop I see a pattern, all these company's provide B2C Software and still represent a tiny part of the overall software marked

@Fast-Nop Sure. That's a situation where you have to give the customer what he actually wants.

A customer expects he can order new features many years down the line. That is such a basic expectation that it's not even mentioned. Compare "for a change, this week I'll buy bread that doesn't kill me". Non-lethal food is taken for granted, as is adding new features.

He'll understand it takes longer than when the software was new. He'll not understand "sorry, code's a mess, you should have told us to keep the code maintainable". It's our responsibility. And that's fine.

Complete rewrites... well it killed Netscape. That should tell us something, these guys were no amateurs. Imho rewrites yes, but only iteratively.

@UnmutableToday what about B2B? Just look at the market share of Boeing and Airbus, respectively. About on a par. Guess why Boeing rushed the 737-Max? Because Airbus had the A320-Neo ready, and it would have Boeing taken years to counter. Until then, Airbus would have eaten the market.

So they attached the big diameter engine to the 737 that was originally designed for small diameter engines. Didn't fit under the wings though. So they moved it upwards and forwards, ruining the centre of gravity and aerodynamics, and tried to compensate the bad design hack via software.

The aircraft wouldn't have crashed if Boeing hadn't gone so far as to even botch up the software hack in every stupid way possible, but the whole thing would still have been an engineering hack.

@UnmutableToday how is it unprofessional when a bug causes production to go down at 2 in the morning and you need to fix it FAST? How is it unprofessional when your 90 day contract doesn't get renewed due to sudden funding shortfalls and you don't get time to fix your "quick patches"?

I never said I carelessly push crap code (I usually adhere to a standard) but sometimes getting a bug fixed is more important than being pristine.

@kshep92 Simple, first you create a hot Fix, after that you immediately (next morning) create a regular fix for the issue - it is that easy.

@kshep92 you are picking cherries, there are several hundred thousand company in the world producing code for relatively mundane companies who need custom software or who develop their own products in-house.

You argument is also very faulty .If companies only move forward like you say, their software will grow unmaintainable and unextendable. This will raise the cost of producing new features by a lot and make it slow. You can pay a growth spurt with technical debt, but you need to control it for sustainable growth. Otherwise you will end up with stagnation and failing products.

@UnmutableToday And that is the point. Systems grow to unmaintainable level and we call it LEGACY code.

I've worked on a few projects that had to grow unreasonably fast and people didn't give a damn if that will cause issues in the future - the functionality had to be delivered NOW and as cheap as possible. You can tell them whatever you want - they still don't care and don't want to invest a single penny in automation, testing nor code refactor because "it works now, why change it?". And oh boy, you dare to spend 30 minutes refactoring... They had a developer from Asia that was hired to check commits that only what is required was added. If something else was changed - they refuse to pay for that.

And that is not very uncommon as people are used to having everything now and developing code seems like simple writing, not actual work. Unless you are working with IT people or giant companies - all of them understand that time is needed most of the time