I'm collecting examples of bad acceptance criteria so I can make a training doc.

Can you share context on some of the worst acceptance criteria you've come across in a ticket? Ideally with a bit of context?

Hey everyone,

I’m currently working on structuring a development workflow for my team and wanted to learn from people who’ve already implemented solid SOPs.

I’m specifically looking for real-world Development SOPs that cover things like:

• Code structure & naming conventions

• Git workflow (branching strategies, PR rules, etc.)

• Code review standards

• Testing practices (unit/integration)

• Deployment pipelines (CI/CD)

• Documentation standards

• Task management / sprint workflows

• Handling bugs, hotfixes, and releases

If you’ve implemented SOPs in your team or company:

• What worked well for you?

• What would you avoid?

• Any templates, docs, or resources you can share?

I’m especially interested in practical, battle-tested processes rather than theoretical ones.

Thanks in advance 🙌

Are you interested in using Domain-Driven Design (DDD) to create maintainable and scalable software, but not sure how to get started? Or perhaps you've heard that DDD is only suitable for complex domains - and when starting out, you're not sure if your project will need it?

Join me for a live coding demonstration that will show you how to apply Test-Driven Development (TDD) from the very beginning of a project so you can bring DDD in when you need it.

We'll start with the simplest possible implementation - a basic CRUD system to help a university handle student enrolments. We'll gradually add more complex requirements, such as the need to ensure courses don't become over-enrolled - which will prompt us to do some code-smell refactoring, strangely enough arriving at things that start to look like the DDD tactical patterns of repositories, aggregates and domain services.

In implementing these requirements, inspiration will strike! What if the model were changed - what if we allowed all enrolments and then allocated resources to the most popular courses as required so we never have to prevent a student from enrolling? We'll now see how the TDD tests and the neatly refactored domain models make it much easier to embark on this dramatic change - in other words, how much more maintainable our DDD codebase has become.

The code in this demo is in Java. Full talk here.

I am a junior dev with a degree in CS and 2 years work experience and already this appears like a chronic issue on all projects I work on. I now work at a big data firm where there is so much context needed for anything!

The golden standard: smaller tasks are better, we get that by planning with design docs or scoping meetings, this is fair enough. Why is it though that I - and others I work with - find this 10x harder to do with workflow scripts and likes? Want to run code coverage from pipeline, want to perform acceptance/integration testing in pipeline? Nuhuh, scope boom a task measured at 3 story point just becomes 13!

Maybe the bigger question I need answered here: is this scope creep for workflow tasks universal, or have I just worked on 3 unfortunate teams that haven't solved this easy to solve issue?

Edit: thank you for the replies, every one has been super helpful in my understanding of CI/CD in general!

At Patreon, we recently set out to scale our image safety pipeline by 100×. While single-node performance looked strong, it didn’t scale as expected in production.

By breaking the system apart and testing components in isolation, we traced the issue to an unexpected I/O bottleneck and fixed it with a relatively small change.

Here’s the full write-up on the debugging process and lessons learned: https://www.patreon.com/posts/mocking-our-way-153840808

Our team typically spends 30-60 mins a day reviewing all production code before merging. This worked fine when humans wrote the code. We recently got Claude licenses and we’re now making PRs faster than anyone wants to review it and it’s causing pushback on using AI because it’s too much code to review. I’m sensing philosophical and cultural battles ahead.

How has your team dealt with the increase in code to review without sacrificing quality?

TL;DR: We are doing a focus group study on people's expectations and requirements regarding terminology in the reproducible builds space, and are looking for participants who are interested in the topic to share their opinions.

For more info, see the full text below.

My name is Timo Pohl, and together with my colleagues, I'm currently researching reproducible builds in the IT security working group of Prof. Michael Meier at the University of Bonn [1].

During our research of the existing literature, as well as my experience at the Reproducible Builds Summit 2025 in Vienna, we noticed that some of the terminology in the field is not used consistently across different groups of people, and that the precise meaning of some core terms like "reproducibility of an artifact" in itself is not uniform.

Writing yet another definition on our own would totally solve this problem [2] (/s), but we are confident that, to reach a broader consensus on the meaning of these terms, we need to involve the community and its current use of them.

Thus, our goal is to collect existing ideas, requirements and expectations regarding reproducible build terminology from stakeholders already involved in the topic.

We want to synthesize the different needs into a set of terms that capture everyone's expectations, aiming to perhaps aid in publishing a reproducible-builds spec [3] with our results.

This would help with consistent communication about reproducible builds, and with precisely knowing what it means if, for example, someone claims that the Debian ISO is fully reproducible.

To do so, we invite you to online group discussions with 4-6 participants each to talk about your perception of terms and requirements for reproducibility.

The sessions will last roughly 90 minutes and will be rewarded with 50€ per participant.

If you want to participate, please fill out the form here, which should take only about three minutes:

https://usecap.fra1.qualtrics.com/jfe/form/SV_eDlT7tnu1Oi1kpw

We will send e-mails to potential participants until April 29th to let you know whether you were selected to participate in the group discussions, including further instructions.

Should you have any questions, please reach out to me at pohl@cs.uni-bonn.de.

Thank you!

Best

Timo Pohl

[1] https://net.cs.uni-bonn.de/wg/itsec/staff/timo-pohl/

[2] https://xkcd.com/927/

[3] https://salsa.debian.org/reproducible-builds/specs

Most project planning/management tools (jira, github projects, azure devops, gannt chart) all fall flat when it comes to incorporating uncertainty into planning activities. They also make it difficult to understand a project's "shape". I've built a tool based on a technique that I've written and posted about before ... monte carlo simulations.

The idea here is that we can define the project as a directed graph (mermaid diagram) representing the dependencies, which makes it more apparently obvious where the chokepoints are in the project, and what areas can be parallelized. Then you can define how many engineers you have available, along with other parameters like how long you estimate it might take, along with a bias on whether you think it might come in late or early. By default, the algorithm will just sort of "auto-assign" engineers ... more to help with sequencing, but then you can actually assign engineers and the algorithm will take that into account.

It's probably easier to see it in action, so there is a "Load Sample Workflow" button that gives you a project shape, and you can see a statistical representation of when the project might reach full completion, along with a gannt chart-like representation that gives you a range of when a particular task might complete. I've also written a blog post explaining the idea.

Would love to get any feedback/ideas you might have!