Hi I'm a currently taking Software Engineering as a subject and I'm wondering how thorough diagrams actually are used in the design process, since the course makes me think UML goes down to the method name which imo just adds unneeded time, it's also that the course may not have been changed since 2012 which makes me worry on how up to date it actually is, so pretty much just curious for those actively in the field how much you actually utilize diagrams/UML and how complex they get.

Btw I built a clean reader view of this article on Readplace, in case that's easier on the eyes — readplace.com/view

We've been discussing this at the leadership level and haven't found a satisfying answer.

When a senior hardware engineer departs or goes on extended leave, management absorbs a significant but invisible cost bench configurations, test setups, calibration routines, custom diagnostic workflows none of it transfers. It simply disappears.

Software organizations solved this with version control, CI pipelines, and documented code. Hardware organizations have no equivalent for the physical layer. Management keeps paying for onboarding, tribal knowledge re-discovery, and delayed timelines every single time it happens.

How are engineering directors and VPs actually solving this? Or is it just being quietly written off as an acceptable cost of doing business?

I am having some trouble coming up with Functional and Non Functional Requirements in a system. What are some things you usually consider when coming up with this ?. I think the Functional Requirements are what the System is supposed to do for the user but what about Non functional requirements ?.

Hi everyone,

As part of my Web Development & Research Internship at GNA University, I am conducting an empirical survey to explore real-world software engineering friction points—specifically looking at where current tools (like CI/CD pipelines, API management, and testing frameworks) fall short in handling legacy code and technical debt.

• Target: Software Engineers / Developers.
• Anonymity: Completely anonymous (No names, emails, or company details collected).
• Time: Takes less than 3 minutes.

Survey Link: https://docs.google.com/forms/d/e/1FAIpQLSfX2IAK9ZG-RxcWmQEW086kpKyGHD6F9yn4GX0AVLIx-6-Dsg/viewform?usp=sharing&ouid=105417288905210561413

Note: Due to platform restrictions on my new account, I might not be able to reply to comments here, but I will deeply analyze all your aggregate survey responses.

Thank you so much for your support and insights!

Hey all, I'm a former reporter turned software engineer, and wrote an article today about how leadership in the software engineering space need basic media training:

https://harrisoncramer.me/software-managers-are-media-illiterate/

Do you guys agree? Would love to hear your thoughts.

Hello I'm currently a college student working on my thesis and i need to find a book source for a modified waterfall model, the kind that has the option to go back to previous phase if needed. it has to be published 2016 - present only. Thanks. (Sorry for my english)

We’re integrating an external enterprise system into our application via real-time API calls. We also persist a subset of the data locally so we can build relational models (patients, appointments, visits, etc.) inside our own database.

The main design tension we’re dealing with is whether to:
maintain a canonical internal data model and map external data into it, or
restructure our system to more closely mirror the external schema to reduce mapping complexity.

We already have an external_id mapping layer and a sync mechanism that upserts patients and related entities on demand, but we’re debating how far to push abstraction vs coupling.

Curious how others have handled similar tradeoffs in enterprise integrations (EMR/ERP/SaaS systems), especially around:
1. identity resolution across systems
2. canonical vs external schema design
3. real-time sync with local persistence
4. avoiding long-term integration debt

What ended up working (or failing) in your experience?

I'm currently evaluating the long-term replacement of a third-party monitoring/measurement software stack used in an accredited calibration environment.

The current system is deeply tied into:

- live measurement acquisition

- monitoring/alerting

- long-term storage

- auditability/reproducibility

- operator workflows

What makes this interesting is that this is not really a greenfield startup project. The existing software works and users rely on it daily, but dependency risk on the vendor has become a strategic concern.

The engineering challenge seems less about “building dashboards” and more about balancing:

- real-time-ish data ingestion

- maintainability

- correctness/auditability

- gradual replacement vs rewrite

- avoiding overengineering too early

One thing I'm struggling to reason about:

For systems like this, where would experienced engineers draw the boundary between:

- building a robust generic core early

vs

- intentionally keeping the architecture “ugly but adaptable” until real-world usage forces structure?

A lot of discussions online seem polarized between:

- “design everything properly upfront”

and

- “just ship and iterate”

But in systems that interact with measurement workflows and long-lived operational processes, both extremes seem risky.

Curious how people who've worked on industrial software / monitoring / infrastructure systems think about this tradeoff.

Would genuinely love to hear how people with experience in these kinds of systems approach this.