I am starting to realise that there really is nothing more permanent than a temporary fix.

To be a good developer, you must thrive in chaos, and have an insatiable desire to turn it into order.

All user input, both work tasks and actual application input, is pure fucking chaos.

The only way to turn that input into anything usable, is to interpret, structure and categorize it, to describe the rules for transformation as adequately as you can.

Sometimes companies create semi-helpful roles to assist you with this process. Often, these people are so unaware of the delicacy of the existing chaos, that any decision they make just ripples out in waves leaving nearly irreparable confusion and destruction in its path.

So applications themselves also slowly wear down into chaos under pressure of chaotic steak-holders which never seem to be able to choose between peppercorn or bernaise sauce for their steaks.

Features are added, data is migrated between formats, rules become unclear. Is ketchup even fucking valid, as a steak sauce?

The only way to preserve an application long term, is refactoring chaos into order.

But... the ocean of chaos will never end.

You must learn to swim in it.

All you can hope to do is create little pools of clarity where new creative ideas can freely spawn.

Ideas which will no doubt end up polluting their own environment, but that's a problem for tomorrow.

So you must learn to deal with the infinite stream of perplexed reactions from those who can't attach screenshots to issue reports.

You must deflect dragging conversations from those who never quite manage to translate gut feeling into rational sentences.

You must learn to deal with the fact that in reality there are no true microservice backends. There are no clean React frontends. There are no normalized databases. Full test coverage, well-executed retrospectives, finished sprints -- they are all as real as spherical cows in a vacuum.

There is no such thing as clean code.

There is only "relatively cleaner code", and even then there are arguments as to why it would be "subjectively relatively cleaner code".

Every repository, every product, every team and every company is an amalgamation of half-implemented ideals, well-intended tug of war games, and brilliantly shattered dreams.

You will encounter fragmented shards of perfect APIs, miles of tangled barbed documentation, beheaded validator classes, bloody mangled corpses of analytical dashboards, crumbled concrete databases.

You must be able to breathe in those thick toxic clouds of rotting technical and procedural debt, look at your reflection in the locker room mirror while you struggle yourself into a hazmat suit, and think:

"Fuck yes, I was born for this job".

Manager: Oh my god have you heard of libraries? I don’t even need to hire developers anymore, everything can just be done with code other people have already built for free

Dev: Well you actually cause a bit of technical debt when you use an abstrac—

Manager: EVERY TICKET SHOULD BE DONE USING LIBRARIES GOING FORWARD.

Dev: …This is going to implode…Can we at least fund some of the libraries we end up using?

Manager: WHAT? NO! Open source developers are suckers, what idiot puts code on the internet for free?? I shouldn’t be required to fund their stupidity. Let’s just take their stuff and make money with it.

Dev: *Phone rings 100th time today from recruiter*. One sec I have to take this call……It’s urgent.

The company I work for...
Has:

1. No CI/CD
2. SVN instead of GIT
3. Outsourcing to India (oof)
4. No Automated Testing
5. Uses Bugnet (ancient, outdated)
6. No clearly defined code standards
7. No real documentation on the code
8. Rubbish code
9. No desire to reduce technical debt
10. Poorly maintained DB
11. Poor outdated equipment
12. A useless PM
13. Still priotizes IE support (??)

On a scale of 1 to 10 how fucked is this company and anything they develop?

In the cave of technical debt...

A seasoned colleague just wrote this and I think it was very valuable:

On tech debt:

So the big challenge with technical debt is making non-technical management (CEO, COO, CFO, directors) understand what it means, and just how it operates. Sometimes it actually makes good sense to incur technical debt to get to market sooner, just as it sometimes makes sense to borrow money to get cash now and repay that loan later with (hopefully) resulting greater revenues from that investment. But just like a loan, tech debt always has to be paid some day. The longer the tech debt goes, the more expensive it gets. And also like a loan, the cost compounds, like compound interest on a loan. Tech debt should always be chosen with a clear plan to pay it off at some point in the not too distant future. The longer one waits to pay it, the more expensive it gets.

Just coded for ~14h straight. Started doing some super heavy code cleanup and refactoring. Almost cried when I saw my code from the past.

Maybe it's time to call it a day...

I'm specialized in creating technical debt.

Basically, I rant my way in any dev specialty.
Since I never have a solid understanding of what I'm fucking with, ranting is more natural.

Ability to create technical debt is one of the most important skill, often underestimated:
- it will lead to heavy refactoring or even rewrite = more job for dev
- it will save a lot of short term effort, and luckily will produce the mid-term lock-in of the developers (more money for dev)
- it will increase billable hours to the customer. Higher the technical debt, more complex the explanation, and easier to confuse the customer.
- the best thing is that you'll never pay the debt. You'll eventually leave - willing or not - the job and you'll find some green field to exploit and create more debt.

As a full-stack dev who has been looking for a full-time role for over half a year now... How the fuck can it be so difficult to land a job as a dev? I'm a passionate, capable, and proven dev; it shouldn't be this hard.

And why the hell are coding/whiteboard interviews the de-facto standard for deciding if somebody is worthy of a role? Whiteboard interviews are as inadequate and unencompassing a means of determining the quality of a candidate as asking a dentist how well they know the organ structure of the human body.

I've applied to an endless number of positions, so far-reaching and desperate as to even apply to international positions and designer roles instead of developer roles (I've been a graphic designer for over 13+ years). Even with this, most don't get back to you, and the few who do most often just notify you of your rejection. On the rare occasion I land an interview, my chances get fucked up by the absurd questions they ask, as if the things they are asking about are at all an appropriate, all-encompassing measure of what I know.

Aren't employers aware that competent devs are able to learn new things and technical nuances nearly instantaneously given documentation or an internet connection? Obviously, I keep learning and getting better after every interview, though it barely helps, when each interviewer asks an entirely new, arbitrary set of questions or problems....

Honestly, fuck the current state of the system for coding job interviews. I'm just about ready to give up. Why the hell did I put myself through 5 years of NYU for a Computer Engineering degree and nearly $100K in student loan debt, if it doesn't help me land a job?

"I strive for code quality and maintainability. I actually do. And i will not work for a company that does not care about it and just wants something done as fast as possible.
The only time i will do something quick and dirty is if it's actually urgent. And even then with one condition - my next task will be to fix it properly.

I do not care about your deadlines. I will do my best to meet them, but not at the expense of code quality. I've seen too many projects fall into technical debt, where productivity is so low, that the only way to move forward is hire more people and start working on a project 2.0

And please do not lie about how great your company is, if it's not. These kind of things surface very soon, and you will have wasted both of our time, because as i said - i will not work for a company that does not care about code quality."

you think i'll ever get a job again if i put this on my CV ? :D

Team quarterly capacity planning:

- Confluence document created with a big table (+100 rows) by product / business. Each row is something that needs to be worked on for the coming quarter.

- Row 1 could be an Epic with 15 tickets attached. Row 2 could be adding a single log to our analytics. No consistency.

- For each row, we create a separate confluence document with the "technical details". 75% of the time these remain blank. 1% of the time there is something useful, the rest its a slightly longer version of the description from the bigger document.

- Each row gets a high level estimate by the leads. 50% of the time without sufficient background info to actually do get it accurate.

- These are then copied into the teams excel spreadsheet, where it will calculate if we are over/under capacity.

- We will go backwards and forwards between confluence and excel until we are "close enough" to under capacity without being too much.

- Once done, we then need to copy them into the org/division's excel spreadsheet. This document is huge, has every team on it and massive 50pt text saying "Do not put a filter on this document".

- Jira tickets + Epics will now be created for each one, with all the data be copied over by hand, bit by bit, by product. Often missing something.

- Last week, at the end of this process for Q2 (2 weeks late), 6 of the leads were asked to attend a 30 minute meeting to discuss how to group the line items together because we had too many for the bigger excel spreadsheet.

- This morning I was told business weren't happy with one of our decisions to delay one line item. Although they were all top priority (P0), one of them was actually higher than that again (P-1?) and we need to work it back in.

... so back to step 1

- Mid way through Q2, a new document will be created for Q3. Work items that didn't make the cut will be manually copied from one to the other. 50/50 whether anything that didn't get done on time in Q2 will make its way to the Q3 doc.

- "Tech excellence" / "Tech debt" items (unit/UI tests, documentation, logging, performance, stability etc) will never be copied over. Because product doesn't understand them and assumes therefore that they are unimportant.

==================

PS: I'd like to say this was a rare event for Q2, but no. Q4 and Q1 were so bad, we were made assurances from the director of engineering that he would fix this process for Q2. This is the new and improved process (I shit you not) that has resulted in nothing tangible.

When your team has no time to address technical debt/infrastructure improvements but we need to make that square checkbox round immediately.

My brain is melting.

6 hours straight of just Refactoring without a break.

Technical debt is real, it is a bitch, and so are clients to expect to 'see' changes every week.

Boss tells me we need to balance doing work on things the client can play with and the backend code that does it all... 😧ok....

'TODO: remove sample return and connect to backen' As far as the eye can see.

No, I do not wish to work on your Scrum-managed project.

I do not wish to contribute to the Taylorism of my profession.

I do not wish to be an interchangeable cog in your software sausage machine.

I do not wish to be tracked by some pointless metrics like a call-centre worker.

I do not wish to bust my tight, cute ass to sprint after some idiotic management request that could have been factored in earlier.

I do not wish to obtain some piss-ant qualification that "authorises" me to do my job.

I do not wish to be party to your lie that technical debt will be avoided by refactoring---whatever the cost.

I do not wish to contribute to the death of software engineering to have it replaced by software development.

Agile? Sure. I can pick up the phone and talk to the client, users and fellow devs. After all, that's what it FUCKING MEANS. Communi-fucking-cation.

See that burndown chart? See your anus? Know what's happening next?

Fuck Scrum and every fucking bottom-feeder that is scamming a living by promoting it. You're killing this business.

Hugs and kisses,

Platypus

Just need to get this off my chest. Started a new job 3 weeks ago at a company that has been around ~18 years, it is only recently that they have started to grow more rapidly. I was brought in under the guise that they wanted to embrace change and better practices and so said I was up for the challenge.

