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
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
The way 90% of the population wears their face masks really explains a lot about their approach to using software, apps & websites as well.
I feel like giving up.
I am not a developer for the salary, or just to solve analytical puzzles. Those are motivators, but my main drive is to make the world more comfortable and enjoyable, better optimized, build ethical services which bring happiness into people's lives. I want to improve society, even if it's just a tiny bit.
But if users invest absolutely zero percent of their limited brain capacity into understanding a product that already has a super-clean design and responds with helpful validation messages...
...why the fuck bother.
I used to think of the gap between technology and tech-incompetent people as an optimization problem.
As something which could be fixed by spending a fortune on UX research. Write tests, hire QA employees, decrease tech debt, create a bold but unified & simple design.
But the technologically incompetent just get more entitled with every small thing you simplify.
It's never fucking fool-proof enough.
Why can't I upload a 220MB PDF as profile picture? Why doesn't the app install on my 9 year old Android Froyo phone? Why can't I sign up if my phone number contains a  U+FFFC? Why does this page load so slowly from my rural concrete bunker in East Ukraine? WHY DO I HAVE PNEUMONIA, HOW DID I GET INFECTED EVEN THOUGH I WAS WEARING A MOUTH MASK ON MY FOREHEAD?
This is why I ran away from Frontend, to Backend, to DBA.
If I could remove myself further from the end user, I would.
At least I still have a full glass of tawny port and a huge database which needs to be normalized & migrated.
Fuck humans, I'm going to hug a server.
25 -
PM: 2 months? no thats way too long, do it in 1.
Director: I had a chat with someone else who doesn't work on this team, he says that developer you complained about is a good guy and we should keep him on the team.
Business: No, we don't have time for tech debt, lets build these new features as quick as possible and lets see where we are.
everyone: WHAT DO YOU MEAN IT CRASHED AGAIN??? THIS IS UNACCEPTABLE6 -
How I went from loving my job to wishing i dont wake up tomorrow just to avoid it.
Ive been a backend dev in the company im at for 2 years now.
First year was a blast, i loved my work so much, I used to get so many random features to do, bug fixes, campaigns, analytics, etc..
Second year i started getting familiar with the part of the code that has to do with Search in our music streaming app. Nobody wanted to work on it, so i wanted to take initiative and start doing a few tasks.
A few tasks turned into sprints, and sprints turned into months worth of sprints. And because the code was the definition of tech debt, and because it was so messed up that changing one thing can blow up everything else, working on Search was not too fun.
However, people seemed to be happy search tasks are no longer piling up and someone is handling them so that used to make me feel good about it. They also gave me so much freedom and i felt like my own manager because no one told me what to do (not even my actual manager) they just let me be and were happy i was handling the part they want nothing to do with. I was also given an intern to mentor and have her work on Search tasks with me which turned out amazing.
During the last few months, I completely rewrote search, made it 10 times more performant in such a neat way, made an inhouse dashboard to automate certain tasks so we wont need to waste developers on them (all of which were extra effort on my own time without being asked), all meanwhile still tending to the fixes of the old implementation.
I felt so accomplished, and in a way, i felt like a lead (even tho im not managing any employees, i had so much freedom and I was literally responsible for everything about Search and if i decide to play with the sprint task order i can even do that).
Then 6 or so weeks ago my manager left the company, and while i thought id be a standalone team / person (single person teams are not uncommon in the company) i was instead put under someone else. Someone who likes to micro manage the fuck out of me. I have been happy working on shit code because it was my baby, my project, no one interferes and no one tells me what to do and everyone would call me the search lead (unofficially). now if i dont report to that guy every two hours he calls to see if im working. preplans sprints i no longer have a say in, and im the only dev who knows the code so all tasks go to me. I feel i got demoted so fucking much. I felt like a lead on a project and now im back to being a normal code minion. From deciding everything about a project to blindly following a some irrelevant manager's opinion. (who btw is making Search worse) And after all the extra effort i put in, after actually caring, after actually embracing Search as my responsibility i get rewarded with losing everything i liked about my job...My Independence. From feeling like a lead to feeling demoted. I am so demotivated.
I love the company, but this is hell for me and this made me hate a job i always loved. I am thinking of talking to the CTO asking to work on other stuff because i no longer want this. If i am to be a code minion at least let it be on code i like, let me go back to dealing with PMs, fuck my new manager I dont wanna work with that guy he can take the project along with all its poopoo.16 -
A seasoned colleague just wrote this and I think it was very valuable:
On tech debt:
So the big challenge with technical debt is making non-technical management (CEO, COO, CFO, directors) understand what it means, and just how it operates. Sometimes it actually makes good sense to incur technical debt to get to market sooner, just as it sometimes makes sense to borrow money to get cash now and repay that loan later with (hopefully) resulting greater revenues from that investment. But just like a loan, tech debt always has to be paid some day. The longer the tech debt goes, the more expensive it gets. And also like a loan, the cost compounds, like compound interest on a loan. Tech debt should always be chosen with a clear plan to pay it off at some point in the not too distant future. The longer one waits to pay it, the more expensive it gets.7 -
One team was delivering for 12 months.
... but definition of done not met. Code crap everywhere. Tests barely there and are total mess.
I inherited mess after previous lead engineer.
I exposed all the issues to the management in a straight way, no sugar coating.
... and now guess who's the bad guy for "complaining" instead of shut up and "making it work"?
P.s.
"Giving accurate report about situation" is seen as "complaining".7 -
We were still using python 2.7 waaay into 2020 - It had been heralding the impending doom since 2018 and finally end-of-lifed in 2020.
That's when I finally managed to be the loudest asshole in the room and allocate a team (myself included) to refactor shit up to 3.6 (then somewhat more modern) for a month or so.
COVID the destroyer may have helped by wrecking havoc on our client's demands pipelines.
It was the third week into "the red sprint" when my entire team (myself included) were beheaded out of the company since we had "not delivered ANYTHING in weeks!" (emphasis in the original).
Frankly, being laid off was by a large margin the best thing that company ever did for me.
I heard from a poor schmuck who stayed behind that they were still using the shitty spaghetti code from before our refactoring - in freaking November 2021 - and that our entire last effort was thrown out because "nobody knows how to use it".
There is tech debt and there is tech bankruptcy.
I may have a lot of tech schadenfreude now :)13 -
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.7 -
I fucking want to skin alive my engineering senior director and VP.
Fucking piece of shit people. Looking at their faces from behind the screen, I can sense them stink doneky balls.
They have made my life hell.
The entire tech architecture is absolute shit in nature and engineers cannot even build a single blue colour button without creating a major fuss about it.
Every single aspect of product is built kept in my only the engineer persona. Everyone else can go and suck a racoon's dick.
And they have no concept of tech debt. They just keep building and building stuff. And then build some more.
Entire engineering org is in rush to ship shit at the end of sprint and if they don't then VP and Director are pissed. So to keep those two half witted donkeys happy, these people ship garbage. And all they comment is "cool, very cool".
And hence, entire fucking product is built because it's cool irrespective of whether it solves a problem or not.
A single user role authorisation or authentication is so fucking complex that it would take an eternity for even a developer to figure what's happening.
Fucking toxic human wastes.
There's a company wide mandate to use a certain tech stack, design guidelines, and a vision that all teams have to align. But these faggots are going in opposite direction to do what they feel like and forcing everyone else to ignore all other engagements or alignments with other teams.
These two people should be skinned alive in town square during noon and then left there until they dehydrate entirely. Fucking baboons.
I am so fucking pissed with such mindset.9 -
Dear Product owners / Company Owners / Whoever requesting a feature:
Devs like to know they are adding value to whatever product they are working on. Every time you request a stupid no value added request, you kick the dev's soul.
After several hits the developer will stop caring about the software and eventually will get the job done, but oh boy, the amount of tech debt/trash code the dev is gonna leave behind will be horrendous.
Then the next developer, not only takes the hit from another stupid request, he/she will see the crappy code the past sad developer left and will take a double hit. Of course all of them start proactive and try to fix previous blood trails but sadness will catch them eventually.
If you want you're apps/products/reports to be good in a long run don't make stupid requests.
BAs, Stop being Expensive Email Forwarders and challenge a request, understand the process and then hand it to the developer.
Us developers are sensible cute ponies. Treat us well or expect poor quality projects8 -
Our company maneuvered themselves into a classic technical debt situation with a project of a second team of devs.
They then left, signing a maintenance contract and now barely work on the project for exorbitant amounts of money.
Of course management got the idea to hand off the project to the first team, i.e. our team, even though we are not experts in that field and not familiar with the tech stack.
So after some time they have asked for estimates on when we think we are able to implement new features for the project and whom we need to hire to do so. They estimates returned are in the magnitude of years, even with specialists and reality is currently hitting management hard.
Code is undocumented, there are several databases, several frontends and (sometimes) interfaces between these which are all heavily woven into one another. A build is impossible, because only the previous devs had a working setup on their machines, as over time packages were not updated and they just added local changes to keep going. A lot of shit does not conform to any practices, it's just, "ohh yeah, you have to go into that file and delete that line and then in that other file change that hardcoded credential". A core platform is end of life and can be broken completely by one of the many frameworks it uses. In short, all knowledge is stowed away in the head of those devs and the codebase is a technical-debt-ridden pile of garbage.
Frankly I am not even sure whom I am more mad at. Management has fucked up hard. They let people go until "they reached a critical mass" of crucial employees. Only they were at critical mass when they started making the jobs for team 2 unappealing and did not realize that - because how could they, they are not qualified to judge who is crucial.
However the dev team behaved also like shitbags. They managed the whole project for years now and they a) actively excluded other devs from their project even though it was required by management, b) left the codebase in a catastrophic state and mentioned, "well we were always stuffed with work, there was no time for maintenance and documentation".
Hey assholes. You were the managers on that project. Upper management has no qualification to understand technical debt. They kept asking for features and you kept saying yes and hastily slapped them into the codebase, instead of giving proper time estimates which account for code quality, tests, reviews and documentation.
In the end team #2 was treated badly, so I kinda get their side. But up until the management change, which is relatively recent, they had a fantastic management who absolutely had let them take the time to account for quality when delivering features - and yet the code base looks like a river of diarrhea.
Frankly, fuck those guys.
Our management and our PM remain great and the team is amazing. A couple of days a week we are now looking at this horrible mess of a codebase and try to decide of whom to hire in order to help make it any less broken. At least it seems management accepted this reality, because they now have hired personnel qualified to understand technical details and because we did a technical analysis to provide those details.
Let's see how this whole thing goes.1 -
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.9 -
There is a company providing a very speciffic service. And it has a core application for that svc, supported by a core app team.
That company also has other services, which are derivations of the core one. So every svc depends on core.
Now that we're clear on that... I was working in a team of one of the subservices. We very strongly depended on core. In fact, our svc was useless if integration w/ core broke down.
The core team had an annoying habbit. They refused to version their webservices and they LOVED to push api updates w/o any warnings. Our prod, test, other envs used to fail bcz of core api changes quite often. Mgmt, IT head was aware of the problem and customers' complaints as well.
So as a result, once core api changes we're all in a panic mode: all prior priorities are lowered and revival of prod is to be our main focus. Core api is not docummented, the changes are not clear, so we have to reverse engineer the shit out of it. We manage to patch our prod up w/ hotfixes, but now we have tech debt. While working on the debt, core api changed again, in test env. Mgmt pushes debt back and reallocates us to hotfix test. Hotfix is 80% done when another core api breaks. Now mgmt asks us to drop wtv we're working on and fix that new break. By the time we're to deploy the hotfix, another api breaks in another env. The mgmt..... You get the picture :)
2 years go by, nothing has changed so far.6 -
Man the senior dev where I work produces the most half baked shit solutions but I guess management loves em because he produces results.
Like Holy fuck this whole place just has a raging hard on for Microsoft products. Plus management won't spend any money on dealing with any of the tech debt and our prod solution is just to erect more monoliths.
Someone please end my suffering5 -
You will have a first phase when you will do everything on your own.
Then you will have a second phase when you will totally rely on external libraries found on the internet.
Then you will have a phase when you will use libraries only for the stuff you don’t want to bother because, never reinvent the wheel but do not get too much tech debt.
Then the hyper simplification phase when you will refuse modern solutions for good old robust stuff as they used to do back then
Then I don’t know… but I am getting interested in agriculture
Anyway try always to learn new stuff and don’t be afraid of change as it is normal. And learn other skills not related to code, those will keep you alive1 -
Any one else’s kinda enjoy the process of removing tech debt? always thought it felt good to rip out old shit to put in shiny new shit4
-
I really like my current job.
I work as an analyst developer looking after and sorting out people's old tech debt.
Once that's stable I get pretty free reign to do what I want.
It allows me to stretch from dev into graphic design, security, architecture and training on a very regular basis.
It allows me to keep an eye on tech trends, research and develop ideas using the latest shiny things.
Oh and if I say I need a thing, I can usually get it purchased.
All of the above comes with the "as long as it's for the benefit of the company" disclaimer, but when your direct managers see an IDE and think "okay he's working" the lines get a little blurry.
They keep asking me about my career goals and if I want to manage or move around. Fuck that noise, all of that noise.
Do wut I wawnt.6 -
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.1 -
Sometimes it's better to burn a bridge so you don't even think about crossing it in the future.
See, I left a company some years ago because I didn't see my future in it and all management combined had a collective intelligence of a chicken.
However, I got a call from them a couple of months ago asking me if I could return. The salary was double and the working arrangement seemed fine. On paper. WFH. Flexibile hours...
Since I actually liked the project itself for its technical challenge, I accepted the return offer. What a bad idea that was.
Of course, the things that made me leave for the first time had only gotten worse. Bad leadership, idiot developers in team leader positions. Tech debt higher than Mount Everest. Bad infra that makes you want to off yourself every time you work on it. The whole circus.
Seriously, the "senior" team leader will happily merge code that includes assert(true == true), but hold up a well written MR because he has a personal vendetta with the developer.
Personally, I always check him whenever he starts being an ass. But the poor juniors are in hell. They're terrified.
Now I'm leaving again, but this time I've made sure I can't come back.3 -
Went to the O’Reilly conference on architecture last week. Will say there were some good points made (really liked the elephant in architecture and tech debt talks). But wow developers love to circlejerk. If you don’t deploy microservices on the cloud with serverless actions for everything then they’ll talk down to you like what you do isn’t important. Like so many talks memed monoliths were annoying. Like I get we love the new and shiny things but it’s kinda ridiculous.1
-
What is it with people just blindly fucking copy pasting from a different project, seeing it work and then submitting it for review.
You copy 2 lines, one of which fixes the thing, WHY KEEP THE OTHER USELESS IRRELEVANT PIECE OF FUCKING SHIT IN THE FUCKING CODE WHY BOTHER WITH KEEPING IT IN IT'S MORE TECH DEBT BECAUSE NOBODY WILL KNOW WHY IT'S THERE
WHY DO I CONTINOUSLY HAVE TO POINT THIS OUT IT'S SO FICKONG TIRING TO CONSTANTLY HAVE TO BE THE ANNOYING REVIEWER WITH +20 COMMENTS ON SMALL PRS IM SO FUCKING TIRED OF BEING 'THAT GUY'
In my language it's called being 'slordig'. Whenever I submit sometning for review I always go over the diff to see is I missed anything that is no longer required and remove it WHY DONT THEY DO THAT TOO
And then their PR stays open for 2 weeks like they forgot about it and during standup they say 'its in review' like I havent already looked at your piece of shit code
FUCK2 -
The switch from “Wild West” to ITIL uncovered so much bull crap. 20% of the people where doing 80% of the work. And then people were keeping some things alive by shear will, once Changes and Service Requests were required, it was shown how awful the environment truly was and how few people in the company knew how anything worked.
-
Product and Design have a common enemy. Yes, you guessed it right, Engineering.
The former aim to solve user problems and focus heavily on aesthetics most of the time. While the latter actually does it.
As a Product guy, I admit that I absolutely hate the role these days because all that are asked to focus on is engagement retention conversion and other fancy metrics. Community has missed the entire point of why the fucking role exist.
On the other hand, engineering always asks the best questions. Focuses on performance and scale while periodically checking on tech debt. Yes, they suck at business or sales but when the solution works, things automatically make money.
I DON'T FUCKING CARE HOW BEAUTIFUL YOUR APP IS, IF IT DOESN'T SOLVE MY PROBLEM THEN IT'S RUBBISH.
Functionality and UX matters to more than colour scheme or fonts. Reason why Amazon is a huge. They are functionally solving a great problem while constantly improvising UX and not giving a rat's ass on UI.
Another down side to your fancy design is that the UI elements make things heavier. No wonder engineers have always been the best problem solver.
We lost our way. Tech world needs to go back a decade or two to fix the tech debt.8 -
My tech debt meltdown is happening right now. We are releasing our huge micro service based product next week with no automated testing of any sort. Our front end clients are relatively DRY. No tests and dry = can't change anything = hacks on top of hacks.
Why? Team lead won't listen to me and has beaten me down so I don't care anymore. If it's broken fuck it.2 -
I'm very short tempered at the moment.
A lot like Dr Cox in Scrubs.
And really ... You mother fucking stupid idiotic developers with your tendency to discuss absolutely everything just to not have to work for a dozen more minutes...
But ok. Let's discuss.
But even that seems to be absolutely impossible for you little shitheads.
Instead of discussing solutions, nooooooooo....
We're grown up developers so we discuss how the baddy manager hurt our lil feelings by saying that we're morons for wasting all the fucking time without coming up with a solution.
Now my lil cry babies, once the baddy manager got your pacifiers so at least once in an hour my migraine finally calms down for not hearing your bitching pathetic lil whiny noises...
Face it. Over the years you collected a huge ton of mother fucking tech debt because no one of you actually took a bit of time to use that empty space in your head to think at least a mu further than the dumb jira task you were given.
And yes. That ends badly.
And yes. As it is now in a state of cluster fuck, guess what. You have to work. You get money for it, remember?
And yes. if you would stop moping and bitching and crying and being a pathetic lil piece of shit, you'd realize we could come up with solutions very fast.
But nooo... Let's talk about our feelings.
And how we are over worked.
And how nothing works.
Cause yes. That will be the hail mary that saves us all.
Let me give u a hint: it's a mother fucking waste of time bitches.
I think it's time I put a pacifier not only in your mouth, but arse too. Maybe it helps overcoming the anal and oral phase of childhood so we can at least have something close to adult talk.
*breathes in*
Gooozfraba.3 -
I worked for a company that was in entertainment news. Specifically rock music.
On the terrible night of the Battaclan (spelling?) terror attacks in Paris. Few years ago our site was one of the first to run the story (the main attack happened at a rock concert). Anyway the tech debt that we’d been complaining about for months reared it’s head. The site got so much traffic that it was just fucked all night. Literally couldn’t get the databases back up for about 7 straight hours. -
That moment when you realize your team-mate pushes code to PROD on Friday evening
but you are the one on pager rotation over the weekend...
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 -
I did it y'all, I just put in two weeks. Goodbye tech debt, goodbye anti-patterns, goodbye constant firefighting.5
-
So new job started.
Just for context- old company was shit.
Promised the world but.
No benefits.
Terrible project management.
High pressure.
But green field interesting work (except by now it’s a few years in so it’s a ‘browning’ field but I was on it from the start).
New company first impressions..
Seems a fantastic company.
True to their word they have money for tools.
Making time for personal development.
Much bigger development community/department.
Seems like the term are under far less pressure so far at least.
But a MASSIVE amount of tech debt.
People seem to want to do the right thing and they’re making time to try and deal with it.
But one or two are very opinionated as to how to deal with it.
So this could go either way and only time will tell I guess.
Trying not to over analyse every little thing they say but I’m hyper sensitive to it at the minute while in the early days.
As always the real challenge in IT is the people not the tech. I count myself as part of the problem, sure I will form some opinions and sharing them too.3 -
love it when people rage quit when you fix the tech debt problem they created because they think the fix is too stupid 🤣BYEEEEE!
-
tech debt is a b!+ch you can only pay if your client somehow approves the budget for something they will never notice.6
-
My team now does daily mini-standups: what you did, what you will do, what's blocking u
But with this wfh, I feel like slacking more or just seen to have less critical work to do... but not sure if the other guys are just "padding their list" or actually really busy.
So wondering when I have nothing to do for work/no defined deadlines or deliverables... How do you look busy?
I do have a lot of optional tech debt improvement work I could do but basically these are like backlog... And not really fun.6 -
untangling some spaghetti deep in a tech-debt-ridden repo:
find the bug causing function
only comment:
`//TODO: replace this once <jira_ticket_url> is done`
go to url
updated: 3 years ago
I miss CS undergrad1 -
Rant against a new religion: the Agile Religion, started by the Agile Manifesto: https://agilemanifesto.org
This manifesto is as ambiguous and open to interpretation as any religious text. You might as well get advice from a psychic. If you succeed, you'll start believing in them more. If you don't, then they'll say you misinterpreted them. The whole manifesto just re-states the obvious with grandiloquent words.
For example: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." What does this say REALLY? To me, it just says "deliver software, try to be fast." Great, thanks for re-writing my job description. Of course, some features take "a couple of weeks", while others "a couple of months". Again, thanks for re-stating the obvious.
"Value *working software* over _comprehensive documentation_"
Result => PHP
"Welcome changing requirements, even late in development."
I'm okay with this one as long as the managers also `welcome the devs changing deadlines, even the night before the release date`. We're not slaves; we're more like architects. If you change the plans for the building, we're gonna have to demolish part of what we've already built and re-construct. I'm not gonna spring just because you change your mind like a girl changes clothes.
"Business people and developers must work together daily throughout the project."
Daily? Fine. ONCE a day, sure. But this doesn't give you the right to breathe down my neck or break my concentration by calling me every couple of mintues.
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
- Not if you could've summed up that meeting in an email.
- Whereas that might be true for clarity, write that down.
"Working software is the primary measure of progress."
... is how you get a tech debt the size of the US's.
"The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
Have you heard of vacations?
"Continuous attention to technical excellence and good design enhances agility."
So you're telling us "do good". Again, thank you for re-writing my job description.
It's just a bunch of fancy babble, more suitable in poetry than in the dev world. It doesn't provide any scientific evidence for any of its supposed suggestions, so I just won't use it2 -
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
-
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)3 -
Fuck, I knew that my code for my thesis would at some point become bad and very unmaintainable. Workaround here and there, everything put together "to fix later", just to make it all work "for now". I know what my code does where and when but my tech debt has reached a critical point, where a new idea and new procedure cannot be simply be added. Well, time to refactor and modularize as much as possible😪
Wish me luck that the whole project doesn't brake. Oh and of course so many different changes that I don't know what to put in git and in which order to do so.12 -
Innovation week is upon us! Rejoice and delve into the years of tech debt to be refactored within one week!
Why does anyone pitch "innovation week" as a fun learning experience when a we are doing is cleaning under the rugs? We can barely get typical feature requests out the door in a week due to the overbearing demands of SAFe and Agile ceremonies.
-
Woke up in the middle of the night thinking about work and how the team seems to be always a few steps away from the next production issue and well always busy with urgent work too so that the crap that produces more and more tech debt never get cleaned or fixed...
And now it's grown so big... The bad habits are just sparking more bad habits and well the only person (boss) able to correct course still hasn't realized for the last 4 years... Constantly thinking things will get better after the next sprint. Hell we don't even use proper sprint planning... even I can't keep up anymore and can never get any long term high value/low immediate return work done...
So I guess I'm having a work overload, nervous breakdown before even going back to work...
I have an urge to tell all this to his boss and have him give him a wake-up slap or maybe bring in a more experienced/veteran manager to set the ship right but my boss personally is a very nice guy so don't want to rat him out...
So not really sure now what to do other than maybe just stay in my lane and put up the blinders? And let the whole forest around be burn down... Though I still gotta bear the heat till it all dies down by itself...
Can't say when that is though...3 -
What i thought to be a cool company, turned out to be a shitshow.
Our "Team Lead" when assigning tasks keeps saying things like "it's only..." or "It's just..." or "You only need to change one line [there]..." And that's in regard to a terrible product with a pile of tech debt. So when you actually start to develop/fix things, you end up redoing third of the whole application.
How do you deal with this? How do you tell the "leader" that he should look into what we have in a code before making us all look bad for doing "just this one line change"?2 -
Due to covid, mgrs decided to fire 10% but could not negotiate schedule increase with internal IT. With no promotions or hikes, few full stacks we have leave.
Now am working with 2 data engg doing cloud java microsvs work while learning. Their first delivery was applauded by their mgr who is under pressure to retain them.
I as arch review their code. No unit tests, print statements all around, shoddy exception handling, variable naming issues. We have Sonar by default in our build. They ignore the report. I ask them about it. Seems mgr told them he is getting a contract person from another team on part time basis to do/fix. I share my confusion.
Mgr calls me up and checks if we can put it as tech debt backlog and deploy to prod !!!1 -
!dev Just realized I think I have a over diversified stock portfolio...
Now half 30 different stocks... Some of them etfs....
So many possible themes... Health care, ev, tech, recovery, US vs China debt...
How do you decide?8 -
So... I’ve recently started a new role, and luckily I’ve established myself as someone that knows his shit (more or less) TM.
I’m leading the charge on tech debt, and raising issues about it, first on my radar is the monstrosity of their approach to app config.
It’s a web app, and they store config in a key-value table in the database.
Get this. The key is the {type}.{property} path and this is fetched from the database and injected *at construction* via reflection.
Some of these objects get instantiated dozens of times per-request. Eurgh. -
I don't get why this retard keeps ignoring my comments on a PR he asked me to review. He is a level above me so I can't push it. I just approve his PR and let him know I do so but with a comment. He then ignores the comments and merges his rubbish changes into the codebase thereby creating a tech debt.6
-
When you do work on a front end ticket. You implement the things as UX tells you to, make a few mistakes, fix those as well when QA catches them.
But then UX realizes other improvements they can make , so you toss some of those in and move some of the other shit to tech debt to avoid possibly failing the sprint due to rabbit hole of front end awfulness because you suck at your job.
Then later somebody else a couple degrees above you in job hierarchy, notes a couple tips and things you could fix unrelated to your ticket. But when will it ever end or do. I suck and hate front end work, AY LMAO LEMME SUBMIT THE SAME SHIT WHICH RENDERS DIFFERENTLY BETWEEN CHROME vs CHROMIUM AND EVERYTHING THAT USES CHROMIUM.1 -
Extremely frustrated with the release process and versioning system at my current company. Don't know if this is same everywhere or the half ass release managers can't think of a better way here.
Basically for any client raised issue that can't wait for next release are built as a hotfix. However hotfixes are never bundled togather or shiped to other clients. This is causing a vicious chain, two clients raise two separate issues on same version. Instead of fixing them as single hotfix (however minor the issues) we create two hotfix versions for each with only their issue. A week later same clients come back with the issue the other raised. Once again instead of bundling what is now effectively same code we build hotfixes on top of the clients respective branches. We now have two branches to maintain with same codebase. No matter how serious issue, the hotfix is never made generally available and always created on client's specific hotfix version.
Now that was an example for only two clients, in reality we have released five patch versions of a product in last 2 years. Each product version contains about a dozen artifacts (webapps, thick clients, etc) with its own version. Each product version being shipped to various clients. Clients being big banks never take a patch of product even if it fixes their issues and continues requesting hotfix. We continue building hotfixes on client branch and creat ever increasing tech debt. There is never a chance to clean up or new development. Just keep doing hotfix after hotfix of same things.
To top if all off, old branches are still in svn while new in git. Old branches still compile with ant new with maven. Old still build with java 5,6,7 while current with 8. Old still build from old jenkins serve pipelines while new has different build server. Old branches had hardcoded integration db details which no longer exists so if tou forget to change before releasing it doesn't work.
Please tell me this is not normal and that there are better ways to do this? Apologies I think I rambled on for too long 😅5 -
Me: Hey, that modification though it will fix the issue, it will add a lot of tech debt in the future.
Lead CoWorker: We'll take care of that when that happens.
Guess who's fixing that TODAY? -
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 -
Fuuuuuuuck!!
CR estimates:
Part 1: 2h including testing
Part 2: 2h-2days-maybe never (small changes on horrifically fucked up project noone understands with tons of tech debt)
Managed to pull off the part two in one day.. //yay me?!
Additional day to unfuckup git fuckups (including but not limited to master head not compiling because a smartass included *.cs in .gitignore file which he also pushed..don't ask, I have no clue why..) which was a huuuge deal for me as I usually use only local repo and had no idea how to tackle this.. coworker helped out.. seems I was on the right way, but git push branchy was acting up & said I had to login & ofc I had no clue what the pass was set to (first setup was more than 2yrs ago)..so new key, new pass.. all good.. yay!
Back to the original story/rant: Now I'm stuck with writing jira explanation why it was done this way & not the way customer suggested. They offered only vague description anyways which would require me to do a hacky messy thing, ew.. + it most probably would require major data modifications after deployment to even make it work..
Anyhow, this expanation is also easy peasy in english..
BUT...
I must write it in my native tongue.. o.O FML! Spent almost 40mins on one paragraph..
Sooo.. if anyone will petition to ban non english in IT, I'm all for it!!2 -
After weeks of constant rush, I finally managed to have one week dedicated entirely to reduce Tech Debt.
It felt so good to close all these todos, finally write those tests, that documentation :)1 -
For me, it was when I was on a team doing government work. We had an entire team devoted to deployments etc which were handled via ansible.
Ansible was fairly new at the time (~2015, they had just been bought by RedHat) but the team was definitely doing a great job picking it up and creating install playbooks for _every_ piece of our distributed infrastructure (load balancers, application servers, queues, databases, everything).
I luckily left before stuff got too hairy, but last I heard they are more than 6 months behind schedule. They STILL can't get a reproducible install process with the ansible playbooks! And it's all due to tech debt ie not giving any time to fix things, so its just band aid after band aid.
It's really sad to hear because the sytem itself was pretty cool, completely horizontally scalable and definitely miles ahead of the program they've been using for the last 20 years. -
> People: Mister IHateForALiving, the external consultant who took care of the new client is about to leave :) his leader is searching for someone to help him and build the new features :) we think you should be doing it, you're very good with the frontend
I WILL NOT FIX
YOUR FUCKING
TECHNICAL DEBT
You fucking moron of a "tech lead", working like a human was free; you chose to work like a dog and encouraged the external consultant to work like a dog as well. From now until you resign, this mess is yours to clean.3 -
Every single morning I despair. I can’t stand this job.
Why pay very highly and get very skilled people to have them working 4 to a support ticket. Doing the most mundane support tickets you have ever seen in your life (mainly updating client contact details)?
And why have such a rigorous recruitment process to get people’s in in the first place?
The company is pissing money away by working like this and all the new starters like me think it’s complete shit.
But the bosses and anyone who’s been here a while think it’s great. Company still is making loads of money so they don’t even care about it.
I’ve never met senior developers who have never worked on a greenfield project in their entire careers until I came here.
I can’t believe how I got suckered into this (was head hunted).
Does anyone have a feel for the UK contracting market right now?
I’m considering the jump but I think I’d have to be looking for remote only contracts because where I live has few opportunities ‘on-site’. Preferably c# / angular.
Is there much competition for roles or is there a shortage of skills in the contractors?
The thought of going into another permanent role that could be as bad as this genuinely keeps me awake at night.
I’m not sure I can go somewhere and then have it in the hands of managers to decide what projects I’m going to do and what tech it will be on.
At any big company there’s going to be tech debt as well as new work. So becoming perm now feels like it’s 50-50 whether or not a new job will just mean being put into legacy stuff for a couple of years or doing something that is actually good.
I’ve been talking various people about roles in government departments (multiple different departments are hiring) and because priorities change none the gov recruiters can guarantee what the work is that they’re recruiting for actually is.
Just that the the big recruitment push is to bring work previously done by consultancies back in house. Presumably because consultancies have been fleecing them.5 -
Hey guys, first time writing here.
Around 8 months ago I joined a local company, developing enterprise web apps. First time for me working in a "real" programming job: I've been making a living from little freelance projects, personal apps and private programming lessons for the past 10 years, while on the side I chased the indie game dev dream, with little success. Then, one day, realized I needed to confront myself with the reality of 'standard' business, where the majority of people work, or risk growing too old to find a stable job.
I was kinda excited at first, looking forward to learning from experienced professionals in a long-standing company that has been around for decades. In the past years I coded almost 100% solo, so I really wanted to learn some solid team practices, refine my automated testing skills, and so on. Also, good pay, flexible hours and team is cool.
Then... I actually went there.
At first, I thought it was me. I thought I couldn't understand the code because I was used reading only mine.
I thought that it was me, not knowing well enough the quirks of web development to understand how things worked.
I though I was too lazy - it was shocking to see how hard those guys worked: I saw one guy once who was basically coding with one hand, answering a mail with another, all while doing some technical assistance on the phone.
Then I started to realize.
All projects are a disorganized mess, not only the legacy ones - actually the "green" products are quite worse.
Dependency injection hell: it seems like half of the code has been written by a DI fanatic and the other half by an assembly nostalgic who doesn't really like this new hippy thing called "functions".
Architecture is so messed up there are methods several THOUSANDS of lines long, and for the love of god most people on the team don't really even know WHAT those methods are for, but they're so intertwined with the rest of the codebase no one ever dares to touch them.
No automated test whatsoever, and because of the aforementioned DI hell, it's freaking hard to configure a testing environment (I've been trying for two days during my days off, with almost no success).
Of course documentation is completely absent, specifications are spread around hundreds of mails and opaquely named files thrown around personal shared folders, remote archives, etc.
So I rolled my sleeves up and started crunching as the rest of the team. I tried to follow the boy-scout rule, when the time and scope allowed. But god, it's hard. I'm tired as fuck, I miss working on my projects, or at least something that's not a complete madness. And it's unbearable to manually validate everything (hundreds of edge cases) by hand.
And the rest of the team acts like it's all normal. They look so at ease in this mess. It's like seeing someone quietly sitting inside a house on fire doing their stuff like nothing special is going on.
Please tell me it's not this way everywhere. I want out of this. I also feel like I'm "spoiled", and I should just do like the others and accept the depressing reality of working with all of this. But inside me I don't want to. I developed a taste for clean, easy maintainable code and I don't want to give it up.3 -
I like the people I work with although they are very shit, I get paid a lot and I mostly enjoy the company but..
Our scrum implementation is incredibly fucked so much so that it is not even close to scrum but our scrum master doesn't know scrum and no one else cares so we do everything fucked.
Our prs are roughly 60 file hangers at a time, we only complete 50% of our work each sprint because the stories are so fucked up, we have no testers at all, team lead insists on creating sql table designs but doesn't understand normalisation so our tables often hold 3 or 4 sets of data types just jammed in.
Our software sits broken for months on end until someone notices (pre release), our architecture is garbage or practically non existent. Our front end apps that only I know the technology have approaches dictated by team lead that has no clue of the language or framework.
Our front end app is now about 50% tech debt because project management is so ineffectual and approaches are constantly changing. For instance we used to use view models for domain transfer objects... Now we use database entities, so there is no commonality between models but the system used to have shared features relying on that..sour roles and permissions are fucked since a role is a page regardless of the pages functionality so there is no ability to toggle features, but even though I know the design is fucked I still had to implement after hours of trying to convince team lead of it. Fast forward a few months and it's a huge cluster fuck to enforce.
We have no automated testing of any sort or manual testing in place.
I know of a few security vulnerabilities I can nuke our databases with but it got ignored.
Pr reviews are obviously a nightmare since they're so big.
I just tried to talk to scrum master again about story creation since any story involving front end ui as an aspect of it is crammed in under one pointed story as sub tasks, essentially throwing away any ability to calculate velocity. Been here a year now and the scrum master doesn't know what I mean by velocity... Her entire job is scrum master.
So anyway I am thinking about leaving because I like being a developer and it is slowly making me give up on doing things to a high standard and I have no chance of improving things, but at the same time the pay is great and I like the people. -
We were refining a tech debt issue about aligning the names and types of the same reference id on different response models. This is to not confuse our API users and make it more intuitive.
Discussion was wrapping up as we all agreed it was a no-brainer and pretty straight forward.
Then suddenly, one colleague goes: "But what's the benefit?"
Errrm...2 -
Any of you are annoyed by your non-technical manager work practices?
Every release I feel like our manager's goal is to have our planning and results look good in front of higher management, no matter if it is true or not.
Oh this big task could not be done because we had to plan 4 months in advance with no info and poorly done requirements? Well let's just push it to the next release we can't have unfinished tasks logged in.
Oh we don't have time to work on tech debt and refactoring, there are too many features and bugfixes to do. Well maybe that is why there are so many bugs, eh?
Oh your automated test results need to all look perfect, does not matter if your test are even good or actually doing anything in the first place, as long as it passes.
Also, I was promised agile and got a waterfall-like bullshit process instead that barely works.
Anyways just morning rambling.1 -
"This component is still using this thing which it shouldn't use." (Changing it won't reflect on the user in any way nor will it trigger a crash. It'd be nice to change it but who cares.)
"Feel free to update it."
Happy 1st birthday to low priority tech debt baby. May you grow up to have a long and fulfilling life.1 -
I knew programming was for me, MUCH later in life.
I loved playing with computers growing up but it wasn't until college that I tried programming ... and failed...
At the college I was at the first class you took was a class about C. It was taught by someone who 'just gets it', read from a old dusty book about C, that assumes you already know C... programming concepts and a ton more. It was horrible. He read from the book, then gave you your assignment and off you went.
This was before the age when the internet had a lot of good data available on programming. And it didn't help that I was a terrible student. I wasn't mature enough, I had no attention span.
So I decide programming is not for me and i drop out of school and through some lucky events I went on to make a good career in the tech world in networking. Good income and working with good people and all that.
Then after age 40... I'm at a company who is acquired (approved by the Trump administration ... who said there would be lots of great jobs) and they laid most people off.
I wasn't too sad about the layoffs that we knew were comming, it was a good career but I was tiring on the network / tech support world. If you think tech debt is bad, try working in networking land where every protocols shortcomings are 40+ years in the making and they can't be fixed ... without another layer of 20 year old bad ideas... and there's just no way out.
It was also an area where at most companies even where those staff are valued, eventually they decide you're just 'maintenance'.
I had worked really closely with the developers at this company, and I found they got along with me, and I got along with them to the point that they asked some issues be assigned to me. I could spot patterns in bugs and provide engineering data they wanted (accurate / logical troubleshooting, clear documentation, no guessing, tell them "i don't know" when I really don't ... surprising how few people do that).
We had such a good relationship that the directors in my department couldn't get a hold of engineering resources when they wanted ... but engineering would always answer my "Bro, you're going to want to be ready for this one, here's the details..." calls.
I hadn't seen their code ever (it was closely guarded) ... but I felt like I 'knew' it.
But no matter how valuable I was to the engineering teams I was in support... not engineering and thus I was expendable / our department was seen / treated as a cost center.
So as layoff time drew near I knew I liked working with the engineering team and I wondered what to do and I thought maybe I'd take a shot at programming while I had time at work. I read a bunch on the internet and played with some JavaScript as it was super accessible and ... found a whole community that was a hell of a lot more helpful than in my college years and all sorts of info on the internet.
So I do a bunch of stuff online and I'm enjoying it, but I also want a classroom experience to get questions answered and etc.
Unfortunately, as far as in person options are it felt like me it was:
- Go back to college for years ---- un no I've got fam and kids.
- Bootcamps, who have pretty mixed (i'm being nice) reputations.
So layoff time comes, I was really fortunate to get a good severance so I've got time ... but not go back to college time.
So I sign up for the canned bootcamp at my local university.
I could go on for ages about how everyone who hates boot camps is wrong ... and right about them. But I'll skip that for now and say that ... I actually had a great time.
I (and the handful of capable folks in the class) found that while we weren't great students in the past ... we were suddenly super excited about going to class every day and having someone drop knowledge on us each day was ultra motivating.
After that I picked up my first job and it has been fun since then. I like fixing stuff, I like making it 'better' and easier to use (for me, coworkers, and the customer) and it's fun learning / trying new things all the time. -
"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 -
Slowly I'm learning not to give a shit anymore. This project I'm on can burn. I'll make progress and help out my fellow devs, but if it takes me longer than estimated to complete my tasks because of the unforeseen technical debt arising from this piss-poor excuse of an application design (plus we're 13 devs working on like 5 different feature branches - God help us with our merge conflicts) then so be it. If my tech lead complains, he can find someone else to take the wheel.2
-
Today I created some reusable clean decent code to replace the random chaos in a huge project and then realised I had 3 options:
1. Sort out every instance to use the new code. This is very high risk because the project is both a shit show and has no tests. I don't have time to manual test or write unit tests on so much stuff.
2. Move over only some so that I can manually test. Still no time to unit test (management is fucked on their priorities). This will fuck the project even more since i will never get time to revisit this and adds yet more inconsistency and chaos to a project on its last legs and has this problem in droves.
3. Leave the project fucked
\_(^^)_/
I'm veering towards option 3 these days.1 -
I can't say how a CS degree helped me since I dropped out, but in all of my tech related jobs we turn down candidates with a CS degree left and right. Turns out showing up for class and managing to pass doesnt give you real world experience, passion, or even knowledge. I used to be a floor factory worker and my team lead was a CS degree holder.
But hey, maybe the crippling debt and super unrelated classes were worth it. -
PHP gurus / masochists.
I've been using Symfony components for new, isolated features in a legacy php application for awhile now. the time has come to integrate using the kernel, and routing for new endpoints while existing endpoints use the existing apache means of loading pages.
It's not my first rodeo doing this, but I'd appreciate any wisdom/resources/patterns you followed for anyone who's had to do the same.
My clients don't have the means to do hire the appropriate ammount of devs to do a proper port, so this is a long path towards modernization by ceasing to bolt on features to existing code and instead, when working on something, updating it to the new design pattern and then extending that, with a spec, documentation and code coverage.3 -
My team is pretty small right now. It's myself and two other guys. One lead, who's been here for five years. A senior who we brought on 2 weeks ago. And me, a regular app dev. The lead put his two weeks in last week and has been trying to brain dump as much as he can onto us.
I've been building a list of prioritization to compensate for when he leaves based on what he was saying was the most important. This list has gotten pretty massive after reviewing most of the processes in place.
I was hired mainly to quell new requests coming in and not to maintain our systems, so that's what I did. I didn't examine our prod code base too closely. I wish I had. It's in a sorry state. I'm pretty sure I have about 2 years of tech debt for a crew of two guys constantly working on it.
I've been trying to prioritize based on what gets the most bug fixes and change requests. These apps will see the biggest changes and will undergo the most maintenance.
Since I'm just a regular app dev it feels weird trying to come up with this and try to prioritize this and come up with a plan. It feels like someone else should have. If it needs done then I guess it needs done. I need to be able to collaborate and work with my co worker and be able to plan for what projects are coming next.
If anyone has any suggestions to tackle tech debt please make them. Or if there's any help for managing priorities in a different manner that may prove helpful I'm open. Honestly, I don't want to tackle this completely blind, it feels like a lot.1 -
I never did get that break I wanted. Though, I did get off incident tickets.
Has been replaced with project after project though, with the emphasis being on "getting it over the wall", so as you can imagine. There is a pile of tech debt that's just being ignored. It'll blow up in production one day.
It's not all doom and gloom though. I've gotten the opportunity to write a few things, from scratch that are separate from the rest of our products. Nothing nicer than a clean slate, not built upon a steaming pile.
Top Tags
Weekly Rant
View