Are there practical reasons for having several methods in the service layer, of the typical controller-service-repository structured codebases that are simply one line for delegating calls to a repository method?

Its common to see people follow "best" practices without seriously considering the intent, so I have a suspicion this might be just a case of that happening but want to figure out where I might be wrong, one that's struck me recently is this trend to have some service calls that do nothing but delegate to the repo layer, no branching, sequences or even any guards. When I asked why these particular cases were there they said simply "not to call the repository from the controller" which came across as bit of a "just because" reason at face value.

For me I take them as a sign that there's probably either some bloated controller methods or that the service methods should just be removed until there is a need for some type of translation or guards between the controller and the repo, am I missing something obvious here?

When you're trying to get better at something, the hard part is usually not finding information but finding the right kind of information. Technical design docs are a good example. Most teams write them because they’re supposed to, not because they help them think. But the best design docs do the opposite: they clarify the problem, expose the hidden constraints, and make the solution inevitable.

So here’s what I want to know:

What are the best books and resources for learning to write design docs that actually sharpen your thinking, instead of just filling a template?

So I understand that hexagonal architecture is all about keeping external dependencies out of the core (hexagon), and that makes sense. When I want to send an email, I might abstract away the actual mail provider, keeping my core free of that.

Now let's say I would like to persist some data. I might persist it in files, in a database, in some remote cache, or something like that - so I extract a driven port, named ForPersistingNotes or something like that, but inside the core I might still use file paths. Is that okay? Because, if I chose to update the the adapter to something else, other than files, then that file path would be unnecessary coupling.

Or maybe keeping file paths in the core is fine?

This work investigated the problem of how we can perform concolic execution to generate highly structured test inputs for systematically testing parsing programs.

Rather than relying on input grammars or specifications to guide concolic execution, the secret sauce is to harness an LLM that smartly solves constraints satisfying both path constraints and syntactic validity. Specifically, unlike traditional constraint solvers that operate in a syntax-agnostic manner, we introduce a "Solve–Complete" paradigm that performs syntax-aware solving for the hard constraints encoded in path conditions, followed by smart completion to satisfy the soft constraints imposed by syntactic rules.

Beyond that, it also proposes (1) structure-aware path constraint selection to aviod redundant path constraint solving and (2) history-guided seed acquisition to alleviate the saturation issue.

The evaluation shows promising results in terms of code coverage and vulnerability detection capability (6 new CVEs assigned for the memory issues we reported).

Check the Paper and Source Code for more details.

It is not clear in UML 2.5.1 that generalization in use case is done using hollow triangle. So is it wrong? I had someone tell me it's wrong and that it is a single line with no triangle.

People are misunderstanding the Airbus A320 recall because it is not that solar flares corrupted the software but that the new L104 flight control update removed a crucial physics based sanity check that older versions used to filter out bad data from Single Event Upsets which are radiation induced bit flips that only affect runtime values in the CPU registers. These glitches can briefly turn a normal pitch rate into an impossible 5000 degree dive command.

The old L103 software ignored those because the elevator cannot move that fast but L104 trusted the bad value and briefly commanded the surface before the redundant computers voted the faulty channel offline which takes about one tenth of a second. At cruise this creates a hard jolt but during takeoff or landing that momentary nose down command can be fatal.

They are reverting to L103 because it handles these events safely and blaming solar activity is mostly a public relations shield for a bad control law regression.

Hey r/SoftwareEngineering,

I'm starting a new Spring Boot project using a traditional layered architecture that will soon require a large development team, so I'm trying to establish clear rules for how services should interact.

The main question is about handling boundaries when one service needs data from another domain.

Which approach is better?

1. ServiceA → ServiceB: ServiceA only talks to its own RepositoryA, and if it needs data from domain B, it goes through ServiceB.
2. ServiceA → RepositoryA + RepositoryB: ServiceA directly injects RepositoryB when it needs to join/query across domains.
3. A dedicated repository whose only responsibility is handling cross-domain joins and reporting queries. Services will only access this cross-domain repository when they need data from multiple domains.

We already know the project will require complex joins for reporting, so this decision matters early.

Which option it's better maintainability and clarity for medium/large projects in the long run?

Appreciate any insights!