In my 2nd week I was asked to produce a document on tackling the technical debt and an approach to software development in the future for 3 consultants who were coming in to review the development practices of the company on behalf of the private equity firm who has taken a major stake in the company. I wrote the document trying to be factual about the current state and where I wanted to go, key points being:

Currently a tightly coupled monolith with little separation of concerns (73 projects in one solution but you have to build two other solutions to get it to build because there are direct references.).

Little to no adherence to SOLID principles.

No automated testing whatsoever.

Libraries all directly referenced using the file system rather than Nuget.

I set out a plan which said we needed to introduce TDD, breaking dependencies, splitting libraries into separate projects with nuget packages. Start adhering to SOLID principles, looking at breaking the project down into smaller services using the strangler pattern etc. After submitting what I had written to be part of a larger document I was told that it had been tweaked as they felt it was too negative. I asked to see the master document and it turns out they had completely excluded it.

I’ve had open and frank discussions with the dev team who to me have espoused that previously they have tried to do better, tackle technical debt etc but have struggled to get management to allow them. All in all a fairly poor culture. They seem almost resigned to their fate.

In my first 2 weeks I was told to get myself acquainted and to settle myself in. I started looking at the code and was quite shocked at how poorly written a lot of it was and in discussions with my manager have been critical of the code base and quite passionate and opinionated about the changes I want to see.

Then on Friday, the end of my third week, I was invited to a meeting for a catch up. The first thing I was told was that they felt I was being too openly critical in the office and whether I was a good fit for the company, essentially a stay or go ultimatum. I’ve asked for the weekend to think about it.

I’ve been a little rocked by it being so quickly asked if I was a good fit for the company and it got my back up. I told them that I was a good fit but for me to stay I want to see a commitment to changes, they told me that they had commitments to deliver new features and that we might be able to do it at some point in the future but for now I just needed to crack on.

Ordinarily I would just walk but I’ve recently started the process to adopt kids and changing jobs right now would blow that out the water. At the same time I’m passionate about what I do and having a high standards, I’m not going to be silenced for being critical but maybe I will try and tackle it in a different way. I think my biggest issue is that my boss who was previously a Senior Developer (my current position) has worked at the company for 12 years and it is his only job, so when I’m being critical it’s most likely criticising code he wrote. I find it hard to have the respect of a boss who I had to teach what a unit test was and how to write one. It makes it hard to preach good standards when by all accounts they don’t see the problems.

Just wondering if anyone has suggestions or experience that might help me tackle this situation?

Would it sound bad if I said I leave because of technical debt to recruiter or my company?

WHY WRITE GOOD CODE WHEN YOU CAN HAVE TECHNICAL DEBT?

I think I want to quit my first applicantion developer job 6 months in because of just how bad the code and deployment and.. Just everything, is.

I'm a C#/.net developer. Currently I'm working on some asp.net and sql stuff for this company.

We have no code standards. Our project manager is somewhere between useless and determinental. Our clients are unreasonable (its the government, so im a bit stifled on what I can say.) and expect absurd things from us. We have 0 automated tests and before I arrived all our infrastructure wasn't correct to our documentation... And we barely had any documentation to begin with.

The code is another horror story. It's out sourced C# asp.net, js and SQL code.. And to very bad programmers in India, no offense to the good ones, I know you exist. Its all spagheti. And half of it isn't spelled correctly.

We have a single, massive constant class that probably has over 2000 constants, I don't care to count. Our SQL projects are a mess with tons of quick fix scripts to run pre and post publishing. Our folder structure makes no sense (We have root/js and root/js1 to make you cringe.) our javascript is majoritly on the asp.net pages themselves inline, so we don't even have minification most of the time.

It's... God awful. The result of a billion and one quick fixes that nobody documented. The configuration alone has to have the same value put multiple times. And now our senior developer is getting the outsourced department to work on moving every SINGLE NORMAL STRING INTO THE DATABASE. That's right. Rather then putting them into some local resource file or anything sane, our website will now be drawing every single standard string from the database. Our SENIOR DEVELOPER thinks this is a good idea. I don't need to go into detail about how slow this is. Want to do it on boot? Fine. But they do it every time the page loads. It's absurd.

Our sql database design is an absolute atrocity. You have to join several tables together just to get anything done. Half of our SP's are failing all the time because nobody really understands the design. Its gloriously awful its like.. The epitome of failed database designs.

But rather then taking a step back and dealing with all the issues, we keep adding new features and other ones get left in the dust. Hell, we don't even have complete browser support yet. There were things on the website that were still running SILVERLIGHT. In 2019. I don't even know how to feel about it.

I brought up our insane technical debt to our PM who told me that we don't have time to worry about things like technical debt. They also wouldn't spend the time to teach me anything, saying they would rather outsource everything then take the time to teach me. So i did. I learned a huge chunk of it myself.

But calling this a developer job was a sick, twisted joke. All our lives revolve around bugnet. Our work is our BN's. So every issue the client emails about becomes BN's. I haven't developed anything. All I've done is clean up others mess.

Except for the one time they did have me develop something. And I did it right and took my time. And then they told me it took too long, forced me to release before it was ready, even though I had never worked on what I was doing before. And it worked. I did it.

They then told me it likely wouldn't even be used anyway. I wasn't very happy at all.

I then discovered quickly the horrors of wanting to make changes on production. In order to make changes to it, we have to... Get this

Write a huge document explaining why. Not to our management. To the customer. The customer wants us to 'request' to fix our application.

I feel like I am literally against a wall. A huge massive wall. I can't get constent from my PM to fix the shitty code they have as a result of outsourcing. I can't make changes without the customer asking why I would work on something that doesn't add something new for them. And I can't ask for any sort of help, and half of the people I have to ask help from don't even speak english very well so it makes it double hard to understand anything.

But what can I do? If I leave my job it leaves a lasting stain on my record that I am unsure if I can shake off.

... Well, thats my tl;dr rant. Im a junior, so maybe idk what the hell im talking about.

I suddenly realized all the technical debt shit I told my boss would happen years ago given the way things were done/heading then... Just occurred pretty much all at once last week in the form of critical production issues...

The teams like:
-we need real time server process monitoring
-structured logging for apps
-containerization so one app didn't affect others

Me thinking: yes.... I told you so like 3/4 years ago when I first joined the team and kept repeating so much I got tired of saying at every annual review...

This is exactly what happens when you let technical debt grow and have no free time for developers to look into and fix then while they were small and not critical production processes... Or properly document and peer review them... (Got a shit pile of projects that no one knows how to use or even exists because the devs left the team) and they'll have a lot more when I finally leave... Hopefully this year.... If I can find another role and not need another medical procedure... (Doubtful)

Marketing pushed deadline for release one week earlier. That sucks.

What sucks even more is that frontend was not ready, but our frontend guy promised to take a look over the weekend and finish it. Thats cool we might make.

What sucks is that he fixed one small issue on Sunday 9PM and left the whole thing unusable.

So guess who was googling till 4am how to do stuff in bloody javascript?

In the end, I beleive I did a decent job and we ca release some kind of alpha and get rid of my dirty hacks later. That's how you get technical debt.

Now lets see what my boss thinks about it and if we are really going to release it or if I'm going to kill somebody.

Amazing how people misuse the term technical debt.

A bug is a flaw in your design/development.

Tech debt is a conscious decision/tradeoff, which is often tracked and removed as the product matures.

The difference is subtle. Avoid this mix up at least in written communication.

SQL injection holes everywhere... The original author of the product put concatenated SQL queries throughout the whole application. If it's not the client asked for a penetration test, we as developers wouldn't even be given chance to fix this shit.

I'm actually glad to have the chance. I can't live seeing them every day but force myself to ignore them.

Anyone else work in a codebase that is so deeply convoluted, that the only way to make new features work is to write new code in a similarly convoluted way?

Everyone wants to refactor our system, but we're a small shop with an insane amount of technical debt, so it likely won't happen for a long time. Any suggestions in the meantime? I feel like I'm spending more time figuring out how to make something work in our system then learning actual good practices.

If I hear anyone utter the words "technical debt" one more time, I swear to God, I will fucking kill them :-/

It's your fault your design smells like piss in the first place. It's your responsibility to fucking fix it. You can't just sit on your arse all day, coming up with new, "innovative" ideas that will build up more technical debt :-/ it's making the life of everyone around you, a big, irreparable mess.

I wish to create a guild for software developers. Like in the old age, where certain masterwork developers work together in order to provide non-hacky solutions. The beauty of a guild is that it would allow proper apprenticeship, Blacklisting of toxic companies and directly help with wage negotiations. Too often I see proper professionals working overtime just because they are harassed and having "impostor syndrome" (I know the term is hated, but passes the idea much better). Also maybe that would eliminate technical debt...
But hey, this is just a vision... :')

That feeling when the business wants you to allow massive chunks of data to simply be missing or not required for "grandfathered" accounts, but required for all new accounts.

Our company handles tens of thousands of accounts and at some point in the past during a major upgrade, it was decided that everyone prior to the upgrade just didn't need to fill in the new data.

Now we are doing another major upgrade that is somewhat near completion and we are only just now being told that we have to magically allow a large set of our accounts to NOT require all of this new required data. The circumstances are clear as mud. If the user changes something in their grandfathered account or adds something new, from that point on that piece of data is now required.
But everything else that isn't changed or added can still be blank...
But every new account has to have all the data required...

WHY?!

Joined a new company....the code is a fucking mess..so much technical debt......

My story about ego boost was when client came one day that they want some system that was prommised to him but guy who promissed him it forgotten about it.

Well, i quickly estimated things in head (i wasnt on meeting, was next to this room so i heared whats up), i pulled out my boss from meeting ("hey i need you urgently for sth") told him that i can make proof of concept to show him for next day (it was +-15) and sure enough, next day 10:00 first version that worked but was kindda rough around edges and with TON of technical debt was created. Than I told client that I just need a little bit more time to work on this as he can see it is here, it works, and it does what he needs, but it would be good to add some polish to it.

He bought my version and i saved company a client, that was lost becose some moron forgotten about him hah

Oh, yes, i got all i needed in return, day off and some extra $$

Every sprint, the beast grows.
Every sprint, we'll sort it "later".
Every sprint, we suffer more.

We warned them, but they did not listen. The technical debt rapture has begun.

