Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuck
Buy Now
-
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...
4 -
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.3 -
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.8 -
"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 ? :D10 -
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?13 -
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.3 -
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,
Platypus15 -
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.10 -
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.6 -
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.10 -
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.8 -
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.6 -
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.3 -
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?
2 -
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.
-
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.42 -
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. -
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.2 -
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.
-
LPT: Avoid building any complex report/tool with Excel, because you will forever be fixing the damn thing!1
-
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. -
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.9 -
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
2 -
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..2 -
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!2 -
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 high6 -
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...20 -
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)1 -
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)6 -
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?5 -
*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??2 -
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.9 -
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.1 -
Time for a full refactor. Everyone can go home for three days while I unfuck every page and pattern.
-
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... -
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.2 -
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.
-
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.14 -
"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..1 -
!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...5 -
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!2 -
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. -
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.3
-
Adding "highly skilled in code divination and paying off bankrupcy-level technical debt" to my resume.
Thanks PHPepsi, you trained me good for this...1 -
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?1 -
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.1 -
Management doesn't know about that "technical debt stuff" because is something the developers must resolve.
So, they set unreal deadlines to "make room for resolve that technical debt thingy" (literal quote from one of the managers).
So every sprint the technical debt is increased, leading to more unstable releases, leading to more bugs, leading to less time to develop new features and fix the mess.
I don't have to explain anymore how stupid is this.
Fortunately, this is from one of my company's client.
Unfortunately, I have to work everyday with them.2 -
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... -
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).1 -
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?6 -
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.6
-
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.2 -
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... FML1 -
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...2
-
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.1 -
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.4 -
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! -
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.1 -
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
```4 -
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 lot7
-
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** -
"All Tech Projects Run Over Budget"
https://medium.com/@team_96861/...
I was on a nice streak of being calm for a while and then this article just dropped today. Fuck management and fuck whichever dumbass wrote this piece of shit.
Is anyone else pissed off at this? It makes it sound like software engineers are slow and never on time, and the main reason for a project's failure is the inability of programmers to meet deadlines. I find this a little sus, especially as it's written by someone in a management position.
I would argue that projects fail because:
1. Management takes the very feasible timeline given to them and throws it out the window, opting to impose impossible deadlines instead, because FUCK your employees right?
2. Clients have requirements that can't be met (I agree w/ this from the article, but not the part about developers not accounting for issues--I always do this and everyone I know does this)
3. Technical Debt arising from when management tells the software engineers to *just do it this way because it's cheaper*
The calculator they made is nice but it's also quoting estimates that I and everyone I've spoken to agree with, so this is clearly not a software engineer problem, it's a fucking management problem. "Budget" = accounting's job.
/rant
That being said, the "take their quote and triple it" part had me dead...1 -
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!1
-
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... -
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.2 -
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.4
-
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. -
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? 🤔
Top Tags
Weekly Rant
View