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
Search - "feature freeze"
-
So I'm working on an CLI right now that fetches data from a website and downloads other stuff based on that data etc bla bla. And since its async it can fully taste my whole internet speed (130Mb/s).
So everything's good and I started working on a new feature. I started the app and it worked... For 3 minutes. After that it just stopped. It didn't even freeze or anything. After 2 hours of debugging and 3 cans of coffee I was so frustrated I just wanted to watch some YouTube and relax. That's the moment I realized I didn't even have internet. I hate my ISP...4 -
Part two of: a day off an iOS developer life:
1. App crashed and stack trace gives no info in which file it happened, I have a generic table view cell that is used in so many places and Xcode just wrote: xcell does not support key value.
2. Mac freezing when Xcode is creating IPA file thanks to a new feature in Xcode 9 (Mac freezing is the new feature, even mouse pointer doesn't move -.-)
3. Let's check the value of this class property, Xcode: fuck off and either print it in console (after hitting a break point) or expand that shitty tree at the bottom to reach your class property!
An advice: never click jump to definition when Xcode is indexing, it will either freezing Xcode or crash it.
Part 1 link: https://devrant.com/rants/1137208/...1 -
What is your least favorite Website "feature" ?
Mine is those off page menus that slide in from the side. They lag like crazy and freeze the entire site. God forbid if click the menu button more than once. Forbes places comments on the off page sidebar which is just pure hell.5 -
- Implemented oauth1 - no body hashing
- URL contains credentials in plain text
- Used Azure API management feature as a proxy of the our API, however the documentation was on the our API, thus exposing the API URL with no management to developers.
- easy resource DDoSing because each trial user got a DB, the registration process did not have bot checks. You could literally freeze the db instance by spamming registration requests. -
A tale of silos, pivots, and mismanagement.
Background: Our consultancy has been working with this client for over a year now. It started with some of our back-end devs working on the API.
We are in Canada. The client is located in the US. There are two other teams in Canada. The client has an overseas company contracted to do the front-end of the app. And at the time we started, there was a 'UX consultancy' also in the US.
I joined the project several months in to replace the then-defunct UX company. I was the only UX consultant on the project at that time. I was also to build out a functional front-end 'prototype' (Vue/Scss) ahead of the other teams so that we could begin tying the fractured arms of the product together.
At this point there was a partial spec for the back-end, a somewhat architected API, a loose idea of a basic front-end, and a smattering of ideas, concepts, sketches, and horrific wireframes scattered about various places online.
At this point we had:
One back-end
One front-end
One functional prototype
One back-end Jira board
One front-end Jira board
No task-management for UX
You might get where this is going...
None of the teams had shared meetings. None of the team leads spoke to each other. Each team had their own terms, their own trajectory, and their own goals.
Just as our team started pushing for more alignment, and we began having shared meetings, the client decided to pivot the product in another direction.
Now we had:
One back-end
One original front-end
One first-pivot front-end
Two functional prototypes
One front-end Jira board
One back-end Jira board
No worries. We're professionals. We do this all the time. We rolled with it and we shifted focus to a new direction, with the same goals in mind internally to keep things aligned and moving along.
Slowly, the client hired managers to start leading everything in the same direction. Things started to look up. The back-end team and the product and UX teams started aligning goals and working toward the same objectives.
Then the client shifted directions again. This time bigger. More 'verticals'. I was to leave the previous 'prototypes' behind, and feature-freeze them to work on the new direction.
One back-end
One conceptual 'new' back-end
One original front-end
One first-pivot front-end
One 'all verticals' front-end
One functional prototype
One back-end Jira board
One front-end Jira board
One product Jira board
One UX Jira board
Meanwhile, the back-end team, the front-end team overseas, all kept moving in the previously agreed-upon direction.
At this stage, probably 6 months in, the 'prototypes' were much less proper 'prototypes' but actually just full apps (with a stubbed back-end since I was never given permission or support to access the actual back-end).
The state of things today:
Back to one back-end
One original front-end
One first-pivot front-end
One 'all verticals' front-end
One 'working' front-end
One 'QA' front-end
One 'demo' front-end
One functional prototype
One back-end Jira board
Two front-end Jira boards
One current product Jira board
One future product Jira board
One current UX Jira board
One future UX Jira board
One QA Jira board
I report to approximately 4 people remotely (depending on the task or the week).
There are three representatives from 'product' who dictate features and priorities (they often do not align).
I still maintain the 'prototype' to this day. The front-end team does not have access to the code of this 'prototype' (the clients' request). The client's QA team does not test against the 'prototype'.
The demos of the front-end version of the product include peanut-gallery design-by-committee 'bug call-outs', feature requests, and scope creep by attendees in the dozens from all manner of teams and directors.4 -
So today we had a pre-sprint-planning meeting where the POs told us about the stories currently in the backlog. They went ahead and "roughly prioritised" some of them. Their priorities were:
- normal (but asap please)
- has to be done this sprint, because the feature has to be in the next release (code freeze after this sprint)
- top priority, because this has to be in the previous release (which was released last friday)
The non-normal stories alone are about twice our normal velocity. Good job guys. Good job. -
It would seem that "code freeze" has become a meaningless term to our systems engineering team. Sure we can sneak in another feature or eight that you felt it beneath you to negotiate on time. That you couldn't make the decision on until now, even though your job is to make these decisions so that we can stay on schedule. This is why systems is a fucking year behind.2
-
Manager: Oh, this feature freeze you where talking about was no joke?
Me: Yes, that's why we have written it into the protocol of the Last Meeting and everyone agreed...
Manager: Thats nonsense, add more Features!