Coming up to (very) tight deadline..

Manager - "Stick in a temporary fix, if the data is mocked out it will do for the demo. We really want to show this feature."
Me - "Okay, I"ll pick up the technical debt after the demo."

*Changes are coded and rolled out*

Manager calls me over to his desk..

Manager - "This feature isn't bringing back real data."

Do these kind of people exist in all companies?

Our company maneuvered themselves into a classic technical debt situation with a project of a second team of devs.

They then left, signing a maintenance contract and now barely work on the project for exorbitant amounts of money.

Of course management got the idea to hand off the project to the first team, i.e. our team, even though we are not experts in that field and not familiar with the tech stack.

So after some time they have asked for estimates on when we think we are able to implement new features for the project and whom we need to hire to do so. They estimates returned are in the magnitude of years, even with specialists and reality is currently hitting management hard.

Code is undocumented, there are several databases, several frontends and (sometimes) interfaces between these which are all heavily woven into one another. A build is impossible, because only the previous devs had a working setup on their machines, as over time packages were not updated and they just added local changes to keep going. A lot of shit does not conform to any practices, it's just, "ohh yeah, you have to go into that file and delete that line and then in that other file change that hardcoded credential". A core platform is end of life and can be broken completely by one of the many frameworks it uses. In short, all knowledge is stowed away in the head of those devs and the codebase is a technical-debt-ridden pile of garbage.

Frankly I am not even sure whom I am more mad at. Management has fucked up hard. They let people go until "they reached a critical mass" of crucial employees. Only they were at critical mass when they started making the jobs for team 2 unappealing and did not realize that - because how could they, they are not qualified to judge who is crucial.

However the dev team behaved also like shitbags. They managed the whole project for years now and they a) actively excluded other devs from their project even though it was required by management, b) left the codebase in a catastrophic state and mentioned, "well we were always stuffed with work, there was no time for maintenance and documentation".

Hey assholes. You were the managers on that project. Upper management has no qualification to understand technical debt. They kept asking for features and you kept saying yes and hastily slapped them into the codebase, instead of giving proper time estimates which account for code quality, tests, reviews and documentation.

In the end team #2 was treated badly, so I kinda get their side. But up until the management change, which is relatively recent, they had a fantastic management who absolutely had let them take the time to account for quality when delivering features - and yet the code base looks like a river of diarrhea.

Frankly, fuck those guys.

Our management and our PM remain great and the team is amazing. A couple of days a week we are now looking at this horrible mess of a codebase and try to decide of whom to hire in order to help make it any less broken. At least it seems management accepted this reality, because they now have hired personnel qualified to understand technical details and because we did a technical analysis to provide those details.

Let's see how this whole thing goes.

It was an intern job for 2.5$ /h. I removed a bunch of technical debt, made their modx site localized (with a weird approach though but hey, I was an intern) and wrote a few new pages. I loved every minute of working there until the end, but had it lasted a bit longer than a month I'd have probably burned the place to the ground when I realized that my friends had earned twice as much at McDonalds and I could've earned about the same amount writing one excel macro a day.

My family (dad, mom and I) runs a software business. Things were going decent when I was in college, and just as I was about to finish college, it went slightly bad due to lack of some technical insight. So I figured, I had the knowledge to do so, and joined in the family business as my first job. When I joined, I found out that things were worse that what I expected, (lack of processes in the company to handle day to day business). But we took a year to fix it and solve issues. But during this year, while the company finally runs as a proper company, we went into some serious debt to keep it running, as we were expecting it to get resolved soon. But now, although the company is structurally fine, the sales have seriously dropped. This has us cornered and we aren't able to do anything. We are seriously considering shutting the company down.

Which is not the worst part. The worst part is the debt. Since I, was a part of the company too, I am equally responsible for paying it off. And now, due to both my parents hitting the retirement age, I will be the only one repaying it. I really don't want to invest an estimated 8-10 years of my life living very modestly and spending a large (70-80%) of my income in repaying this.

I don't even know what to do, and things just seem very hopeless for me. Looking for any advice anyone has.

I guess if I had a bit more experience in the real world, I would be better at dealing with this, but I'm literally just 1 year out of my college.

Our technical debt has technical debt. There's no way we're fixing this tire fire 😔

There was a sales manager who was raked with overseeing me and another dev finish a last minute request project. He said at one point to the other dev that he was mad at developers because we understood something that he would never understand.

This same manager would often sit in on estimation meetings and constantly say that we were estimating too high and needed to come up with faster solutions. When we would offer him with caveats of possible technical debt or unintended side-effects/performance issues, he'd want us to go with that solution. He would then complain that we were always wanting to work on technical debt and that our application was slow. He would also ask for very high level estimates for large, unscoped features/apps without any meaningful level of detail, then hold us to the high-level estimated date even after revealing additional features previously unmentioned.

We learned to never compromise on the right solution and to push back hard on dates without proper scoping. They didn't learn, so I and most of the good devs left.

designing a SOAP backend in 2020....

i hate it, its wrong.
i hate it, because mounting technical debt ties a system to the past.
i also hate it, because i dont want to shit around with jurassic things. or short:

i hate everything about the fact that i am sitting here, designing a SOAP backend, in the year 2020

When I realized my job isn't to code, it is to hack for hacks.

As smart developers our job is to be accountable to non-technical product management types who care nothing for elegant system design or DRY code. They expect features get done fast and "technically complete." They use terms like "minimum viable product (MVP)" to imply we'll go back and improve things like refactoring and tech debt later.

They will not. Most likely they won't even be around. Producers and scrumlords have the highest turnover rate of any role on a team. By design they get bored or frustrated easily and are constantly looking for greener pastures. Many people in self-proclaimed "non-technical" roles like this never had the patience and attention span to learn a real vocation, and they've discovered a career path that doesn't require one.

These are our masters. As developers, we will answer to them forever and always.

Does anyone get the feeling that as they become more senior, they care less about meeting "best practices" and more of just "good enough"?

Best practices being everything in those books about TDD, unit testing, design patterns, design artifacts.

Good enough: enough so it won't blow up in prod, some tests but not 80-90%, some docs. Basically not like those public docs, open source projects/frameworks where function is covered

When I first started professionally, I was all about efficiency, good design, reducing technical debt, clean code.

But now, I look at problems and instinctively I may make these decisions but I don't really think about it much. First goal is to just get something working, clean it up later... Maybe.

In my short career, I've seen projects become legacy before their first release. Hell, I've seen proof-of-concept apps turn into technical debt because to management as long as it works we won't rewrite it.

My boss's SQL schema has no foreign keys and he said he left them out intentionally because they should be handled in the application layer and they're a large performance impact.

This is a fresh greenfield project and he's already pre-optimizing for problems we don't have yet, on things that may or not be bottlenecks using ideas (e.g. foreign keys have huge performance costs on mariadb/auora) with no hard data or facts to back them up.

Let's start a new project with some technical debt!

I have a lead developer who is obsessed with over-engineering everything to the point where we are adding features that he thinks the clients will ask for, but 50% of the time they don’t want it and we just end up maintaining useless code. To top it off, he doesn’t touch the code anymore and is a glorified business analyst, plus he’s slated to retire soon but keeps pushing the date back a year at a time. Just move on with it! I want to be spending my time on cleaning up technical debt, not making more.

Writing clean code.
Writing useful comments.
Commit before experimenting.

Just anything to prevent Technical Debt. Just because it works doesn't mean it should be kept as is. Later down the line you'll need to add a new feature and you'll spend 2x more time fixing the things you took for granted.

In a tiny galaxy far, far away there is the huge company XL and the tiny XS where I work, competing and sometimes cooperating. Both use the same horrible customer administration software called Y which is a windows-oracle mess but has a huge amount of complex domain specific business logic built in. So it can't really be replaced, just worked around.
XL have their work arounds, I am sure. We have ours but it's old and have needed to be replaced for years, let's call it The Problem. I am the guy who is supposed to keep it working while we wait for the right moment to build a new one. I always get called in to deal with The Problem at the last moment. It's only needed a few times a year. It's never a priority except at these times and then well, there is time only for the quick fix.
Now The Problem was once a good solution, actually pretty well built. You can still see some nice touches. It talks to the shitty API provided by Y and makes the most of it. But The Prob is written in a language-framework combination we no longer use for new projects. So a major update does not get favoured, especially since the guy who wrote it left a few years ago. And a total rewrite is a big project.
So The Problem lingers in use.
The stake holder mostly cares about how it looks, talking about technical debt to them just makes their eyes glaze over.
A couple of outings ago the stake holder boss wanted the web user interface of The Problem to look the same as the one used by XL because we ran a cooperative campaign. I managed to make them look very similar. Got some praise for that even.
Since then Y:s API has been updated with some big breaking changes. API calls that The Problem depends on have been heavily modified, even completely removed. With some really crazy hacks I still managed to make it work, just one more time.
Of course I again complained a bit. I loved the response:

- XL:s solution looks almost exactly the same so I'm sure they run what we are running. Why do we have so much trouble with Y when they don't?

Nooooo! It looks the same but... I just don't know what to say. But I do know the joke is on me.

How bad it feels when it work in a place where Agile and DevOps are mostly abused buzzwords.

