Requirements vs Delivery - Guide to Programming
This one is a killer and I've received it in multiple forwards in office email, and we always have a good laugh seeing this joke.

Client: “Our next requirement, and this is something big you know, we need an elephant”
IT Team: But why don’t you adjust with a buffalo, even it is big…. and black?”

Client: No, we need an elephant only, let me explain our current process……” (client explains for an hour)
IT Team: Fine, I understand your requirement. But our system supports only a buffalo…

Client:We need only an elephant!
IT Team: Ok, let me see if I can customize it for you”

Requirements are taken as follows:
Client wants a big black four legged animal, long tail, less hair. Having trunk is mandatory. The same was documented, signed off and sent to offshore for development!

At the Offshore Development Centre,

Design/Development – Based on requirement all features are supported in base product (as buffalo), for trunk alone a separate customization is done.

Finally the customization is shown to client:

TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.

I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.

FF to today:

- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"

And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.

!Rant But after seeing this I laughed like hell I need to share this to all my dev folks.

Client: “Our next requirement, we need an elephant”
IT Team: But why don’t you adjust with a buffalo, even it is big…. and black?”

Client: No, we need an elephant only.
IT Team: Fine, I understand your requirement. But our system supports only a buffalo…

Client:We need only an elephant!
IT Team: Ok, let me see if I can customize it for you”

At the Offshore Development Centre :
BA – Client wants a big black four legged animal, long tail, less hair. Having trunk is mandatory. The same was documented, signed off and sent to offshore for development! Based on requirement all features are supported in base product (as buffalo), for trunk alone a separate customization is done.

Finally the customization is shown to client, and the client faints

Addon to this, testers completed their test case as above

So do you still believe in Santa and trunk-based development?

What branching methodology do you use and why? We've been using a trunk based development model, but I'm reviewing others.

Just joined a new company and can only describe the merge process as madness.....is it or am I the one that is mad?!

They have the following branches:

UAT#_Development branch
UAT#_Branch (this kicks of a build to a machine named UAT#)

Each developer has a branch with the # being a number 1 to 6 except 5 which has been reserved for UAT_Testing branch.

They are working on a massive monolith (73 projects), it has direct references to projects with no nuget packages. To build the solution requires building other solutions in a particular order, in short a total fucking mess.

Developer workflow:

Branch from master with a feature or hotfix branch

Make commits to said branch and test manually as there are no automated tests

Push the commits to their UAT#_Development branch, this branch isn't recreated each time and may have differences to all the other UAT#_Development branches.

Once happy create a pull request to merge from UAT#_Development to UAT#_Branch you can approve your own pull request, this kicks off a build and pushes it to a server that is named UAT#.

Developer reviews changes on the UAT# server.

QA team create a UAT/year/month/day branch. Then tell developers to merge their UAT#_branch branches in to the previously created branch, this has to be done in order and that is done through a flurry of emails.

Once all merges are in it then gets pushed to a UAT_Testing branch which kicks off a build, again not a single automated test, and is manually tested by the QA team. If happy they create a release branch named Release/year/month/day and push the changes into it.

A pull request from the release branch is then made to pre-live environment where upon merge a build is kicked off. If that passes testing then a pull request to live is created and the code goes out into production.

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh it's a total mess. I knew when I took on this job it would be a challenge but nothing has prepped me for the scale of the challenge!! My last place it was trunk based development, commit straight to master, build kicks off with automated testing and that just gets pushed through each of the environments, so easy, so simple!

They tell me this all came about because they previously used EntityFramework EDMX models for the database and it caused merge hell.

Using trunk based development for a week now with 3 dev teams... What a relief