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
-
"Why is this taking so long?"
"Unforeseen complications"
"Why didn't you factor that in while estimating?"
"Because thats impossible, by definition."7 -
Disclaimer: I can't 'officially' verify this.
I've been using Firefox as main browser with about 5 addons for added privacy for ages now. When googles (fucking) reCaptcha takes more than a few minutes on Firefox (about 90 percent of the time, I'm estimating), I switch to Chromium (with the same amount of (similar) privacy addons) so I can go on with my stuff.
Now, I recently thought 'why not try to do user agent spoofing on Firefox to see if reCaptcha would start working 'normally'?
So, I installed a user agent spoofing addon on Firefox/Chromium, results:
Without spoofing:
Firefox reCaptcha success rate: 10 percent approx. (mostly 2+ minutes)
Chromium: 90 percent. (mostly instant)
With spoofing:
Firefox: 90 percent approx.
Chromium: 10-20 percent approx.
Again, I can't prove any of this yet but mother of fucking god, whenever using Chromium or spoofing Chromium on Firefox the succession rate skyrockets.
Google, what the fuck are you up to?12 -
My company does estimates in two ways.
1. Sales person just throws a number out there, always short, and we panic code to make it happen before the client decides twice as long isn't worth it.
OR
2. The devs are told to give an estimate before having a chance to find out all the requirements, THEN ARE TOLD THEY ESTIMATED TOO HIGH AND TO LOWER THE NUMBER!
FUCK THE ESTIMATING!!! GIVE US TIME AND ACCEPT OUR ESTIMATES!! SALES PEOPLE DONT HAVE TO STAY UP IF WE NEED TO CRAM!!9 -
ESTIMATING FUCKING HOURS.
Well not literally, that only takes 10 minutes.
But software estimation... anyone pretending to be good at it is a dirty liar. Adding a button? Uh, let's say 2 hours, I mean I gotta poop in between as well, and it's probably some broken bootstrap theme with hacked custom margins.
Building a commenting system coupled to an ancient CRM? Uh... maybe one day? Maybe a month? I don't even know what the CRMs looks like? You won't show me because "that's irrelevant"?
WELL THEN I DON'T FUCKING HAVE A CLUE.
And in the time we spent on discussing time estimations, I could have written like half of the feature... or zero... because you still haven't fucking shown me what the CRM API looks like.
YOU KNOW WHAT I'LL GIVE YOU AN ESTIMATION. ME. VACATION. DONE IN 6 WEEKS.6 -
That's so true.. when those who will actually perform the work are excluded from the estimating process !
What do you think about it?
3 -
I’m back for a fucking rant.
My previous post I was happy, I’ve had an interview today and I felt the interviewer acted with integrity and made the role seem worthwhile. Fuck it, here’s the link:
https://www.devrant.io/rants/889363
So, since then; the recruiter got in touch: “smashed it son, sending the tech demo your way, if you can get it done this evening that would be amazing”
Obviously I said based on the exact brief I think that’s possible, I’ll take a look and let them know if it isn’t.
Having done loads of these, I know I can usually knock them out and impress in an evening with no trouble.
Here’s where shit gets fucked up; i opened the brief.
I was met with a brief for an MVP using best practice patterns and flexing every muscle with the tech available...
Then I see the requirements, these fucking dicks are after 10 functional requirements averaging an hour a piece.
+TDD so * 1.25,
+DI and dependency inversion principle * 1.1
+CI setup (1h on this platform)
+One ill requirement to use a stored proc in SQL server to return a view (1h)
+UX/UI design consideration using an old tech (1-2h)
+unobtrusive jquery form post validation (2h)
+AES-256 encryption in the db... add 2h for proper testing.
These cunts want me to knock 15-20h of Work into their interview tech demo.
I’ve done a lot of these recently, all of them topped out at 3h max.
The job is middling: average package, old tech, not the most exciting or decent work.
The interviewer alluded to his lead being a bit of a dick; one of those “the code comes first” devs.
Here’s where shit gets realer:
They’ve included mock ups in the tech demo brief’s zip... I looked at them to confirm I wasn’t over estimating the job... I wasn’t.
Then I looked at the other files in the fucking zip.
I found 3 of the images they wanted to use were copyright withheld... there’s no way these guys have the right to distribute these.
Then I look in the font folder, it’s a single ttf, downloaded from fucking DA Font... it was published less than 2mo ago, the license file had been removed: free for Personal, anything else; contact me.
There’s no way these guys have any rights to this font, and I’ve never seen a font redistributed legally without it’s accompanying licence files.
This fucking company is constantly talking about its ethical behaviours.
Given that I know what I’m doing; I know it would have taken less time to find free-for-commercial images and use a google font... this sloppy bullshit is beyond me.
Anyway, I said I’d get back to the recruiter, he wasn’t to know and he’s a good guy. I let him know I’d complete the tech demo over the weekend, he’s looked after me and I don’t want him having trouble with his client...
I’ll substitute the copyright fuckery with images I have a license for because there’s no way I’m pushing copyright stolen material to a public github repo.
I’ll also be substituting the topic and leaving a few js bombs in there to ensure they don’t just steal my shit.
Here’s my hypotheses, anyone with any more would be greatly welcomed...
1: the lead dev is just a stuck up arsehole, with no real care for his work and a relaxed view on stealing other people’s.
2: they are looking for 15-20h free work on an MVP they can modify and take to market
3: they are looking for people to turn down this job so they can support someone’s fucking visa.
In any case, it’s a shit show and I’ll just be seeing this as box checking and interview practice...
Arguments for 1: the head told me about his lead’s problems within 20mn of the interview.
2: he said his biggest problem was getting products out quickly enough.
3: the recruiter told me they’d been “picky”, and they’re making themselves people who can’t be worked for.
I’m going to knock out the demo, keep it private and protect my work well. It’s going to smash their tits off because I’m a fucking great developer... I’ll make sure I get the offer to keep the recruiter looked after.
Then fuck those guys, I’m fucking livid.
After a wonderful interview experience and a nice introduction to the company I’ve been completely put off...
So here’s the update: if you’re interviewing for a shitty middle level dev position, amongst difficult people, on an out of date stack... you need people to want you, don’t fuck them off.
If they want my time to rush out MVPs, they can pay my day rate.
Fuuuuuuuuck... I typed this out whilst listening to the podcast, I’m glad I’m not the only one dealing with shit.
Oh also; I had a lovely discriminatory as fuck application, personality test and disability request email sent to me from a company that seems like it’s still in the 90s. Fuck those guys too, I reported them to the relevant authorities and hope they’re made to look at how morally reprehensible their recruitment process is. The law is you don’t ask if the job can be done by anyone.6 -
Please disregard. I just need to vent.
Being a manager is so fucking shit. This is not even about devs or tech specific only. Never become a manager.
Why? Because it’s about handling people and all the dumb shit they do. It’s all about knowing what people suck at and preventing that weakness from leaking into other areas. The amount of fucked up people on this earth means that you have to work with at least some of them, and that means putting up with their stupid ass list of super special requirements, that if they do not fulfill, will make them a shit worker. It’s not even an issue of technical skills.
You have the guys that are often late, because “they have depression”, but will complain that “companies don’t treat employees like adults”. Being on time for work is apparently very difficult. Which doesn’t generally matter in general for dev work, but it ends up affecting other things.
You have the completely socially inept idiots that make half the team hate them and try to avoid working with them, increasing problems and work for other people. Just because they’re socially stupid, have low or no empathy, or are incapable of not being insufferable to others.
You have the people that are so bad at estimating that they keep making up numbers instead of waiting to think for a few minutes and say “ not sure, I need to research and estimate that”.
You have the surprise absentee for dumb as fuck reasons like “my phone died lol sorry”. They never do anything to actually improve, it is just “sorry guys! Btw I will do jackshit about this”.
Or the ones whining about virtually everything, all the time. Wtf why do I have to be on scrum at 12 tomorrow?! Wtf why do I have to record the result of that customer call? Wtf why should I talk with XYZ?
And if you leave them alone, everything burns. They actually need someone to tell them “hey mate you need to improve that, shall we plan something to do so?”. I think managers are useless and unneeded when you have adults working, but it seems like most of the population is composed of children. It’s basically another form of daycare.
And you have to prepare shit around all of these constraints.
Then you have the one guy that reads the requirements, has common sense, and is inoffensive and can work like a normal adult human that needs no baby sitting. A ray of light on this shitshow.
I just want to go back to pure dev.22 -
Oh yeah that shouldn't take too long right? I mean it's just the front end.
No shut your fucking dumb ass mouth up. It will take long. The front end is very complicated, and your stupid fucking ass who couldn't learn to code is in no position to estimate how long it will take. Do us all a favor and stick to the "business" side. Fucking incompetent idiot.
If you're not a programmer, when it comes to estimating how long a task will take. Just shut the fuck up. Just cause you work in this industry does not qualify you to estimate a task. Just shut the fuck up.1 -
Estimating the task. A total of... 2 months.
Other guy: I think we should squeeze it to 1 month.
Others: I think we should squeeze it in 2 weeks to meet the deadline..
Deadline: 2 weeks
Progress:25%4 -
wk147
Estimating development duration.
Whatever number that first came up on your mind... multiply it with 2.5.1 -
For fuck's sake man! I know you are an inexperienced junior dev/student but estimating 3 months at 6 hours /day for slightly modifying some C# code is just ridiculous.
I may have never touched anything .NET before but the modification required just 3 fucking lines and I did it in a day. In three months I would have finished the whole fucking project.
PS: VS2017 (RC) was quite lovely.8 -
I work for a web agency.
Over the last 18 months a company asked us about 5 different quotes for rather minimal changes to their website.
While being minimal changes, estimating costs for them still requires several hours of work for research, meetings, correspondance and writing the damn things. They never even gave us a response (neither positive nor negative), except once where they told us that they wouldn't pay for project management because their instructions are so clear that PM isn't necessary.
As a response to the last one, after several months, they send us a 10 pages long pdf with requirements for a new website (or a "restyle" like they call it, even if it has absolutely nothing in common with the current one).
We inform them that we can't permit ourselves to continue studying new solutions for free and therefore tell them that a detailed offer would cost them something like 300$, and that amount would then be discounted from the eventually accepted job. We also roughly estimate a price range of about 15k - 20k for the new website.
We get an email back, from the CEO (until now it was a secretary), with essentially 3 arguments written in condescending form:
1. he brags about his revenue being over 9 billion $$$ a year, and that being a part of a global holding for which "communication is essential" (sic.) means that they need to coordinate and "can't simply accept an offer" [even if it's 400$, for specific change exactly requested by them, I guess...]
2. 15k is too much [... for the website representing this 9 billion dollar holding on the internet, for which the requirements are written in the 10 pages long pdf]
3. He asks for a meeting
We accept the meeting, we go to their office.
When we arrive there, the secretary informs us that the CEO will not participate. So we talk the her and the head of the "Communication Dept" in videoconference.
I explain them that if the sum, which we thought would be appropriate (~15 - 20k), is too high, the Pareto principle would allow us to, theoretically, achieve about 80% of the features and quality for about 20% of the cost. Their genuine response is:
"So your estimate was wrong! You can do it for much less!".
I try to explain them that the most money in a project goes into "attention to detail".
The "Communication Dept." person, who is "doing this job since too much time" (sic.), refuses to believe and insists that "details" don't exist on the web.
I tell her: "In any kind of work, the more effort you put into something, the better it tends to get, with diminishing returns".
She insists: "I don't understand this".
So now I'm here, doing the 6th offer, free of charge, for a 5k website, for a company that generates 9kkk revenue each year, trying to define a "Definition of Done" that works out.
FML I guess.
Sorry for the long post.7 -
I fucking hate estimating time.
I appreciate that agile is better than any planning type before it, but HOLY SHIT is estimating time a fool's game.
I've been at this over a decade now and I'm still like.. 50% accurate at best. The complicated shit is seldom obvious, and usually if I think something will be complicated it ends up being very simple once I dig in.7 -
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. -
Scrum. And agile. And people over-communicating. And estimating work complexity on a prototype. And people in general. I like nights, when all annoying people just shut the fuck up and sleep.1
-
People rant here about how they hate documenting things or writing tests or whatever.
Yes these things are not the most interesting but I have a feeling that we are forgetting about most horrendous of tasks - estimating. Especially in agencies. Especially related to altering legacy features. Especially big projects.
I mean, I'm spending time doing something that is basically dev's Voo Doo, hoping that I will be right... and usually I'm not.6 -
Holy shit. In a meeting that literally makes no sense. We're taking credit for work by claiming story points. Story points. How the hell does that work? Especially since we have told management CONSTANTLY that story points are abstract LOE shit and NOT time spent. Yet I suggest if we REALLY want to estimate who worked what we track time spent I get shot down. You can't get a concrete measurement from an abstract concept. Also, we're being encouraged to argue over who does what? What does THAT help? AND we're not even reestimating if we over or under estimating, but being forced to massage our numbers into the estimate. What the fuck?4
-
At one of my previous gigs, the IT director was just some guy that dated the bosses daughter. When she inherited the company he went from entry level data analyst to his new director position. IF he decided to show up to work at all it would be at just in time for lunch, and then he'd head out shortly after.
This guy would ask for an estimate on development and then start the timer when marketing started working on the project. This would often lead to us estimating something like 4 months on a project, and then waiting on marketing for 3 of those months, leaving us with 30 days left.1 -
Anyone else gets PTSD from estimating time expenses on projects you know nothing about, no basic design, specification, or anything besides “this page of the app is called the request handler, it handles requests by other users.” Oh really? Like what kind of requests? What can they request? Who can approve those requests? Etc... Is this normal, or am I just at an unprofessional company with fully incompetent PMs?12
-
Customer: We wanna add this thing to that feature. It has to go live with the next deployment (1 1/2 weeks to go)
Me estimating developmenttime, and informing the Management
management: this will take approx. 12h to implement, but we need these informations: [long list of not answered questions]
1 week later (1/2 week left till deployment
customer: okay, lets do it
management: we dont have much time left, what about the questions i sent you?
1 Day no response, 1 1/2 days left until deployment
customer: here you have a few answers. couldnt get the others. ill Send them tomorrow
damn... wtf? guys! i need this shit to Stay in time! cant wait another day! hell no! -
Battling impossible project deadlines and maintaining a work life balance. Estimating projects properly.1
-
Answering several emails per day from annoying customers.
Estimating expenditures of possible future projects for offers.
Calls from the management. Calls in general.
People coming into my room in the office (where I sit with 2 other programmers) just to have a call, because it's quieter in this room than in the rest of the office.4 -
i am a weak developer, i dont know that much of what im doing, unexpected things come up, i dont like time estimates (estimating time is harder than complexity estimates), some school of thoughts dont like estimates https://youtube.com/watch/...
my manager posed a thought exercise to me, imagine im a contractor (im not, clearly not skilled enough to be) , contractors can estimate how much time precisely a task will take to do their work, get jobs, etc
is it possible to learn this power? how does one git so gud, walk in learn how existing code base works, change, edit , build on top of it, ideally doing quality work8 -
Luckily I don't work at a place like this anymore, but I sure hate it when a company touts that they are an effective company who has implemented agile "the right way", then when they describe their process in detail, it is almost exactly the opposite of what agile is supposed to be.
I've worked for a couple places that just couldn't get their head around the fact that one of the reasons agile exists is because estimating software is hard, and only after doing agile the real right way for an extended period of time can a company expect to have realistic estimates. The business can't go a week without hard deadlines.2 -
When you create a script to automate something, and that one guy keeps estimating high on the task because he likes to do it manually and refuses to use it because "his way is simple and safer".1
-
What i be like when the project manager insist on estimating a full project instead of working in an agile way...
2 -
Estimating time before consulting the dev on the task he/she will be working on is like pouring the milk in before the cereal. CRINGE.3
-
Estimating for a new client, asked for details of their current API. Got the answer " I can't do your work for you". This will be fun!!1
-
Learning programming, networking, robotics, and other technical skills are very important but do not forget that these are future working software developers.
They will need to know a lot more intangibles. Like effective pair programming, performing proper git pull requests and code reviews, estimating work, and general problem-solving skills and more.
These people will be learning technical skills for the rest of their life (if they are smart about it) but what can really get them ahead is the ability to have good foundational skills and then build the technical skills around them over time. -
Don't you just love estimating the story points of a ticket that is completely irrelevant to your role. How do I estimate work that I have never done in my life? 🙄4
-
Estimating a rather simple looking project without a thorough examination of the client's code.
It turned out to be the worst kind of crap a human brain could produce. The project we estimated for 2 months is going to last 6... And if we decided to rewrite it the day we were to estimate it, it would be done in 6 weeks1 -
First job while in college... Was working for web dev team lamp set up before lamp was lamp (year was 2000).
Had deadline one week after summer vacation. Worked non stop a couple of days to get shit done and didn't make it. Got in a conflict with my manager in front of the team and I blew my steam off. Quit on the spot.
Lessons learned:
1. Don't be a fucking idiot when estimating work.
2. Be cool with other teammates, nobody cares about drama and nobody has to feel sorry for you.
3. Uhm, plan? Had entire fucking vacation to get work done. I was a fucking moron.
4. Burning out is stupid and unproductive.
5. Your manager can be as poor in management as you are. Your job is to try to make them better at it, as they have less visibility in the details.
Next job in grad school. Worked for a security company. Direct manager had the bright idea to make execs sign the change requests. WTF. Code was in Perl/php, a mess. Team rewrote back end DB access , taking over six months, or more, failing twice the deadline. After a final 48 hour burn out, we ship and get laid off the week after.
Lessons learned:
1. Don't work for dicks.
2. Don't be a dick yourself.
3. Don't work for dicks.
Third job was in silicon valley. It was a great company, and I stayed there for five years. -
It's all based on the dev's experience. A beginner always faces trouble estimating a feature/project, but seniors don't, cuz they have the experience to get over the hurdles in software development.1
-
Devs: We've spent some time estimating the stories, and found that we will finish a month too late. Which stories should be removed?
PM: None
Devs: Which are less important?
PM: All are vital. (read: Work harder)1 -
Holy fuck, I though working with Wordpress was a fucking nightmare, but it’s a dream compared to the shit I am estimating maintenance on...
It’s running on Asp.net and the Sitecore cms... I have no fucking clue what the fuck is going on anywhere
I’ve estimated 3-4 days for doing basic maintenance like improving SEO and fix some minor semantics. Everything is wrapped in a fucking <form> element, I mean every fucking thing. It goes;
<body><form method=POST>shit content</form><body>2 -
I'm estimating the cost for a data migration from CA Clipper based system.
I've got to meet the original developer: the most energetic 79 yo man I've ever met - I honestly wish he was my grandfather4 -
Joel Spolsky wrote a great article about estimating the time it will take for dev work: https://joelonsoftware.com/2007/10/...1
-
How realistic is it to expect a single developer to build a site that functions like booking.com or similar online hotel booking system from scratch? Doesn't have to be on par with those popular sites.
Is this something you would be able to do alone?
I got asked about doing it and I haven't responded a clear yes or no. I'm not sure if I'm under estimating the technical difficulty.7 -
The company i work for is getting into scrum. Hired consultants, product owners and scrum masters. First action was 'lets spend 2 days in meetings estimating the rest of the project'.
Agile as fuck3 -
I don't understand how my leads are so bad at estimating time.
"I'll message you in five minutes" = they'll message me in an hour
"Give me ten minutes" = I will sign off for two hours and not respond for another 45 the next time you see me on and message me
Seriously, stop saying things you don't mean. It's rude and insulting.3 -
If I get asked why I didn't complete a task tomorrow I will respond politely with "because we outsource all of our projects, I am fixing shitty bugs resulting from abismal code on 6 different project, merging requests, project managing even though I'm a developer, liaising with clients, writing scopes of works, estimating new projects whilst being the lead dev on 4 projects. Sorry you're right, like everyone else you need this today. I'll get right on that"
-
If i could estimate a schema issue. I looked at this site once in my time here. Don’t know shit about schema’s.
Estimating haha.
Im not asking you an estimate for example building a rocket. Right?
I don’t know this shit. -
Does it count as a learning experience if I have still not yet fully learned it? Then it's estimating tasks.
Fix this bug where the modal is rendered underneath the message-count-badge on your profile? Heh should be easy, 10 mins to set a higher z-index.
Final cost: two weeks, where I needed two status meetings and drawing on the whiteboard to explain why this happens and why it needs a major restructuring.1 -
Always estimating for the best possible, quality solution. I refuse to write anything less than perfect. Also I estimate the time based on how I feel that day lol.7
-
I'm curious about what you guys think of giving percentage updates. Like we have an x project, there are i, j, k things to do and you're asked to give percentage completed on the sub tasks. I feel like we're generally bad at estimating, now you have to consider the weight of each sub-sub tasks and I feel like when you give a percentage update, project managers and clients will eventually ask you "why is the 20% of work not done yet". I feel like it makes the work look a lot easier than it is.8
-
!rant
Finally managed to implement a proper E2E testing solution for our app with Protractor and Jasmine. Some basic tests (login and dashboard) are already working.
I'm just so happy to automate everything, going to cut down our manual testing time from 2h to about 20 to 30min if I'm estimating this correctly.
That's all. Just wanted to say I'm very happy with the results 😊5 -
My process for estimating dev work?
3 hours a day of uninterrupted dev time, 4 days a week (~12 hours a week).
So when I say the project will take 24 hours, it is about two weeks worth of work.2 -
So my non-tech manager has started doing all the estimates for us developers on features upon high management request to save time, because of course rushing all the estimates for the work to be done in the next 6 months is the best process in software engineering.
All the estimates are based on previous work. Sometimes it will be accurate, but most of the time it is absolutely not.
So I get a task estimated to 3 weeks but I planned for 5. Just fit it in 3 weeks.
I planned for 2 weeks but the original estimate is 5. Just fit it in 5.
What kind of crap is that lol? What is the point of us estimating work if management knows apparently better than us how to design systems?
You guys got any similarly shitty project management system?1 -
Estimating a 1 day change as 4 weeks when the scrummaster, product owner & BA haven't bothered to run the simplest dilligence check and can't be arsed to even give a quantitative valuation.1
-
In estimating software development the only certainty you have is that someone will be sad. Or the client or the programmer.1
-
Has anybody experience with Scrum in small web development agencies? Especially estimating stories with story points instead of hours/days?
We have a new junior project manager, without any practical experience working agile, who wants to establish scrum because what he read about it sounded so good... I already worked agile with kanban before and I loved it, but I only have little experience with scrum.
I think scrum, or agile in general, won't work with the clients we have. Most of the time, our clients have a fixed deadline, a fixed budget (either money or time) and they know their requirements, so there is no much room for beeing agile.
Regarding story points, I just adding an unneccessary layer of abstraction, because the customer wants to know how long a specific feature takes. Sure, story points are just another, more dynamic unit for time, but then why nut estimate in static time unit in the first place? Another fear I have, is that some devs may be more ignorant regarding deadlines and expectations on customers side. "yeah I'm working for 10 days on this story, but it's 8 points!" instead of informing the project manager "Currently I spend 2 days on this feature, we estimated 3 days, but it seems I need 3 days more".
Maybe I shouldn't be worried, but it would be great if you could share your experience and learnings. Thanks in advance!14 -
1 - Correct me if I’m wrong, but in true Agile, a product owner ought to be able to interact directly with the dev team, and vice versa, in the card/conversation/confirmation process of creating, estimating, and executing the user stories, correct?
2 - If Company “A” contracts with Consultant “A” to have software developed, and then Consultant “A” then contracts with Company “B” who then contracts with Consultant “B” to do the development, who would you define as the Product Owner?
3 - If Company “B” is barring Consultant “B” from talking with Company “A” and Consultant “B”, is Agile even possible?7 -
Is anyone aware of planning methodologies related to estimating a teams support capacity? I’m getting tired of working on a team that builds more than it can ever possibly support.
-
Heard an interesting idea: along with estimating tasks based on time/points, a dollar value should be placed on it by the product owner, basically how much money they think completing the task would bring in for the company. If this was based off of real data, I could see a lot of tickets being moved back into the back log.
Top Tags
Weekly Rant
View