Forced doing "scrum" with:
- half of the team providing endless daily reports instead of focusing on the 3 questions
- a scrum master that is barely reachable
- a product owner that would not even make a decision
- a sponsor that pushes us to go faster regardless of current technical debt (it's important to look good to other sponsors!)
- doing all possible scrum ceremonies with no value added
- not even estimating stories
- not even having accurate description in stories. Most of the time not even a description.
- half of the team not understanding agile and DevOps at all

Feels so good (not). Am I the one in that boat?? ⁉️

What's the point of doing scrum if implemented that badly?? 😠

Me: Why are we spending time building reports for Support? AFAIK they never read or use them.

Boss: Seems they expect you to do it.

Me: Then what exactly are they supposed to be doing? All the issues seem to just escalate back to us.... We should just make sure issues never get into PROD

Boss: I agree, they're always firefighting... we gave them more funding so eventually they should catch up **Me: I highly doubt it, you should just stop hiring monkeys** esp. if we prevent PROD issues.

Me: Yea... we should prevent production issues because someone always has to pay off the (technical) debt and interest rates in PROD are very high

Our code base is shit.
To improve, we went through different coaching style: Freudian Psychoanalysis, behavioural psychology, gestalt

- Freudian Psychoanalysis: After several years refactoring and discussing our technical debt we can say that we really understand our code in deep. But it's still shit

- Behavioural psychology: after some months of work, we built a lot of testing. Now the code is still shit, but we don't get dirty anymore

- Gestalt: after few weeks sessions, the code is still shit. But we don't care anymore, we accept it and we are happy

(note. it's an adapted psychology joke)

So I am finally plunging into continuous integration. If I make one more deploy script mistake, I've lost enough time to merit having learned a better solution than bash scripting calling git and rhc and py files I wrote. I have failing tests that are failing because they weren't updated after the million and a half urgent changes in the past 2 months, so it's time to act like I am a TDD fanatic and write the tests correctly. So much work. All from me listening to the constant req changes, listening to the urgency, letting non-devs get under my skin if you will. I'm optimistic in all the wrong places - I think I can write that by end of day let's try it. I'm lazy in the wrong places - I think that I can write that test later, because all I changed was XYZ (which took all night but I said I'd get it as close as possible didn't I?). And I think these handful of bash scripts are good enough to make sure I run tests? But remember, I didn't write the tests or I didn't go back and update them. Or the tests that fail, I'm too lazy. And so much of the tests, I would need to use, idk selenium for, and damnit if I really don't want to dig for element IDs to wait for every time I need an AJAX call.

Okay wow, I really did rant here. And discredited myself a bit lol I need to ignore the wrong lazy and embrace the right lazy. Protect myself from myself and from contributors. It really is, up to me now, to rescue myself from my bad habits. Bad habits perpetuated by clients urgency every day, to change things, that should have been finalized in November if we wanted a stable flipping system in January. It feels like the blind (client) leading the blind (me, when I do dumb shit like rush features out the door half tested).

Anyway all this came out, because I have been reading about continuous integration and stumbled upon this quote. And thought someone might laugh at the anachronism like I did

A refactor a day keeps the doctor away!

LPT: Avoid building any complex report/tool with Excel, because you will forever be fixing the damn thing!

I need some advice here... This will be a long one, please bear with me.

First, some background:
I'm a senior level developer working in a company that primarily doesn't produce software like most fast paced companies. Lots of legacy code, old processes, etc. It's very slow and bureaucratic to say the least, and much of the management and lead engineering talent subscribes to the very old school way of managing projects (commit up front, fixed budget, deliver or else...), but they let us use agile to run our team, so long as we meet our commitments (!!). We are also largely populated by people who aren't really software engineers but who do software work, so being one myself I'm actually a fish out of water... Our lead engineer is one of these people who doesn't understand software engineering and is very types when it comes to managing a project.

That being said, we have this project we've been working for a while and we've been churning on it for the better part of two years - with multiple changes in mediocre contribution to development along the way (mainly due to development talent being hard to secure from other projects). The application hasn't really been given the chance to have its core architecture developed to be really robust and elegant, in favor of "just making things work" in order to satisfy fake deliverables to give the customer.

This has led us to have to settle for a rickety architecture and sloppy technical debt that we can't take the time to properly fix because it doesn't (in the mind of the lead engineer - who isn't a software engineer mind you) deliver visible value. He's constantly changing his mind on what he wants to see working and functional, he zones out during sprint planning, tries to work stories not on the sprint backlog on the side, and doesn't let our product owner do her job. He's holding us to commitments we made in January and he's not listening when the team says we don't think we can deliver on what's left by the end of the year. He thinks it's reasonable to expect us to deliver and he's brushing us off.

We have a functional product now, but it's not very useful yet and still has some usability issues. It's still missing features, which we're being put under pressure to get implemented (even half-assed) by the end of the year.

TL;DR
Should I stand up for what I know is the right way to write software and push for something more stable sometime next year or settle for a "patch job" that we *might* deliver that will most definitely be buggy and be harder to maintain going forward? I feel like I'm fighting an uphill battle in trying to write good quality code in lieu of faster results and I just can't get behind settling for crap just because.

Me: we need to fix all these technical debt and prevent new ones from growing

Boss: this needs to be prioritized by product owner

Correct me if I'm wrong but a PO didn't see all the shit under the hood, (of a nice looking "car")... And by the time the engine starts choking... It's already too late?

I wish business people understood the importance of tackling technical debt

I don't understand how my managers suddenly forgot that my "down weeks" we're due to technical debt I inherited. The whole on boarding hasn't been in my favor. I've stayed at work everyday til long after work hours, digging through code, trying to get JIRA tickets done, encountering issues specific to our code base that no one would ever discover on their own without docs/help from the original dev. The whole time, I was told that they know what's going on and apologize. I constantly expressed that plenty of what we were doing was building on antipatterns. They acknowledged. When a ticket wasn't done, they always knew the very specific reason and I wasn't faulted. 6 months in, I receive a great annual review. 7 months in? I receive an email titled "Performance Discussion," detailing 4 of those incidents where a ticket was pushed back -- with inaccurate depictions of what actually went down. They actually wrote that I didn't communicate. One part of the report expressed that there were "bugs found in production due to inadequate test coverage." WTF!! Everything made it past code review and QA. What are you talking about?? In fact, the person who wrote that merged my code in each time!!!! Insane!! Anyway, Q2 is partly about cleaning up technical debt, which is a responsibility I have been vested (fantastic). I've deleted about 800 lines of code in the last 2 weeks and added plenty of doc strings. Two of the most important modules our application works from are about 1000 lines of JavaScript each without any comments/docs. I'm changing that, but I don't know if my managers truly know the significance. Someone was recently promoted to my position but manually wrote out a sorting algorithm (specified numeric indexes and all); didn't do shit to earn it but breathe. And while they get more and more praise and responsibility, I'm over here stuck trying to prove myself and live up to why I assume they hired me. It's ridiculous. I love the company, but I'm not getting any sleep and I'm stressed out. It's only been about 7 months and I've been doing everything I can. Why is this happening? What am I doing wrong? I've been developing a recurring (physical) headache and ticks. My heart/chest area sometimes feels like it's lifting weights. I sound like an idiot, pushing so hard for a company that isn't mine, but I take so much pride in being in this position, and I'm so set on proving myself this early in my career (I'm 25).

If you give the client a choice of:
- Quick and dirty solution which results in tech debt
- Better solution that would be cheaper in long run

They will always choose the first without fail..

I no longer work for a startup company. On Monday I’ll start work for a real company, one that values project managers and their infrastructure. As a DevOps engineer, I value the IT resources that power my old companies SaaS platform. My old position is not being back filled and they’re hiring a full time dev instead of and Ops engineer. They have chosen to proceed with zero employees who know Azure or the platform their own software runs on.

Word to the wise when choosing to work for a startup. Ask these questions:

- Do they have a dedicated product manager/owner , who isn’t also the CFO?

- Do they value infrastructure and their IT resources ?

- Do they have decent powered laptops to work with?

- Do they have too much technical debt because they’re always building new features ?

- Do they work 18 hour days because they set poor work/life boundaries ?

- Who handles Support tickets , and what’s a typical support issue like?

- Do they have a branching and merging strategy? Don’t accept “we’re too small” as an answer! It’s a trap that they don’t want one.

Did not expect when I joined this new startup that there would as much technical debt as there is

What time do you get up on work days? I'm starting to think I should have me time in morning (reading, learning, coding my own things) before going to work.

I've think I've come the the conclusion that this job/team is sorta chaotic and tedious and there's no skill growth. Not learning anything new. Usually just something broken, integrate some new feature, build something that I've already built before but differently for this specific case. Nothing fun or challenging, or new.

And also tired of trying to be a "role model", make things right. I tend to like to keep things orderly, documented, well tested and clean but everyone else seems to just bulldoze their way to get whatever they need, leaving a mess behind... It's been like 2yrs already but the technical debt seems to be growing not shrinking...

It's been a while DevRant!

Straight back into it with a rant that no doubt many of us have experienced.

I've been in my current job for a year and a half & accepted the role on lower pay than I normally would as it's in my home town, and jobs in development are scarce.

My background is in Full Stack Development & have a wealth of AWS experience, secure SaaS stacks etc.

My current role is a PHP Systems Developer, a step down from a senior role I was in, but a much bigger company, closer to home, with seemingly a lot more career progression.

My job role/descriptions states the following as desired:

PHP, T-SQL, MySQL, HTML, CSS, JavaScript, Jquery, XML

I am also well versed in various JS frameworks, PHP Frameworks, JAVA, C# as well as other things such as:

Xamarin, Unity3D, Vue, React, Ionic, S3, Cognito, ECS, EBS, EC2, RDS, DynamoDB etc etc.

A couple of months in, I took on all of the external web sites/apps, which historically sit with our Marketing department.

This was all over the place, and I brought it into some sort of control. The previous marketing developer hadn't left and AWS access key, so our GitLabs instance was buggered... that's one example of many many many that I had to work out and piece together, above and beyond my job role.

Done with a smile.

Did a handover to the new Marketing Dev, who still avoid certain work, meaning it gets put onto me. I have had a many a conversation with my line manager about how this is above and beyond what I was hired for and he agrees.

For the last 9 months, I have been working on a JAVA application with ML on the back end, completely separate from what the colleagues in my team do daily (tickets, reports, BI, MI etc.) and in a multi-threaded languages doing much more complicated work.

This is a prototype, been in development for 2 years before I go my hands on it. I needed to redo the entire UI, as well as add in soo many new features it was untrue (in 2 years there was no proper requirements gathering).

I was tasked initially with optimising the original code which utilised a single model & controller :o then after the first discussion with the product owner, it was clear they wanted a lot more features adding in, and that no requirement gathering had every been done effectively.

Throughout the last 9 month, arbitrary deadlines have been set, and I have pulled out all the stops, often doing work in my own time without compensation to meet deadlines set by our director (who is under the C-Suite, CEO, CTO etc.)

During this time, it became apparent that they want to take this product to market, and make it as a SaaS solution, so, given my experience, I was excited for this, and have developed quite a robust but high level view of the infrastructure we need, the Lambda / serverless functions/services we would want to set up, how we would use an API gateway and Cognito with custom claims etc etc etc.

Tomorrow, I go to London to speak with a major cloud company (one of the big ones) to discuss potential approaches & ways to stream the data we require etc.

I love this type of work, however, it is 100% so far above my current job role, and the current level (junior/mid level PHP dev at best) of pay we are given is no where near suitable for what I am doing, and have been doing for all this time, proven, consistent work.

Every conversation I have had with my line manager he tells me how I'm his best employee and how he doesn't want to lose me, and how I am worth the pay rise, (carrot dangling maybe?).

Generally I do believe him, as I too have lived in the culture of this company and there is ALOT of technical debt. Especially so with our Director who has no technical background at all.

Appraisal/review time comes around, I put in a request for a pay rise, along with market rates, lots of details, rates sources from multiple places.

As well that, I also had a job offer, and I rejected it despite it being on a lot more money for the same role as my job description (I rejected due to certain things that didn't sit well with me during the interview).

I used this in my review, and stated I had already rejected it as this is where I want to be, but wanted to use this offer as part of my research for market rates for the role I am employed to do, not the one I am doing.

My pay rise, which was only a small one really (5k, we bring in millions) to bring me in line with what is more suitable for my skills in the job I was employed to do alone.

This was rejected due to a period of sickness, despite, having made up ALL that time without compensation as mentioned.

I'm now unsure what to do, as this was rejected by my director, after my line manager agreed it, before it got to the COO etc.

Even though he sits behind me, sees all the work I put in, creates the arbitrary deadlines that I do work without compensation for, because I was sick, I'm not allowed a pay rise (doctors notes etc supplied).

What would you do in this situation?

rant="""
It's too many features for me to keep up with. And the client just bounces between this matrix of all the possible permutations of them, refusing to admit that he is asking for mutually exclusive behavior in more than one place. I have mentioned to him at least 12 times a year that there is too much going on, not organized, we need to simplify, prioritize, or we will have 100 half baked untested features.

Of course it is more or less made it out to be that this is all my fault, or at least it's hard not to feel that way when I say:

It will be a long time before X will be working, we need 25 other things first.;

Next day he asks:
Have you made any progress on X;

I reply: Now we need 24 things to be done at this rate it will be a month.;

He replies:
Ok but I need this yesterday. How about if you add a new feature Y that does everything X does without those 24 things?;

I reply: That will not work at all like X. Y is just X + 1 more feature.

He replies: Ok well I need Y so when you're done with X I need a way to do it like Y also. I just thought it'd be easier.

EASIER TO ADD MORE FUCKING FEATURES YEAH SURE THATS EASY AS FUCK YOU FUCK FUCK FUCK. He's a nice enough guy, pretty smart compared to my first few paying gigs, but wtf really? How do I come out and tell you I need 25 days and you ADD more work? This was one example.

IN TWO days he has added 12 features. And during the week has asked for 29 UI interfaces to be COMPLETELY different. This is becoming COMMONPLACE. Every week there is either a huge change, or a conversation like about that finds its way into the entire business flow inside an dout.

The worst thing is: I TOTALLY understand what he needs. I feel that HE doesn't. This weekend I spent literally HALF of his retainer on getting equipment into my hands to bring it back to find out it DOESNT WORK. Why aisn't HE doing this so I can finish the features from NOVEMBER that HE NEEDS in order to PROCESS SALES.

I've tried and tried but I just can't get through to this client what a tremendous waste of time his \"process\" is, for lack of a better word. Constant changes, contsant additions, lack of clarity, needless repetition and contradictions, constantly adding moonshot ideas to compete with every industry in the region, and not beta testing anything until something goes wrong.

Fuck this guy! His business is failing and I felt responsible for the longest time but it is clear to me that if I wanted to save his business I would have to ignore 95% of his feature requests. I ignore 50% now because of the stress in trying to determine which of the 3 different paradigms he is talking about changing. I will lose this client, and I feel like he will sue me to get all of his money back. He holds me to very little honestly - BUT WEEKLY reminds me that he won't be able to pay me next month if feature XY and Z arent ready!

If a developer is CLEARLY overwhelmed, it makes NO sense at all to continue to PILE ON feature after feature
"""
try:
while true:
rant+=", after feature"
except DevHeadExplodes as inevitable:
raise YourDevsRatesOrLookElsewhere(inevitable)

Time for a full refactor. Everyone can go home for three days while I unfuck every page and pattern.

Fuck stupid managers.

My current agency tried to create a bundle of generic Microservices with the hope of save time and money on future projects. That was two years ago (i was working here from 4 months ago).

What they have now? well, a sort of distributed monolyth were if one service goes down, everything else fails, infinite technical debt, no security policies (yeah, all the apis are open!!!) Business rules on the frontend . . .

And what the stupid manager say? "Everything must be ok because i designed it very well, i research a lot for this"

Stupid boomer.

PD: Yeah, despite the fact he is judt a manager, he take the responsibility to design the full architecture, idk why no one srops him.

Technical debt.... so much technical debt it’s driving me crazy!

It’s not only that there’s commented out lines in abundance, methods and whole classes not used anywhere anymore in a decade and code using not only deprecated standard library functions, but some that have been REMOVED in earlier versions of the language (have no idea how those have even stayed functional...), and documentation that has very little to do with the reality... but today, I submitted a pr to fix the documentation for setting up dev env - which was outdated already when I started a few years ago!

I know we are understaffed and busy, but c’mon - it doesn’t take much to leave the code in a better place than when found...

Recently installed SonarQube and its been amazing to see the level of code quality (or lack thereof)

Some projects have 30 to 60 days of technical debt and I found a few files with a cyclomatic complexity over 100. I’m still learning what the “good” numbers should be.

Yesterday, couple of devs were very proud they were going to start reducing the numbers, they started with one of my solutions that had 5 minutes of technical debt. Yes, 5 minutes.

DevA: “OMG…look at this…it has a cyclomatic complexity of 11…that’s terrible. I thought we were supposed to be professional developers.”
DevB: “And take a look at this, he used the double-slash instead of a triple slash for comments. How does any of code even compile?!”
Me: “Maybe we should tweak some of those SonarQube rules so they make more sense to our code base. We’re never going to use unicode, so all those string culture warnings should go away and code comment formatting? Who cares? Be happy we have comments. I think we should also focus on the bigger fish in that pond. The CRM project is one of the biggest and has a lot of improvement opportunities.”
DevB: “There you go again, don’t bring me problems, bring me solutions..ha ha”
DevA: “Yea, no kidding …hey…did you see the logger? OMG…the whole class is over 25 lines…we gotta split that up into smaller projects so it’s more manageable.”

It’s a good thing our revenue stream isn’t dependent on people getting work done.

*everyone bitching about a piece of software that everyone hates because it's awful, doesn't work, AND costs millions of dollars*
Me: Hey here's a solution that's basically free and gives us everything we need, and all of the enhancement requests
"Cool! We'll look into it for 2020. Keep working on it for a third of what you should be making though"
.. but we need it now??

Too much technical debt
Write more unit tests
Unit tests failing, the code will be right so change the tests to pass
Too many unit tests to maintain, they look a lot like technical debt
Remove unit tests to reduce maintenance overhead

Fuck my project manager. He wants to sacrifice code quality, test coverage and technical debt in favor of more features. In the future when everything takes longer or breaks guess who is responsible? Certainly not him.

Does anyone work on a team with multiple stacks?

For example we have batch jobs in Java but also have a JS front-end and APIs.

How do you divide the developers and the work across these projects?

Currently everyone does everything but I feel like this is inefficient and hard to develop expertise. And different people or even the same person will make the same mistakes over and over again because they don't know how to do X or they forget or overlook some quirk. When I switched Beck to JS took me like a week to get a Promises nailed down again. And this morning someone else had a production bug and couldn't figure it out. But when I looked at the code I could pretty much see where an issue could be (uncaught exception in a promise)

Also the testing frameworks are very different and there's a lot of infrastructure technical debt, things that really should've been done a long time or fixed but no one had the time or expertise to do it or notice it (until it causes a production issue and then everyone is like WTF is happening??!!!!).

I'm not the manager but I always feel that the team needs to be split along the language lines and specific people need to own these projects to review and code changes for all these common newbie errors. And also developer enough expertise to foresee problems before it becomes a production issue.

"God we've got an awful lot of technical debt, there's no process for anything here, no one knows how to use it, how it works or what even what it really does. Should we try to spend some time documenting and fixing that since this problem is going to keep cropping up again and again and the guy who wrote it left 2 years ago"

"Nah, the execs want features, fuck the fact that we are constantly struggling to meet deadlines due to being horrendously understaffed and everything takes 3 times as long as it should due our crippling technical debt. Lets keep hacking away with our old rusty saw instead of taking 10 mins to sharpen it"

I have a folder in my project called Technical Debt. As of now it has the same number of files as the rest of the project.

Boss: We need a discount coupons system right now

Me: We have lot of security concerns, if we implement that as the things are right now, that will be exploited by hackers to get infinite discounts

Boss: Dont worry, i will monitor everything personally for avoid problems

Me: :facepalm:

PD: I entered this software agency 4 months ago by necessity and everything was a mess, they pay 250 bucks to all their devs.

They have what they deserve, a shitty software that can be exploited everywhere

Pls give me another Job xD

PD2: I can sell you lot of exploits for this shitty platform they built JAJAJAJAJAJAJA okno

Demo Driven Development

Now let's hit some deadlines, add the tests later, and the technical debt will probably just be somebody else's problem.

Once upon a time i had a great idea.
Because i couldnt be bothered to do anything productive i created a simple app in the C# that would look into every .js file (from a game that uses it for the gui/main menu) and search for "//todo" lines.

I did it mostly for kicks. I got that idea when i encountered one //todo in a file when i was trying to mod that game.

Yes i know grep exists: fuck you.
It would have taken me more time to learn that than to write that 20 line program...

The result? Over 30 lines of //todo with some briliant pearls in the type of:
>Temp workaround because X
>Workaround for race condition
>Clean that up
>Obsolete

When i return home i will post real quotes. They might be amusing to read...

The game is based on a custom C++ engine. HTML, CSS and JS is used for main menu and some graphical interface in game.

The most amusing thing is that this inefficient sack of chicken shit is powering one of the biggest (no playerbase but unit, world, gameplay vise) rts that i have ever played.

But still in spite of a dead community, buggy gui as shit and other problems i love this game and a lot of other people love it too. It is a great game when it works correctly.

To the interested: JS portion uses jquerry and knockout lib.

I love working on legacy products. You just need a good shower and possibly a therapist after.

- Sensitive data sent over the internet encrypted with DES (not even 3DES). Guess it doesn't matter that the key (singular, for the last decade) is basically 0123456789ABCDEF.

- Client databases with open default port, admin/admin superuser.

- Critical applications (potential for substantial property damage, maybe loss of life) with a single point of failure and without backup.

Suggestions, to slow down a bit with sales, so we have time to rewrite this steaming pile of crap are met with the excuse: be more pragmatist, this is standard industry practice.

Some of this shit can be fixed on my own time if my conscience nags too much, but others would require significant investment of time from multiple developers, which would slow down new business.

Guess the pay is ok, so that's something...

A little background on project fubar:

Project fubar was started a couple of years ago, by an entirely different set of devs, against an entirely different set of requirements which were never made transparent to this day, on a new platform and framework.

That means it had APIs either outdated or deprecated, front-end logic that did things it wasn't supposed to be doing and lots of scope creep and technical debt.

I had to support and fix fubar for the last few months to prime it for UAT. It was the equivalent of plugging leaks which created more leaks.

Finally, I couldn't take it and asked for a week off. I timed it so it would be right after what would have been the final UAT deployment and I'd be back after they completed their test rounds, so I could fix any new or returning defects.

Today I just found out that fubar got put on hold, that UAT was a failure and all fubar-related work had to stop. I have some mixed feelings on this: I worked hard to get fubar working as business wanted, and I was proud of that. But I also didn't like that fubar was constantly changing in scope and function.

I wonder if anyone else has ever felt the same thing?

"Do it right do it light..do it wrong do it long"

My old peewee football coache's sage advice on the pitfalls of technical debt..

Debating on whether to quit my job.

Part of the reason it's hard for me to make a decision is there are a lot of good things about my job:

- almost all the projects we work on are blue sky; no technical debt anywhere
- great teammates; people help each other out and generally there's a good vibe
- reasonable boss; he's totally fine with me managing my own schedule, and since I get my work done, he basically never questions when and where I work
- about 1 hour of corporate meetings each week
- best healthcare I've ever had; basically everything is paid for
- 3 weeks PTO & all major US holidays
- free food; generally healthy office snacks and such

So why would I want to quit this environment?

- I hardly get to code anymore. About 2 years ago, I got asked if I would mind helping spec out projects. Since then, I've moved from writing code related to projects to helping my teammates understand the business situation so they can build the right thing.
- I'm in lots of meetings. So we have very few meetings for the company itself. We have a bunch of customer meetings, though. And progressively, I've getting pulled into meetings where there's really no reason for me to be there, aside from "we should have a technical person present."
- The sales people are getting tired of turning down clients that our product isn't targeted for. So they're progressively pushing to make products in those areas. Unfortunately, I'm the only one on the engineering team has any experience in that other tech stack. Also, the team really, really don't want to learn it because it's old tech that's on its way out.
- The PM group is continuously in shambles. Turnover there has averaged 100% annually for about 5 years. Honestly, IMO, it's because they're understaffed. However, there has been 0 real motion to fix this other than talk. This constant turnover has made it so that the engineering team has had to become the knowledge base for all clients.
- My manager has put me on the management track, but has been very slow to hand off anything. I'm the team supervisor, and I have been since the beginning of the year formally. When the supervisor quit last year, it basically became obvious to me that I was considered the informal supervisor after that. However, I can't hire or fire; I can't give a review; I don't have any budget; I can't authorize time off. So what do I do now? Oh, I'm the person that my boss comes to ask about my co-workers performance for the purpose of informing promotion/termination/pay increases. That's it. I'm a spy.

Giving a short talk on technical debt at our monthly meeting tomorrow. I hope it helps people in my organization understand why we need to take care of all the quick and dirty work we do. I'm tired of people saying how long updates take and the reason is because we cause the problems.

ColdFusion and all ColdFusion devs should be executed. Its a god-awful software from the 90's and if you still use it you're either braindead or ignorant.

Shut up about legacy CF code too! No one cares whether or not your embeddable calendar would be hard to make in JS; fucking figure it out.

I realise that CF may make things easier in the short run, but in the long run you'll have introduced so much technical debt that you'll run crying back to JS anyways; CF is so hard to refactor and even to make flexible that you would spend less total time over an application lifecycle learning JS.

Yesterday we released this huge refactoring/rewrite I did alone so it was my task to release and fix any upcoming problems. Not that I would have died to refactor a huge part of the codebase but technical debt was waiting to kill us on upcoming features.

Deployment is done by ssh'ing into prod and pulling from git. I'm happy I could convince them to track a dedicated release branch... Why would we want to build anything? What is automation?

Debian 8 with MySQL 5 community edition... Throws some internal error on my use of JSON functions. Thankfully I was allowed to switch prod to MariaDB but updating packages caused segfaults with the PHP MySQL connector. This is why you need NixOS!

Prod is a 4 core 4 GB VM that would take forever to run migrations. Also no disk space. Had to copy the whole db to staging (which is much more powerful and on Debian 9? diverging environments in the same data center...), migrate there and and pipe back mysqldump directly into ssh while in my neck I feel another client's project that I have about half a week left to finish.

It's Monday night. Customer has a full office of over 50 users at 8 AM.

Almost fell asleep in the car the next day, and I think I have RSI in my enter finger now.

Me: We have a lot of technical debt.

PM: And what is that?

Me: ...FML...

All day long meeting with business consultant about company future, software architecture, technical debt, refactoring, resources, projects.

Conclusion from top consultant, ex country manager of a weeeell known tech company:
Who cares about "code" anyway? (disgusted smile)

Fucking damn! This program is so poorly built that it's racking up terrible amounts of technical debt. This should be fucking easier than this, but because of how closely coupled everything is I'm now having to suffer through this ungodly beast of code.

I was aiming for a nice top down model where things communicated straight down, but with each additional feature requested by my PM, there are things that are growing increasingly more difficult to build around.

I could rebuild the entire thing, but this is the culmination of 8 months of work!

GOD KILL ME PLEASEEE

The more I investigate mobile development the more it becomes apparent to me that modern development is a *massive* pile of technical debt thats going to burst, crash, and burn one day, along with the entire industry.

If it takes a newbie more than ten minutes in your framework to add a fucking *button* and navigate to a new screen, then your framework is shit.

On a project that will crash and burn due to a badly projected date given to the business. I'm team lead and the Developement manager. I'm not sure how to save my career from this one. 22 years at this company and this may end my employment.

Can't change the date because the business has had it with deployment failures. Not enough time to do any of the technical debt and I'm not sure one if the issues has a solution.

Time to create a resume I guess. Been a really long time.

Let me know if you want a developer in Des Moines!

Join a team that understands technical debt and actively squashes it...

Yes I am having a bad day, or should I say month, because I have to work to pay down other people's debt...

So working for a company and the dev team I’m apart of works on a legacy rails app. Technical debt is high, no automated tests, no proper routing and also running unsupported versions of the language.

I joined seven months ago and got the current team doing automated testing so that’s a plus, they bought this app four years ago and there’s been no language updates, testing, cleanup, security updates, nothing, just adding to bad code.

Now we’re looking to actually upgrade language versions, the language and the framework now this will cause a lot of stuff to break naturally due to how outdated it is.

So I started putting proper routes into place how things should of been when things were being built as we have some spare time I decided to go out of my way to clear up some of the technical debt to get ahead of the curb. Re-done an entire section of the app, massive speed improvements, better views, controller, model, comment clean up and everything exactly how it should be.

I push the PR,
*other dev* - “why are we doing all of these other changes”
*me* - “well to implement routes properly, we have to use the new routes I just did some extra cleanup along the way”
*today, me* - “can you lend me a hand with one of the routes the ID isn’t getting passed”
*today, other dev* - “this wouldn’t of happened if you didn’t redo all these files, let’s just scrap the changes”
…

Sooo, I’ve spend three weeks improving one section in the app, because I’m having issues with one route according to this dev I should scrap it? Wait come again, am I the only one in this team who cares about making this app better all round?

Frustrating…

So, after having my mental breakdown with the 500k LoC Zend Frameshit PHFuck 5.5 with 0 test project, for a whole year; and after moving to a better job, I now inherited a React/Node/GraphQL project with a shitty architecture. It's so shit technical debt can almost be payed with actual cash... or flesh, ass-for-arch.

However, line test coverage is over 90%, so I guess it is an improvement.

Posted previously about our codebase being a monolithic, poorly-written, pain-to-maintain gigantic cluster-fuck. And the efforts made to rewrite it.
Well, we made huge success the previous year in this regard. I rewrote the entire API while my other team mates worked on two different UI apps one of which is now in production and the other soon to be released in alpha.
Processes have being put in place for our team and are being improved.
We still have some technical debts though.
Dev goal for 2020,
- Pay most of the technical debt.
- Dive deeper into Flutter and finish the app I wanted.
- Play with ML, AI and Game dev.

Adding "highly skilled in code divination and paying off bankrupcy-level technical debt" to my resume.

Thanks PHPepsi, you trained me good for this...

Company tool over a Magento shop from an internal solo developer. They made a new theme based on a bought theme, but the developer who started it is leaving. The 'developer' (yes, quoting it now) made a royal mess about it; rewriting core files, overwriting theme files, leaving JavaScript alerts all over the place, placing business logic in templates and defining CSS classes with functions in custom module block classes. I could go on for a while. After the first sprint we tried to convince the customer to do a complete rebuild, but we couldn't convince him...

The 'developer' has been hold on for now to give support on his crappy code and my next few months are filled with working in this mess without cleaning up the technical debt because we don't have enough time for that... FML

Technical debt is paid back in time and frustration

"I need help"

I joined this new service based company and they dumped this giant messed up jquery/php spaghetti project on me, with no comments or any technical documentation. It's completely unmaintainable.

It's been a couple days, and it has already started to take a toll on my health. I feel anxious, causing me nausea at times. I wanna quit, but no other developer is free to takeover in their company.

Am I a crying little bitch? I wanna man up to it, but it's shaking my peace of mind.

It's pile of garbage, and they want me continue working on it.

I know some of you would say, it's an opportunity to fix something. But they don't want changes or fixes. They want me to continue piling it up with more features, ultimately increasing the technical debt.

When Do You Stop Taking Responsibility?

Let me clarify by describing four scenarios in which you are tasked with some software development. It could be a large or small task. The fourth scenario is the one I'm interested in. The first three are just for contrast.

1. You either decide how to implement the requirements, or you're given directions or constraints you agree with. (If you hadn't been given those specific directions you probably would have done the same thing anyway.) **You feel accountable for the outcome**, such as whether it works correctly or is delivered on time. And, of course, the team feels collectively accountable. (We could call this the "happy path.")

2. You would prefer to do the work one way, but you're instructed to do it a different way, either by a manager, team lead, or team consensus. You disagree with the approach, but you're not a stubborn know-it-all. You understand that their way is valid, or you don't fully understand it but you trust that someone else does. You're probably going to learn something. **You feel accountable for the outcome** in a normal, non-blaming sort of way.

3. You're instructed to do something so horribly wrong that it's guaranteed to fail badly. You're in a position to refuse or push back, and you do.

4. You're given instructions that you know are bad, you raise your objections, and then you follow them anyway. It could be a really awful technical approach, use of copy-pasted code, the wrong tools, wrong library, no unit testing, or anything similar. The negative consequences you expect could include technical failure, technical debt, or significant delays. **You do not feel accountable for the outcome.** If it doesn't work, takes too long, or the users hate it, you expect the individual(s) who gave you instructions to take full responsibility. It's not that you want to point fingers, but you will if it comes to that.

---

That fourth scenario could provoke all sorts of reactions. I'm interested in it for what you might call research purposes.

The final outcome is irrelevant. If it failed, whether someone else ultimately took responsibility or you were blamed is irrelevant. That it is the opposite of team accountability is obvious and also irrelevant.

Here is the question (finally!)

Have you experienced scenario number four, in which you develop software (big as an application, small as a class or method) in a way you believe to be so incorrect that it will have consequences, because someone required you to do so, and you complied *with the expectation that they, not you, would be accountable for the outcome?*

Emphasis is not on the outcome or who was held accountable, but on whether you *felt* accountable when you developed the software.

If you just want to answer yes or no, or "yes, several times," that's great. If you'd like to describe the scenario with any amount of detail, that's great too. If it's something you'd rather not share publicly you can contact me privately - my profile name at gmail.com.

The point is not judgment. I'll go first. My answer is yes, I have experienced scenario #4. For example, I've been told to copy/paste/edit code which I know will be incomprehensible, unmaintainable, buggy, and give future developers nightmares. I've had to build features I know users will hate. Sometimes I've been wrong. I usually raised objections or shared concerns with the team. Sometimes the environment made that impractical. If the problems persisted I looked for other work. But the point is that sometimes I did what I was told, and I felt that if it went horribly wrong I could say, "Yes, I understand, but this was not my decision." *I did not feel accountable.*.

I plan on writing more about this, but I'd like to start by gathering some perspective and understanding beyond just my own experience.

Thanks

I'm in a dilemma.

I started this job about 9 months ago and it's really not what I expected. I'm the sole developer in my department that handles applications built around our customer database.

Well it's pretty boring and there is a lot of technical debt with the source code since usually 1-2 people are taking care of it so they never had proper conventions. And we have super old applications running on legacy solutions like cold fusion 🤢

I also receive a lot of problem tickets that never contain enough information to actually do anything and the people don't realize I have no idea what they do or what their business processes are.

The upside is I'm paid very very well for this job > 100 in a place where cost of living is cheap. And when there's no work to do I can work on side projects.

It's really not fulfilling work and idk if I should stick it out. I also don't know where I would head next. There's not very many companies working on cool stuff. Maybe remote work?

Anyone else have a similar story?

I'm 22 years old and 1.5 years into my first Startup Job. (and second Dev job)
I feel kind of uncomfortable now and I would like to ask your opinions.
I'll start with the work related description of my situation and later add a bit of my life situation.

I develop as hobby since I can think. I'm pretty engaged and love to do things right. So I quickly found myself in the position of the de-facto lead fullstack Developer.
Although, to be clear, were only a few devs - which are now replaced by not so many other devs. I feel often like the only person able to design and decide and implement in a way that won't kill us later (and I spend half of my time fixing technical debt).

I mostly like what I do , because it's a challenge and I feel needed. I learn new things and I am pretty flexible in work time. (but I also often work till late in the night, sacrificing friendship time)
But there are so many things I would love to do and used to do, but now I have no motivation to develop outside of my job.
I don't really feel that what my company is doing is something I find valuable. (Image rights management)

I earn pretty well - in comparison to what I'm used to: 20€/hour, Brutto 2.800 / month for 32 hours a week. In Berlin. (Minus tax and stuff it's 1.800€). It's more than enough for what I need.
But when I see what others in similar positions earn (~4.000), I feel weird. I got promised a raise since nearly a year now. I don't feel I could demand it. I also got the hint that I could get virtual shares. But nothing happened.

Now what further complicates the situation is that I will go to Portugal in April for at least half a year, for joining a social project I love. My plan used to be that I work from there for a few hours a week - but I'm starting to hesitate as I fear that I will actually work more and it will keep me from fully being there.

So, I kind of feel emotionally attached - I like (some of) the people, I know (or at least believe) that the company will have a big problem without me. (I hold a lot of the knowledge for legacy applications) .
But I also feel like I'm putting too much of myself into the company and it is not really giving me back. And it's also not so much worth it... Or is it?

Should I stick to the company and keep my pretty secure position and be financially supported during my time in Portugal, while possibly sacrificing my time there?
Should I ask for a raise (possibly even retroactively) and then still quit later? (they will probably try to get my 1 month of cancelation period upped to 3).

Also, is this a risk for my "career"?

Today, for a feature that doesn't need to be released at all, we had to choose between delivering 2 months later so we could pay the technical debt, or release on time with even more technical debt, and 96% sure this will kill the project.

Guess what?

Remaining two days of current sprint : I offer to code unit tests to increase coverage, technical debt and stuff.

My colleague : I will start next sprint's feature.

:facepalm: :jealous:

!Rant

How do I get into Technical blogging? I think I have a lot to say and it will probably vent my frustrations, especially on the need reduce technical debt...

and also figure out what m my ideal team would be...

But whenever I start writing (which is rare) I can never finish... Gets sidelined by other things...

Have you ever considered switching to IT support/help desk?
I mean, sometimes I try to analyze my own situation from a 3rd person perspective and I realize I could have a pretty much stressless job with still enough money to live a normal life.
I have a BSc and MSc(soon to have) in CS, with focus on AI/ML. I've always been a geek with a problem solving attitude, that's why I got into computers in the first place. And now I'm pondering if I should just try an IT Support position, it's the kind of things I used to do as a teenager when a classmate had a network/computer problem, it doesn't even feel like a job to me. I could call it a day, get home at 5/6pm, and spend time on my personal projects (software, infosec) with a fresh mind, going to bed (and sleep) knowing that the next day would be a nice one. No clients wanting a new feature that you gotta implement and push on a production server friday afternoon because your ceo(who is also a pseudo proj manager) just said:"Yes, we can", while you watch the technical debt rising like amazon's stocks.
Maybe this is just the burnout talking, I don't know. Maybe I should just try being a software engineer outside of Uni in the first place, and only then start pondering.
Maybe a sysadmin position...
Have a nice day

Oddly enough, i have simultaneously been less busy and more productive since working 66% remotely.

I find myself with more time that feels "wasted" or not busy, but my metrics show that I have more production, better results, and far nicer documentation. A bunch of us also sat down and did a bunch of coursework on really putting together a domain script library for one click onboarding of new servers or new client setups. We spun up a bunch of new virtual environments that literally solved headaches that had existed for years that never got dealt with because of too many other tickets.

Some of our web clients freaked out at us because the business is moving away from doing maintenance of legacy web work (small to midsize businesses). But it didn't matter. Rather than respond with a "make them happy," the response was "well, we will get rid of them as clients. We need to focus our energy on the essential service sectors we support."

Hell, we even got an automated test that has been broken apparently since 2018 to work again.

Granted, the incoming workload has slowed down. But it's still interesting to me to see that despite the slowdown, there isn't any concern; its still paying the bills and we are getting rid of technical debt everywhere. Tbh, this has really been a good reality check.

My coworker had to face this one: When SonarQube shows you 50 years of technical debt within 1.5 million lines of code from someone else and you have to fix the worst.

#FeatureDrivenDevelopment

I'm just glad that someone helped me do front end in an unrealistic deadline given to us in 2 weeks to finish a corporate-scope project .(2 of us working on)

Now that we realize that he made was another issue that leads to technical debt.

I will do all the refactoring and assure that it works perfectly fine.

Ok so first technical blog post/rant cuz I just reduced a lot of debt... Prolly gonna put this in an email to my boss (he says progress improvement is now a priority but there are some problems as listed below):

So last week, I spent a lot of time investigating db logs manually to figure out a prod issue: tiring, time consuming, and not very effective.

This week I built an app. It took a few days but having the time to design it correctly, it is very powerful.

So in order to really do process improvement, you need to have: dedicated the time, the problem solving mindset (the right people), and the understanding of what the problem is and why so you can build a good solution (time and people).

What do you call time spent by a new dev learning a company's codebase?

Genuinely asking because, as a non-native English speaker who has to communicate with English speakers on a regular basis, I usually end up saying that a dev is still studying the code or familiarizing himself with it.

I'm not sure why it kinda feels off for me. Is there a specific term that describes this?

Sort of how technical debt tells me that it's the cost for someone being lazy with his work before.

The customer told us that we have had a good momentum lately and that we need to keep it so that we can finish on time. What makes me frustrated is that what he perceives as "momentum" actually is increasing technical debt and overtime work...

Technical debt = I dreamt I went jogging....😦

Technical Debt is a Ponzi scheme. Change my mind.

I hate weekly demos. Why not wait until something is done and ready to show, and then schedule a show an tell?

Otherwise you're just racing around to get some half-ass, not working rubbish in to make things look good. Yet it probably doesn't work at all, and is filled with technical debt that will make it to production.

The term "technical debt" is poorly used. I hear folks of all stripes and roles proudly proclaim that they've "reduced technical debt" in some way. It's used as a catch all to describe some kind of supposedly beneficial change. I think it's just more software process word salad. Mostly because there seems to be some assumption that "Yay, that stuff that was changed is no longer a problem" when odds are that it will be changed again before too long for more "technical debt reduction". Software changes over time because the requirements change over time. I don't see the need for the phrase at all, and I think using it gives some false sense of accomplishment when really the constant change of code is the normal state.

I'll never finish this shit!!!

Whenever I close a task I end up creating one or two more I found in the way, it's like an infinite rollercoaster of technical debt and perfectionist-me throwing work at myself.

Any of you are annoyed by your non-technical manager work practices?

Every release I feel like our manager's goal is to have our planning and results look good in front of higher management, no matter if it is true or not.

Oh this big task could not be done because we had to plan 4 months in advance with no info and poorly done requirements? Well let's just push it to the next release we can't have unfinished tasks logged in.

Oh we don't have time to work on tech debt and refactoring, there are too many features and bugfixes to do. Well maybe that is why there are so many bugs, eh?

Oh your automated test results need to all look perfect, does not matter if your test are even good or actually doing anything in the first place, as long as it passes.

Also, I was promised agile and got a waterfall-like bullshit process instead that barely works.

Anyways just morning rambling.

Bash mentality: when in doubt, quote it.

I figured it all out, where all the bad code comes from, I know it now!
I think good developers need two things, an ego that makes them wanting to be competent and perceived as such and (very important) a problem with authority!

All the bad code is written by people who wanted to be liked by their teachers. The PM and PO are their teachers now and they make everything possible for them. Technical debt and human costs are swept aside when the authorities want a stupid feature now - because they have to like you and you need to be a nice pet to whip!

So we have duplicate code because dumb devs thinks Bootstrap (4) is kick-ass for mobile. 😒 Can't do jack with their tables.

I told them to use Flexbox instead. Bootstrap (even 4) is antiquated and there's better options.

My recommendation is to use Flexbox Grid with React to build a modular living style guide with built in unit testing for styles and interactions.

Basically got told that my opinion is just an opinion and is the same as using Bootstrap. 😭

Anyone have some solid "facts" on Bootstrap I can use in the long run? We haven't even launched anything and we're already in technical debt because of this stupid framework decision. Someone please help. 😞

Comment introduced by a commit 3 years ago before an empty function:

```
%% TODO determine if there needs to be something here or if this can be removed
```

Found this in a shell script. Instead of just one regex, why not use grep and sed, even though you could have just done it all with sed!

IMAGE_TAG=`grep defproject project.clj | sed -e 's/^.* \"//' -e 's/\"//'`

A lot of the skills I use at work are actually learned on my own time. And a lot of the time, it feels like I trying to drag the team forward but everyone else does things that drag them, and thus me as well, backwards.

There's always work but most of it is low value and there's just less and less time to make things better because no one else has any opinion of how things should be...

Maybe I should just give up... Again....

I really need to find a better job or at least one without so much technical debt.

Feels like actually my PM is exactly like the name of in Phoenix Project... But I guess he'll never take any meaningful action.

But when I'm not sure what that is... Guess it really is hiring the right people and doing things right from the start, it at least fixing them immediately.

**END internal monologue and summary**

Whenever I go out for a walk now, I get a monologue in my head about everything wrong with my team... But using managerial terms like man-month, velocity, chaotic, context switching costs, lack of processes and standards, need for more slack, too much low value busy work, technical debt, scope creep, (violation of) the two-pizza rule... by a lot

Sometimes I wonder if it's the norm, that the frontend reassemble almost nothing on the backend...

Even worse when a solution is agreed and sold one way, but implemented another.
Usually eliminating the opportunity to properly expand on, without hacky work-arounds.. further driving the technical debt..

I need some advice to avoid stressing myself out. I'm in a situation where I feel stuck between a rock and a hard place at work, and it feels like there's no one to turn to. This is a long one, because context is needed.

I've been working on a fairly big CMS based website for a few years that's turned into multiple solutions that I'm more or less responsible for. During that time I've been optimizing the code base with proper design patterns, setting up continuous delivery, updating packaging etc. because I care that the next developer can quickly grasp what's going on, should they take over the project in the future. During that time I've been accused of over-engineering, which to an extent is true. It's something I've gotten a lot better at over the years, but I'm only human and error prone, so sometimes that's just how it is.

Anyways, after a few years of working on the project I get a new colleague that's going to help me on my CMS projects. It doesn't take long for me to realize that their code style is a mess. Inconsistent line breaks and naming conventions, really god awful anti-pattern code. There's no attempt to mimic the code style I've been using throughout the project, it's just complete chaos. The code "works", although it's not something I'd call production code. But they're new and learning, so I just sort of deal with it and remain patient, pointing out where they could optimize their code, teaching them basic object oriented design patterns like... just using freaking objects once in a while.

Fast forward a few years until now. They've learned nothing. Every time I read their code it's the same mess it's always been.

Concrete example: a part of the project uses Vue to render some common components in the frontend. Looking through the code, there is currently *no* attempt to include any air between functions, or any part of the code for that matter. Everything gets transpiled and minified so there's absolutely NO REASON to "compress" the code like this. Furthermore, they have often directly manipulated the DOM from the JavaScript code rather than rendering the component based on the model state. Completely rendering the use of Vue pointless.

And this is just the frontend part of the code. The backend is often orders of magnitude worse. They will - COMPLETELY RANDOMLY - sometimes leave in 5-10 lines of whitespace for no discernable reason. It frustrates me to no end. I keep asking them to verify their staged changes before every commit, but nothing changes. They also blatantly copy/paste bits of my code to other components without thinking about what they do. So I'll have this random bit of backend code that injects 3-5 dependencies there's simply no reason for and aren't being used. When I ask why they put them there I simply get a “I don't know, I just did it like you did it”.

I simply cannot trust this person to write production code, and the more I let them take over things, the more the technical debt we accumulate. I have talked to my boss about this, and things have improved, but nowhere near where I need it to be.

On the other side of this are my project manager and my boss. They, of course, both want me to implement solutions with low estimates, and as fast and simply as possible. Which would be fine if I wasn't the only person fighting against this technical debt on my team. Add in the fact that specs are oftentimes VERY implicit, so I'm stuck guessing what we actually need and having to constantly ask if this or that feature should exist.

And then, out of nowhere, I get assigned a another project after some colleague quits, during a time I’m already overbooked. The project is very complex and I'm expected to give estimates on tasks that would take me several hours just to research.

I'm super stressed and have no one I can turn to for help, hence this post. I haven't put the people in this post in the best light, but they're honestly good people that I genuinely like. I just want to write good code, but it's like I have to fight for my right to do it.

Slowly I'm learning not to give a shit anymore. This project I'm on can burn. I'll make progress and help out my fellow devs, but if it takes me longer than estimated to complete my tasks because of the unforeseen technical debt arising from this piss-poor excuse of an application design (plus we're 13 devs working on like 5 different feature branches - God help us with our merge conflicts) then so be it. If my tech lead complains, he can find someone else to take the wheel.

I find it very surprising that people at work are always reluctant to do code reviews. There are no standards in place and everyone is free to push whatever they want. There is Sonar but it doesn't catch bad logic. Don't know how are we going to deal with this technical debt.

how hard is it to set up a wordpress site? i hate to ask but am too busy just to try.

i always build everything from scratch, but my mother constantly asks for a new website providing wp-templates as examples. none of my past fancy features were used so i am a bit tired of putting in the effort. is it worth it or would i just create technical debt? what about security concerns, updates and upwards-compatibility with new php versions to come?

Sometimes I think computers and the work conspire to make me an alcoholic. Trying to rush the release and thanks to piled up technical debt it's taking ages. And as it is taking ages, other work is piling up so I would have to rush to something else without cleaning it up and will be swearing again next time. That gives me headache. And to cure it I need to drink. And drinking gives me different kind of headache. All those stupid endless circles are ruining my life!

Hasn't technology become magic - and we ignorant sorcerer's apprentices who can perform a video call to the other side of the globe perhaps while we understand only some bytes of the thousands software snippets that were piled up by us code monkeys to perform the miracle? ...

This however has always been the state of software (for us developers): that this house of cards needs constant care by our hands to not collapse - in constant fear we may preserve the facades while the number of components that interact, the sheer mass of code only allow for guesswork and hotfixes accumulating the technical debt. Yes, we have all that terms for that. The problems are known since the 80s or 60s, so we might be relabeling it once in a while, but mainly it is just: complexity.. or entropy.

First project at new company ended up shit as clients kept using the backlog to define and refine their business requirements. Did not go to production.

Second project at same company ended up the same way, except it had more infrastructure issues than technical debt (and an asshole for a project manager).

Basically I'm scoring 2 for 2, and totally expecting my next project to be doomed too for a 3 score. Maybe I'll build up enough rep as that guy who dooms projects to just sit on my ass and collect my paycheck while I work on my personal stuff.

So our code gets released on Monday. Do you guys think I survive another week and not get fired?

It’s Friday. Survived another week. I feel like Monday is like my last day. I feel every day is my last day at work.

Well for many reasons which are true. Rewording my review so that I don’t get fired prematurely:

Sucks at Jira, does not do many code reviews, lot of technical debt. There is more...

The moment you realise the team you have joined has just finished a brittle implementation: "Wish I was here to stop this."

Management that understands and respects the true virus like nature of technical debt. Considers the implications of bolting on more features. Gives me a place at the table in decision making regarding these matters.

Don't settle for any less.

Im hoping the dept of ed will work with me here.

i have been trying to pay off this technical debt. Otherwise, the new feature won't launch and i might screw up this contact. hope that the govt will understand that i can't pay financial debt until these bugs are resolved.

I mean that's how it works right?

Does rapid application development methodology leads to more technical debt compare to other ones? With a factor like deadlines, a small number of team etc? 🤔