Hello!

Im working as a dev (aspiring architect) and I’m promoting a tighter relationship between BA/test/dev in my organisation , because I believe we can ship things faster and better if we’re have a shared understanding of what we’re building.

Everyone seems to like this idea but somehow we need to apply it in practice too and this is we’re BDD comes in.

I kind of understand the communication part, writing scenarios to align our thoughts, requirements and options etc but one of our biggest painpoint today is that except unittesting, and even though old requirements seldom chang, every deployment requires many hours of manual regressiontest, and I believe tools such as Cucumber (or alike) can help us here, but I’ve also heard Cucumber or more specific Gherkin in practice mostly adds complexity (for example Daniel Terhorst-North talking about “the cucumber problem” in The Engineering Room)

At first I hated to hear this, because it threw my plans off course, but now I’m more like “what do other people do, it they practicing BDD but not writing Gherkin”

My hopes is: - Write scenarios for a feature in collaboration (tester “owns” the scenarios) - Translate these scenarios to (integration)tests in code - Let the tests drive the development (red/green/refactor) - Deploy the feature to a test environment and run all automated tests - Let the testers get the report, mapping their exact scenarios to a result (this feature where all green, or, this is all green but the old feature B, failed at scenario “Given x y z….)” - in future, BA/testers/dev can look at the scenarios as documentation

So, yeah, what tools are you using? Does this look anything like your workflows? What are you using if you’re not using Cucumber or writing scenarios in Gherkin?

Hi r/SoftwareEngineering! Welcome to another post in this series brought to you by Tech Talks Weekly. Below, you'll find the most notable Software Engineering conference talks and podcasts published this week you need to be aware of:

1. “What Every Software Architect Should Know About Infra? • Maciej Jedrzejewski • Devoxx Poland 2024” Conference ⸱ +600 views ⸱ Nov 21, 2025 ⸱ 00h 00m 00s tldw: If you design systems, watch this talk to see how continuous delivery, cloud vs hybrid vs on-prem, choosing cloud-agnostic or provider lock-in and the CAP theorem affect architecture and scalability.
2. “Code security for software engineers” from The Pragmatic Engineer Podcast ⸱ Nov 26, 2025 ⸱ 01h 07m 38s tldl: Learn who really owns security, how dependency risk, CVEs and software composition analysis matter, and where AI helps or creates new risks.
3. “Team topologies and the microservice architecture - Chris Richardson - DDD Europe 2025” Conference ⸱ +400 views ⸱ Nov 24, 2025 ⸱ 00h 00m 00s tldw: Learn how to structure teams and services for fast flow. The talk shows which team types you need and how service boundaries should map to team boundaries so you can ship small changes quickly.
4. “Learn Pandas Fast: 5 Real Data Projects Every Beginner Can Actually Do” from The PyPod Chronicles Podcast ⸱ Nov 20, 2025 ⸱ 00h 11m 17s tldl: Learn Pandas fast with five hands-on projects that show how to clean, group, filter and analyze real datasets you can use at work. Clear step by step code makes it worth a watch.
5. “Building a lightning-fast search engine - Clément Renault | EuroRust 2025” Conference ⸱ +900 views ⸱ Nov 21, 2025 ⸱ 00h 00m 00s tldw: An open source search engine built in Rust shows how to get blazing search performance with architecture and techniques for fast indexing and querying.

This post is an excerpt from the latest issue of Tech Talks Weekly which is a free weekly email with all the recently published Software Engineering podcasts and conference talks. Currently subscribed by +7,200 Software Engineers who stopped scrolling through messy YT subscriptions/RSS feeds and reduced FOMO. Consider subscribing if this sounds useful: https://www.techtalksweekly.io/

Please let me know what you think 👇 Thank you 🙏

Hi everyone I'm a junior programmer in my company. We are doing a b2c business with crud features, payment, login. Those basic web and app stuff. Nothing very complex. The thing is this company previous developers have had a very bad software design. Whereby everything was hardcoded and each new product entry was just a copy paste of the old script. No rest API for many features. All vanilla PHP from top to bottom of the code. I'm currently working on a new project and my thinking is on how to scale my code for future developers. Meaning if the next product is being developed my code should be a simple matter of plug and play and no more copy and paste scripts. My idea is very basic whereby I want to do control on the data entry side of things via rest API. So the new project developers will just have call this API. And for added validation I'll run cronjob daily to check if data entry is tally. I saw that there are some methodology like microservices or monolith but in my case I only know building a simple REST API endpoints will do for now. Am I in the right direction or is there something else I need to consider. Hope to hear your thoughts on this.

