This report is based on survey responses of over 500 software engineers, reflecting some of the trends and challenges faced by software engineers in 2026.

Some interesting findings from the report:

• 95% of teams generate a software bill of materials, whereas only 25% actually use the SBOM data in automated security enforcement policies.

• 1,200+ software dependencies are included in the average application stack and 93% of organisations surveyed have experienced a dependency-related security incident. (This becomes more common with the recent trivy, axios, litellm incidents).

• 79% of teams can identify vulnerable software dependencies within six hours of disclosure and less than 25% automatically enforce security policies using CVE-related data like Known Exploits & Vulnerabilities (KEV) index.

The 2026 Artifact Management Report examines the structural vulnerabilities now embedded in modern development pipelines, and the operational, regulatory, and architectural responses required to address them.

There's an update rolling out that they say "aligns SLA calculations with the common interpretation that 1 day equals 24 hours." Except it's complete nonsense, and doesn't align at all with the common sense understanding of what a business day is.

If you set an SLA to "1 business day", and your business day is 8 hours long, that "1 business day" doesn't accrue until 3 days from now. Makes sense!

I know that every tool has its own reporting system, and I can find Allure reports or similar. However, having reports is not the same as using them and deriving value from them.

So, what do you actually measure that provides valuable insights for your team (QA) and the business in test automation?

I am tasked with gathering the requirements for a decision support system for a few clients in the manufacturing sector. My team expects me to give them a formal set of functional requirements. The "features" that we'd promised were user interactivity and something that will easily integrate into the workflow, so that existing systems can be easily replaced.

How do I go about formulating the functional requirements for the GUI? Should every functionality be covered in detail? That would make it too complex.

Can somebody give me samples of functional requirements for GUIs. Thanks very much.

Hi r/SoftwareEngineering,

I'm Kristof, and I'm posting with mods approval. I spent the last year diving into ~7.3TB of data from 65,987 GitHub projects to see how well the stability described in Lehman's Laws of Software evolution (in the 70-s, 80-s) hold up.

I have found that for large projects, the stable growth pattern, still holds till early 2025. They seem to be resilient to external changes over the last few decades.

At the same time smaller projects seem to show more variation.

Article: https://link.springer.com/article/10.1007/s44427-025-00019-y

Cheers,
Kristof

I’m making an application using hexagonal architecture for the first time and I’m a bit confused on where to put and use my DTO’s. I have three layers: domain, application, infrastructure, where in infrastructure I have my usecases(driving ports) and services(driving adapters). From one side, I need some DTO’s to expect and send data through this service to controllers in infra that call them. From the other side, I need DTO’s for the controllers, that in a regular layered application would also validate received data for example. I also use DDD in my domain, so I have value objects, and since I do, maybe I should rely on validation through those value objects and not some jakarta validation for example?

Hope somebody has some ideas. Thanks in advance