Reply to: Anyone else have to spend hours reviewing "pull requests"?

[Hobosapien]

If Microsoft can't get it right, then why should we. Carry on pushing crap out to users, they're getting used to it.

On the plus side, those of use with a modicum of quality can rise to the top like a liferaft on a cesspool.

[BR14]

reading this, i'm rather glad the hardest thing i had to do was get applications teams <usually on a weekend> to sign off that their krap still worked after we'd redesigned the platform it was running on

[vwdan]

And add the 'savings' that the Cloud will bring.

Oh how I laughed on my first day...

"We want to go cloud"
"Certainly, sir - he's what you'll be looking at"
"Oh...well, maybe not for everything"

And seriously, I've been doing a lot of Azure work and I'm rinsing through crash just doing test/dev. It adds up so so quickly, and woe betide you accidentally leave a machine or two running - ouch.

[cojak]

If this is happening then the business has no clue about how to implement agile development properly or what user stories are supposed to be.

User stories are not supposed to be fully formed use cases with an exhaustive list of implementation detail and acceptance criteria. Certainly not at the initial planning stage.

A user story should be a fairly high level overview of a feature - the best way I've heard it described is a "promise of a conversation". User stories should be groomed and discussed between the business and developers during release and sprint planning. The first thing a developer should be doing when they pick up a new user story - unless its really straightforward - is talking to the business owner of that story directly. The owner may be a BA/customer proxy, it may be an actual end user, but the important thing is to have the conversation. The customer can help clear up any misunderstandings a developer might have. Sometimes a developer may have better suggestions for how something should be implemented than the customer. The end result of the conversation should be an agreed approach and acceptance criteria.

Completely get that CP, and not everything needs a Use Case. The sad thing is that Use Cases have been completed dumped, so I'm not sure where Business Rules end up. (I'D be ok if Epics/Users Stories were used but the backlog resembles a stream of consciousness rather than structured requirements*).


I still train any junior BA in Use Cases, but let them know they may never use them. UC's are there if they need them rather than re-invent the wheel.

*I know that users stories aren't requirements, but that's another thread and I don't have the energy for it atm...

[cojak]

Agile doesn't really work without tools like git. The key is that feature development can work in parallel with Testing/QA/Bug-fix etc. This sucks in a whole load of other tooling to make it all manageable.

I'm currently doing a consultancy where I'm evangelising all this agile+dev/ops+CI/CD stuff. It's going down a storm with devs and middle-management but the finance director wants me dead.

And add the 'savings' that the Cloud will bring.

Oh how I laughed on my first day...

[cojak]

Can't see it on here:

This has quietly died a death in current client - it was big this time last year but most of 2018 was spent realising how unwieldly (and don't say it loudly) slow it was making the sodding thing work

[Hobosapien]

To do the job well there should always be time for testing.

Unit testing by the developer before committing changes. Sometimes this isn't possible in complex systems where a good enough local development environment for initial testing within is unfeasible, so then integration testing in a shared DEV environment should catch the major bugs before it gets released beyond DEV for functional testing by dedicated testers not the developers and on to UAT where the customer is involved in signing off their own testing.

You can wrap the above in whatever development methodology bollox is in fashion.

[woohoo]

That's madness - The bug may be quickly fixable, but what about its consequences, in corrupt or even lost data, and company reputation (if the software is customer facing)?

Maybe permanent data isn't always an important consideration in certain apps, such as online games. But it sounds like your agile team will come a big cropper before long

I agree. It’s managable when making lots of small changes and pushing often. But when you work on anything that is substantial it’s a right pain.

Yep and there is the danger you introduce a subtle bug that you find a month down the line and it’s caused corruptions.

[d000hg]

There's a school of thought that pull requests and indeed branching, are anti-patterns. One of the core practices of continuous development is "trunk based development". In order for this to work it requires a lot of discipline, real-time code review (including pairing), a strong test suite (from unit tests right up to automated acceptance tests).

I think its an interesting idea, I agree with a lot of the principles - , but also think it would be hard to implement in a lot of teams:
Trunk Based Development

The compromise version of TBD is to only have very short-lived branches (less than a day) and use the Github pull request model for code reviews before merging.

One huge benefit of branching to me is that I can check in my code and know it's safely backed up, without causing anyone else headaches. I can have all the benefit of version history AKA "it worked yesterday WTF did I change?" without having to commit WIP to trunk/master.

My preference is feature-branches (basically the GitHub workflow) which tend to be short-lived but might not be... the other benefit being the coder is responsible for keeping their branch compatible with trunk/master.

The huge benefit of DVCS to me is not that it's distributed - I couldn't care less for commercial code - but that branching and merging actually works. Remember trying to merge in tools like Perforce and VSS that insisted no deliberately misunderstanding your changes so putting code inside a

{ ... }

block made it decide every line was now different?

[suityou01]

If this is happening then the business has no clue <snip/>

Yup

[NigelJK]

Always preferred a gated check in and preferably configurable once you have confidence in the coder(s).

[TheCyclingProgrammer]

DVCS is nothing to do with Agile, it's just far better.

What is your preference, just people randomly committing un-tested code to the master branch? Pretty sure the big boys have been using the equivalent of pull-requests for decades, long before Git. I remember reading an article on MS' custom version of Perforce for Windows builds.

There's a school of thought that pull requests and indeed branching, are anti-patterns. One of the core practices of continuous development is "trunk based development". In order for this to work it requires a lot of discipline, real-time code review (including pairing), a strong test suite (from unit tests right up to automated acceptance tests).

I think its an interesting idea, I agree with a lot of the principles - , but also think it would be hard to implement in a lot of teams:
Trunk Based Development

The compromise version of TBD is to only have very short-lived branches (less than a day) and use the Github pull request model for code reviews before merging.

[TheCyclingProgrammer]

What has happened is that the developers are now completely isolated from the business, the business write user stories which get pumped into JIRA and off we go.

If this is happening then the business has no clue about how to implement agile development properly or what user stories are supposed to be.

User stories are not supposed to be fully formed use cases with an exhaustive list of implementation detail and acceptance criteria. Certainly not at the initial planning stage.

A user story should be a fairly high level overview of a feature - the best way I've heard it described is a "promise of a conversation". User stories should be groomed and discussed between the business and developers during release and sprint planning. The first thing a developer should be doing when they pick up a new user story - unless its really straightforward - is talking to the business owner of that story directly. The owner may be a BA/customer proxy, it may be an actual end user, but the important thing is to have the conversation. The customer can help clear up any misunderstandings a developer might have. Sometimes a developer may have better suggestions for how something should be implemented than the customer. The end result of the conversation should be an agreed approach and acceptance criteria.

[d000hg]

DVCS is nothing to do with Agile, it's just far better.

What is your preference, just people randomly committing un-tested code to the master branch? Pretty sure the big boys have been using the equivalent of pull-requests for decades, long before Git. I remember reading an article on MS' custom version of Perforce for Windows builds.

[suityou01]

That's madness - The bug may be quickly fixable, but what about its consequences, in corrupt or even lost data, and company reputation (if the software is customer facing)?

Maybe permanent data isn't always an important consideration in certain apps, such as online games. But it sounds like your agile team will come a big cropper before long

You are a dinosaur Owlie, this is a new fad called "Devoops".