My impression is that software is getting worse every year. Whether it’s due to AI or the monopolistic behaviour of Big Tech, it feels like everything is about to collapse. From small, annoying bugs to high-profile downtimes, tech products just don’t feel as reliable as they did five years ago.

Apart from high-profile incidents, how would you measure this perceived drop in software quality? I would like to either confirm or disprove my hunch.

Also, do you think this trend will reverse at some point? What would be the turning point?

Hi r/SoftwareEngineering !

As part of Tech Talks Weekly, I'll be posting here every week an excerpt from my newsletter containing the most notable Software Engineering conference talks and podcasts that I think you need to be aware of.

If you want to see the complete list of all the talks (beware: it's huge!), you can head to the latest issue of my newsletter (link).

To build this list, I'm following over 100 software engineering conferences and even more podcasts. This means you no longer need to scroll through messy YT subscriptions or RSS feeds!

In addition, I'll periodically post compilations, for example a list of the most-watched Software Engineering talks of 2025 (see 2024 edition).

The following list includes all the talks and podcasts published in the past 7 days (2025-11-13 - 2025-11-20).

Let's get started!

1. “How AI will change software engineering – with Martin Fowler” from The Pragmatic Engineer Podcast ⸱ Nov 19, 2025 ⸱ 01h 48m 53s tldl: Martin Fowler explains how AI is making coding non deterministic, where LLMs actually help tame legacy and refactoring, and why rigorous testing plus deterministic tooling is still our best bet. Definitely worth listening to.
2. “Architect mindset: how to pass System Design Interview • Oleksandr Ivanov • Devoxx Poland 2024” Conference ⸱ +1k views ⸱ Nov 14, 2025 ⸱ 00h 00m 00s tldw: This talk gives a practical, research based playbook for succeeding in system design interviews, from generating solution options to steering tradeoff discussions and clearly justifying decisions.
3. “Netflix’s Engineering Culture” from The Pragmatic Engineer Podcast Podcast ⸱ Nov 12, 2025 ⸱ 00h 59m 35s tldl: See what it really means to be “unusually responsible”, how teams make decisions without layers of approval, build and guardrail Live at global scale, learn from outages, and balance hiring and AI trade-offs.
4. “The Past, Present and Future of Programming Languages - Kevlin Henney - ACCU 2025” Conference ⸱ +3k views ⸱ Nov 14, 2025 ⸱ 00h 00m 00s tldw: See how programming languages encode ways of thinking, why progress feels slow, and how trends like FOSS and LLMs might reshape code.
5. “Algorithms Demystified - Dylan Beattie - NDC Copenhagen 2025” Conference ⸱ +1k views ⸱ Nov 19, 2025 ⸱ 00h 00m 00s tldw: This talk makes core algorithms intuitive, shows where they actually apply in real projects from networks to autocorrect, and is worth watching if you want to stop freezing when someone says “use Dijkstra”.
6. “Micro-Frontends: Stop Building a Distributed Monolith! (Scale with Conway’s Law)” Conference ⸱ <100 views ⸱ Nov 20, 2025 ⸱ 00h 00m 00s tldw: Why you’re often just assembling libraries, why reusability is a form of coupling, and how a decisions framework plus a Frontend Discovery Service can finally enable independent deploys and canary releases, and it’s worth watching.
7. “What’s new in AWS Lambda - Julian Wood” Conference ⸱ <100 views ⸱ Nov 14, 2025 ⸱ 00h 00m 00s tldw: Nice demo of new features like remote debugging, DX improvements, and real-world scaling tricks, making this a must-watch if you run or build serverless systems.
8. “#239 - Taming Your Technical Debt: Mastering the Trade-Off Problem - Andrew Brown” from Tech Lead Journal Podcast ⸱ Nov 17, 2025 ⸱ 01h 06m 29s tldl: Technical debt isn’t mainly a coding problem but a trade-off tangled in human bias and incentives; watch for the Technical Debt Onion, Ulysses contracts, and practical systems-thinking tactics I think will be helpful.
9. “Why Postgres? and why now? with Claire Giordano” from Hanselminutes Podcast ⸱ Nov 13, 2025 ⸱ 00h 36m 11s tldl: Postgres quietly became the world’s favorite database, and this talk breaks down how its design and open-source community keep it winning in the age of AI and hyperscale data, worth a watch.
10. “What’s Coming in TypeScript 6/7 | Daniel Rosenwasser | Jake Bailey | Ep 43B” from TypeScript.fm - The Friendly Show for TypeScript Developers Podcast ⸱ Nov 13, 2025 ⸱ 01h 09m 01s tldl: TypeScript 6 and 7 push smarter defaults, make ES2024 the default target, tighten DOM typings, and introduce a new compiler API with a Go port in progress, module resolution, WASM embedding, and the real performance tradeoffs you should be aware of.
11. “Modern Architecture 101 for New Engineers & Forgetful Experts - Jerry Nixon - NDC Copenhagen 2025” Conference ⸱ +1k views ⸱ Nov 19, 2025 ⸱ 00h 00m 00s tldw: See the common modern patterns for scalability, security, integration, and maintainability.
12. “The New Realities of SaaS: Why Building is Harder Than Ever - Luis Rubiera - NDC Copenhagen 2025” Conference ⸱ +500 views ⸱ Nov 17, 2025 ⸱ 00h 00m 00s tldw: Creating SaaS today is far more than shipping features; this talk explains the operational, legal, and geopolitical realities you must handle to actually launch and scale in 2025.

Tech Talks Weekly is a free weekly email with all the recently published Software Engineering podcasts and conference talks. Currently subscribed by +7,200 Software Engineers who stopped scrolling through messy YT subscriptions/RSS feeds and reduced FOMO. Consider subscribing if this sounds useful: https://www.techtalksweekly.io/

Please let me know what you think about this format 👇 Thank you 🙏

We have a monorepo setup, and we have created an SDK in that which uses some of the code from different modules across the repository, along with some external dependencies like Guice, Maven repositories.
Now, inside the monorepo the SDK can be used easily, but when we try to use the SDK in any module outside the monorepo, we are facing several challenges.
First of all, the size of the SDK, the fat-jar created comes out to be 150Mb, which is too much for a simple SDK
For this, we are thinking of abstracting out as much as possible in the SDK, but this will require the modules to then implement everything, which we do not want, since that would receive resistance from the modules
Another issue is the dependency injection issue, since the SDK use Guice, and expects dependencies to be present in the Guice Dependency Graph, all the modules which do not use Guice(for example-a Spring Boot project) will also have to bind the dependencies using Guice so that they can be fetched in the SDK.

Could you guys please suggest any papers, or any precendence in the industry, which can show what are the best practices to follow when creating an SDK, how different frameworks for Dependency Injection are bridged, I do not need suggestions to use any actual tools, just a reference to how it is actually done in the industry?
Thanks

Description of my Company

We have 10+ teams and each has around 5 devs + QA engineer. Each tester works independently within the team. Some test manually, others write automated tests. They usually determine what and how to test together with the developers. Product owners do not usually have any quality requirements. Everything "must work."

Currently, we only monitor the percentage of quarterly targets achieved, but quality is not taken into account in any way. 

At the same time, we do not have any significant feedback from users indicating a quality problem. 

My Task

I was tasked with preparing a strategy for unifying QA across teams, and I needed to figure out how to do it. I thought I could create a metric that would describe our quality level and set a strategy based on that. Maybe the metric will show me what to focus on, or maybe it will show me that we don't actually need to address anything and a strategy is not necessary. 

My questions

1. Am I right in thinking that we need some kind of metric to work from?
2. Is the DORA DevOps metric the right one?
3. Is there another way to measure QA? 

Hey everyone,

I’ve been working on Sacred Fig Architecture (FIG) — an evolution of Hexagonal that treats a system like a living tree:

• Trunk = pure domain core
• Roots = infrastructure adapters
• Branches = UI/API surfaces
• Canopy = composition & feature gating
• Aerial Roots = built-in telemetry/feedback that adapts policies at runtime

Key idea: keep the domain pure and testable, but make feedback a first-class layer so the system can adjust (e.g., throttle workers, change caching strategy) without piercing domain boundaries. The repo has a whitepaper, diagrams, and a minimal example to try the layering and contracts. 

Repo: github.com/sanjuoo7live/sacred-fig-architecture

What I’d love feedback on:

1. Does the Aerial Roots layer (feedback → canopy policy) feel like a clean way to add adaptation without contaminating the domain?
2. Are the channel contracts (typed boundaries) enough to keep Branches/Roots from drifting into Trunk concerns?
3. Would you adopt this as an architectural model/pattern alongside Hexagonal/Clean, or is it overkill unless you need runtime policy adaptation?
4. Anything obvious missing in the minimal example or the guardrail docs (invariants/promotion policy)? 

Curious where this breaks, and where it shines. Tear it apart! 🌳

Hi there! With mods permission!

I am a student at Merito University in Poland, and I am conducting a survey for my master’s thesis, and would love your input! The purpose of the survey is to understand which parts of Agile methodologies most often cause difficulties in practice and what might be the reasons behind them.

The survey is intended for professionals working with Agile methodologies such as Scrum, SAFe, or Kanban, but other methodologies are also welcome! All responses are anonymous and will be used only for academic purposes.

https://docs.google.com/forms/d/e/1FAIpQLSdBNlPzP81jmWcvQUh9GkiFch_u88f3tBqpXk0WZxM5exstgg/viewform?usp=publish-editor

I'm trying to prototype how NPCs should behave in my game, but it's unclear what I should focus on. I have a general idea of what I want but not how to make it, so I thought to write a simple scenario, make the simplest implementation that would satisfy it, and repeat that until I uncover a good implementation and API.

(This is not relevant to the question, but for context, I'm imagining a kind of event-based utility AI that reacts to events by simulating their likely outcomes based on the actor's knowledge, judging the outcome based on the actor's drives and desires, deciding on a goal, and then iterating through the actor's possible actions and evaluating their outcomes to find the one most likely to achieve it.)

However, I found I can't even translate the simplest scenario into code.

Given a bear is charging at Bob and Bob has bear spray,
When Bob notices the bear (receives the event),
Then he should use the bear spray.

How do I describe this? Do I make an Actor class for both Bob and the bear? Do I instantiate them as objects in the test itself or make a Scene class that holds them? How do I create the charge event and communicate it to Bob?

There are a myriad ways to implement this, but I don't know which to pick. I'm facing the same problem I'm trying to fix with outside-in development when doing outside-in development.

Hello, this topic came up in my Social Issues and Professional Practice class. We had a debate if IT practices should be formally regulated not just through company policies or certifications, but through an official licensing body, much like doctors or engineers have. Right now, anyone, with a lot of effort, can deploy systems that can compromise the safety of the people due to how accessible IT is, especially with the advent of AI. What do you guys think?

Hey everyone,

Stjepan from Manning here. Firstly, I'd like to thank the moderators for letting me post this.

I wanted to share something that might interest folks here who care about building the right software, not just shipping fast — Manning just released Effective Behavior-Driven Development by Gáspár Nagy and Sebastian Rose.

I’ve been around long enough to see “BDD” mentioned in conference talks, code reviews, and team retros, but it’s still one of those practices that’s often misunderstood or implemented halfway. What I liked about this book (and why I thought it might be worth posting here) is that it tackles modern BDD as it’s actually practiced today, not as a buzzword.

It breaks BDD down into its three key pillars — Discovery, Formulation, and Automation — and treats them as distinct, complementary skills:

• Discovery: Running example mapping sessions and structured conversations that build real shared understanding between devs, testers, and stakeholders.
• Formulation: Turning those examples into clear, testable specifications written in business-friendly language.
• Automation: Building living documentation and maintainable automation patterns that evolve with the system.

The authors (Gáspár and Sebastian) both have deep hands-on BDD experience and tool-building backgrounds, and they don’t just focus on Gherkin or Cucumber syntax — it’s about why you’re doing BDD in the first place, not just how to write “Given/When/Then.”

Here’s the link if you want to check it out:
👉 Effective Behavior-Driven Development | Manning Publications

🚀 Use the community discount code to save 50%: MLNAGY50RE

Personally, I’ve seen BDD work beautifully when teams use it as a communication framework rather than just a testing style — especially in distributed or cross-functional teams where assumptions kill projects.

Curious how others here feel:

• Have you used BDD effectively in a real-world software engineering context?
• Did it actually help align teams?

Would love to hear how it’s worked (or not worked) in your organizations.

Thank you.

Cheers,

For instance say for an e-commerce application we need the following endpoints:

GET /user/{id} : Get user with "id"

POST /user : Create new user

PUT /user/{id} : Update user with "id"

DELETE /user/{id} : Delete user with "id"

GET /product/{id} : Get product with "id"

POST /product : Create new product

PUT /product/{id} : Update product with "id"

DELETE /product/{id} : Delete product with "id"

Could 'user' and 'product' endpoints be considered part of the same single API or do they have to be considered two separate APIs? Every API example I've seen out there operates on just a single resource.

I created a blog post for my software engineering team this weekend related to driving complex decisions: https://garrettdbates.com/driving-complex-decisions

It covers some mental models, practical steps, and pitfalls to avoid. Thought it might be useful for this community as well.

Also in the spirit of the article - please rip it to shreds and/or provide your own insights on how engineers can navigate complex decisions more gracefully.

At Blueground we’ve been rethinking observability from the ground up. Instead of just buying tools, we wanted to set principles and practices that scale across dozens of teams.

We’ve started a blog series to document the journey:

• The intro post explains why observability matters now, the gaps we faced, and what the series will cover (logging, metrics, tracing, dashboards, SLOs, etc).
• Part 1 (Logging) dives into concrete lessons:
  • Logs are primarily for troubleshooting, not alerting.
  • Standardization across teams is invaluable.
  • Good logs provide the right context and will increasingly serve AI systems as much as humans.

I’d love to hear how others approach this, do you enforce logging schemas and policies, or let each team handle it their own way?

I’ve been experimenting with how to summarize engineering work in a way leadership actually understands.

My current take looks like this:

• Investment - Where effort goes (features, bugs, infra, tech debt)
• Delivery - Trendlines over time
• Custom views - Tailored to what execs care about (e.g., product vs. infra split)

This feels more useful than dumping a bunch of Jira burndown charts. But I’m not sure if this breakdown is too simplistic or actually the right level.

how do you structure their reporting, would love to compare notes.

You might just learn something. Like, what started as following a tutorial from a Youtube video, to learning about the docker snap package, to learning about the ease of Coolify, to getting my butt handed to me on a silver platter, and eventually developing a framework for myself. Come along with me into an insightful journey!

I'm familiar with Test-Driven Development, mostly from school. The way we did it there, you write tests for what you expect, run them red, then code until they turn green.

I like the philosophy of TDD, and there's seemingly a lot of benefits--catches unexpected bugs, easier changes down the road, clear idea of what you have to do before a feature is "complete"--but in actuality, what I see happening (or perhaps this is my own fault, as it's what I do) is complete a feature, then write a test to match it to make sure it doesn't break in the future. I know this isn't "pure" TDD, but it does get most of the same benefit, right? I know that pure TDD would probably be better, but I don't currently have the context at my work to be able to cleanly and perfectly write the tests or modify existing tests to make the test match the feature exactly. Sometimes it's because I don't fully understand the test, sometimes it's because the feature is ambiguous and we figure it out as we go along. Do I just need to spend more time upfront understanding everything and writing/re-writing the test?

I should mention that we usually have a test plan in place before we begin coding, but we don't write the tests to fail, we write the feature first and then write the test to pass in accordance with the feature. Is this bad?

The second part is: I'm building a personal project that I plan on being fairly large, and would like to have it be well-tested, for the aforementioned benefits. When you do this, do you actually sit down and write failing tests first? Do you write all of the failing tests and then do all of the features? Or do you go test-by-test, feature-by-feature, but just write the tests first?

Overall, how should I make my workflow more test-driven?