Highlights from my week:

Prod access: Needed it for my last four tickets; just got it approved this week. No longer need it (urgently, anyway). During setup, sysops didn’t sync accounts, and didn’t know how. Left me to figure out the urls on my own. MFA not working.

Work phone: Discovered its MFA is tied to another coworker’s prod credentials. Security just made it work for both instead of fixing it.

My merchant communication ticket: I discovered sysops typo’d my cronjob so my feature hasn’t run since its release, and therefore never alerted merchants. They didn’t want to fix it outside of a standard release. Some yelling convinced them to do it anyway.

AWS ticket: wow I seriously don’t give a crap. Most boring ticket I have ever worked on. Also, the AWS guy said the project might not even be possible, so. Weee, great use of my time.

“Tiny, easy-peasy ticket”: Sounds easy (change a link based on record type). Impossible to test locally, or even view; requires environments I can’t access or deploy to. Specs don’t cover the record type, nor support creating them. Found and patched it anyway.

Completed work: Four of my tickets (two high-priority) have been sitting in code review for over a month now.

Prod release: Release team #2 didn’t release and didn’t bother telling anyone; Release team #1 tried releasing tickets that relied upon it. Good times were had.

QA: Begs for service status page; VP of engineering scoffs at it and says its practically impossible to build. I volunteered. QA cheered; VP ignored me.

Retro: Oops! Scrum master didn’t show up.

Coworker demo: dogshit code that works 1 out of 15 times; didn’t consider UX or user preferences. Today is code-freeze too, so it’s getting released like this. (Feature is using an AI service to rearrange menu options by usage and time of day…)

Micromanager response: “The UX doesn’t matter; our consumers want AI-driven models, and we can say we have delivered on that. It works, and that’s what matters. Good job on delivering!”

Yep.
So, how’s your week going?

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...

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.

- 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.

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.

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.

Do you guys still see the relevance of using code freezing instead of just properly managing versions, repositories and branches in a cyclical manner, given how advanced software practices and tools are supposed to be?

To give some context, the company I work for uses the complete trash project management practice of asking teams to work on a sprint basis, but there is still a quarterly milestone and code freeze to commit to and it's where shit hits the fan.

Development teams rush features at the end of the quarter because they had to commit at the very least to a 6 months in advance planning (lol?) and turns out, not being able to design and investigate properly a feature combined with inflexible timelines has high chances to fail. So in the end, features are half-assed and QA has barely any time to test it out thoroughly. Anyways, by the time QA raises some concerns about a few major bugs, it's already code freeze time. But it's cool, we will just include these bug fixes and some new features in the following patches. Some real good symver, mate!

Of course, it sure does not help that teams stopped using submodules because git is too hard apparently, so we are stuck with +10Gb piece of trash monolithic repository and it's hell to manage, especially when fuckfaces merges untested code on the main branches. I can't blame Devops for ragequitting if they do.

To me, it's just some management bullshit and the whole process, IMO, belongs to fucking trash along with a few project managers... but I could always be wrong given my limited insight.

Anyways, I just wanted to discuss this subject because so far I cannot see code freezing being anything else than an outdated waterfall practice to appease investors and high management on timelines.

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!