3 months ago:
"Can you comfirm that each user account can have no more than one of these entities?"
"Yes. Definitely."
Today:
"Oh by the way, we have some users who need to have multiple entities. Can you fix it?"
this post was submitted on 23 Aug 2023
863 points (98.1% liked)
Programmer Humor
18961 readers
345 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
I eventually learned to never trust any restrictions on the user.
I quickly learned to make sure everyone had a copy of decisions made, so that I could charge by the hour for changes. I eventually learned to include examples of what would and would not be possible in any specification or change order.
I'm in the exact same boat right now.
Also this change from 1:1 to 1:n entity was like one "minor" feature in a rather larger list of feature requests. It so far has caused more work then all the other features combined.
And months later you'll find out, that your change completely fucks over some internal optimizer statistic and causes the DB to turn into lava.
I definitely don't know that, because of several hour long outages and millions of lost revenue.
Or worse, it was an n:1 and they want it n:n
Even worse, they'll claim it was a bug
this is ongoing now. Our "creators" were supposed to be "matched" for a "job" based on "skills", not "skill". pure chaos
Oof
Jokes on them I charge by the hour
I was about to say. Rejoice! If this is a client these are billable hours
yea, but it stops being fun when they say it's a bug and it's always supposed to work like that.
Then it's a valuable lesson in writing your client contracts and your work change order templates.
If you bid per project you need to have clear milestones and sign-offs. If you bill per hour then it's not issue.
It's a good thing I'm a hobbyist so that I can avoi- hmm, now that I think about it this feature could be really cool and shouldn't take too long to implement...
2am me: why the fuck this doesn't work anymore!!!
Spouse at 7:00 AM: "Why do only some of the house lights work and there's no hot water?"
Me: "You know that quick fix I was working on last night. Well, umm, one thing led to another aaaand... Umm... Just so you know, your phone is using mobile data because the wifi is out."
In consulting, that’s called “after work”. Got to pump those billables
Honestly though, unless it’s a feature that is completely outside the domain of the application. If you have to re-write your entire app then your app was probably dog shit to begin with
To be fair, it said "an enormous amount of code", not "your entire app", but yes, the ability to add unexpected new features or make focused changes without touching more than a minimal amount of existing code is a very good smell metric of code quality. The problem is that for every dev who understands how to program like that, there are at least five, probably more like ten who don't, which means most of us are working on teams that produce a blend of clean code and, as you say, dog shit, so the feature request that requires stirring up all that shit is out there waiting for us, like it or not. The best we can do, when it hits, is try to at least improve all the shit that we touch in the process. Maybe some of it can become compost, I dunno, the metaphor breaks there, gonna have to refactor the metaphor.
Yeah, that wasn't a SOLID piece of work
Jokes on you, I like refactoring code.
Refactoring is healthy for code.
This is a good thing!
If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.
Your frontend will always churn, that's the nature of the job.
Your frontend will always churn, that’s the nature of the job.
Yep. The trick is to be gone before anyone finds the gross stuff needed to make it all work.
cries in open source frontend development
Bro that’s just Tuesday
My favorite thing was having to rewrite an enormous amount of code to support a new feature because the original architect originally wrote an enormous amount of code in anticipation of supporting a new feature like it.
I just had to rewrite all my code for 3rd time in a row and I am the customer. Ughhhh
Twitter API user found.
I mean I am the one causing myself to have to rewrite my code. I am developing a VR Theme Park.
We just need to change one field into an array, so that users can be linked to more than one location.
We estimate around 400 hours work.
We estimate around 400 hours work-
In order to analyze the problem, inform stakeholders and a allow for a brief period for outlining the next potential steps to be decided by the steering committee. Once there, we can talk about allocating developer hours to enabling the resolution and it's required upgraded dependencies. See my previous estimate sent 2/7/2018.
Oh the flashbacks... Do you work in healthcare or banking?
AR application development.
Good lord it's everywhere. Get the flamethrowers...
3 years and $5m down the drain for something we just got in production this year.
Could have been worse?
Thats what end of life-ing your products is for 😎
How about end of life-ing your client?
😎
Sounds like job security to me.
I pretend I do not see it
You'd think this is stupid but this has surprisingly worked on more than one occasion for me.
Lmao power move
And you'll have to do documentation and everything and then they won't even use it.
Composition helps a little at least
This literally happened in my meeting last week. Top position development manager was complaining the existing thing was shit. Basically means we have to build a new thing from scratch. And guess what? The deadline is 12 Sep.
If you think it was shit why did you let them do what they did in the past?