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

In the cave of technical debt...

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...

Client: This codebase is known to be ripe for refactor. We'll probably have you do that.

Me: *opens up codebase and notices inconsistent coding styles, bad design principles, and direct contradiction of accepted community standards for how to use that particular language*

Me: I suppose to start, do you guys have some coding standards I can look at to help cleanup the code in a way that is consistent with your other codebases?

Client: This one team was working on developing some, but they haven't touched it in a while. We don't really need them, though.

Me: Ok, then I'll do my best to make sure coding styles are consistent using my own knowledge. Why are you guys doing [thing that contradicts community language usage standard because it causes memory issues]?

Client: Well the docs talk about [similar x scenario], but don't mention [actual y scenario], so we decided to go our own way. It doesn't really matter, right?

Me: It can cause memory issues because you're largely bypassing some of the atomicity and garbage collection checks that come with the runtime by default. I'll change those to be safe.

Client: Why are you so concerned about these small things? We need to refactor the structure of the code! We don't have time for this!

Me (in my head): Because your codebase is unreadable and several of your issues could likely be fixed by following community guidelines.

Standards are important and should be agreed on by the Dev team using them. Community guidelines exist for a reason, even if they aren't 100% documented. These things may seem small, but they often make a world of difference when it comes to supporting your code and reducing technical debt. If you let your devs be cowboys, your code will be the Wild West.

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

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.

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?

WHY WRITE GOOD CODE WHEN YOU CAN HAVE TECHNICAL DEBT?

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.

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

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.

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.

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.

I hate marketing department. They have no idea how much work is involved to make their pedantic "minor" and pretty useless changes. But instead of considering the technical debt something will cause, they just want it done.

When they say "it's just this, it's easy" I seriously want to strangle them.

You do it if it's so easy assholes!

If I tell you the framework we use does it a certain way and to change it means to track down and make changes to core across entire system that most likely will break other stuff for something bullshit minor visual effect they seen on a competitors site that has an entire dev team of at least 5 devs, not a single dev that also takes care of there stupid servers, plus doesn't use the same framework we do, makes me beyond rageful. And then when i finally get it done, they decide they like it better a different way! Fuuuuuck I hate you!

Decided I really hate marketers.

Sometimes I wonder if I made the right decision not taking the job offer.

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.

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?!

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?

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.

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

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.

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.

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

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.

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.

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.

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

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?? 😠

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.

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!

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!

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

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...

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 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).

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

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.

I wish business people understood the importance of tackling technical debt

*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??

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 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.

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...

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

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.

Ideal dev job?

Working remotely for an established company on a modern but not immature stack with a small but non-zero amount of technical debt for a good but not great salary with 3.5 weeks vacation and ample sick time. Also good unit and integration test coverage and continuous integration.

Is that too much to ask? :)

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

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.

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.

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.

"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..

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.

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!

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.

!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...

Technical debt is paid back in time and frustration

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...

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

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

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?

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.

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

We were asked to go from a prototype iPhone app to a fully released application to the App Store in 7 months. This probably doesn't sound like a lot, but it was a communications application in a healthcare setting. We had to hook this in to corporate systems, write backend server side code, setup a 3rd party platform that handled the communication and utilise their framework for the app (which they sent us several versions that just didn't build). We had all of this and only 6 devs to do the work. 2 months in, we realised we weren't going to hit deadline unless we picked up more developer capacity.

Normally, this would happen by hiring more devs.

Their response was to have all 6 of us work 60+ hour weeks and some weekends for the remaining 5 months until we managed to crap an application out to meet deadlines that sort of worked.

We then spent 2 years fixing it and cleaning up the technical debt caused from this process. Needless to say, I no longer work for them.

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?

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.

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).

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

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"?

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

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 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 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...

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.

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!

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
```

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.

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. 😞

Bash mentality: when in doubt, quote it.

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.

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.

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

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...

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!

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? 🤔