[Tutorial/Workflow/Doc] Optional Additional Principle: Interrogate Constraints Before Accepting Them

[TinasheMTapera]

🧾 Summary

What you’re pointing at is very real—and it shows up all over mature engineering cultures—but it’s usually expressed a bit differently than “assume you’re the only one with the problem.” That framing can actually push people in the wrong direction (reinventing wheels, bypassing governance, or creating fragmentation).

A more grounded principle from computing and research software practice would be:

“Assume the problem has been encountered before; search, validate, and adapt before settling or reinventing.”

This aligns with a few well-established ideas:

1. Don’t accept constraints blindly (but verify them)

Inexperienced users often treat constraints (IT policies, software availability, errors) as fixed. Experienced engineers treat them as:
	•	potentially negotiable
	•	often misunderstood
	•	sometimes already solved elsewhere

But the key is verification, not rebellion.

⸻

2. “Prior art” / “Don’t reinvent the wheel”

A core engineering norm:
	•	Before building or accepting a workaround, look for existing solutions
	•	This includes:
	•	open-source alternatives
	•	lighter-weight tools
	•	different workflows (e.g., CLI vs GUI, remote vs local)

In your QGIS example, the “RSE instinct” is:
	•	Is there a smaller install?
	•	Is there a portable version?
	•	Can I use GDAL/OGR instead?
	•	Can I run it on a remote system (e.g., FASRC) instead of locally?

⸻

3. Satisficing vs. optimizing

From decision theory:
	•	Satisficing = accepting a “good enough” solution quickly
	•	Optimizing = searching for the best solution

Non-technical users often satisfice too early.

Your principle is essentially:

Delay satisficing until you’ve explored the solution space.

⸻

4. Unix philosophy / composability mindset

Instead of one “big approved tool,” experienced users think:
	•	Can I compose smaller tools to achieve the same outcome?
	•	Do I actually need the full application?

This is exactly the counterpoint to “QGIS is large so I’ll just wait.”

⸻

5. Research Software Engineering framing (what you probably want)

For your handbook, I’d suggest something pragmatic and teachable:

⸻

Proposed Principle (Handbook-Ready)

Interrogate constraints before accepting them

When you encounter a limitation (software access, performance, file size, permissions), do not assume it is final.

Before settling for a suboptimal workflow:
	•	Search for existing solutions (documentation, forums, colleagues)
	•	Check for alternative tools or lighter-weight approaches
	•	Consider whether the task can be done differently (e.g., remotely, programmatically, or with smaller components)

Only accept a constraint after you have confirmed:
	•	it is real (not a misunderstanding), and
	•	no better-supported alternative exists within your environment.

⸻

Optional Add-on (very RSE tone)

Prefer adaptation over waiting.
Waiting for access or approval is sometimes necessary, but it should not be the default response when alternatives exist.

⸻

Why this works better than your original idea

Your original idea:

“only settle when you are sure you are the only person facing this issue”

The problem:
	•	Encourages isolation (“maybe it’s just me”)
	•	Misses the key behavior: searching and validating existing knowledge
	•	Doesn’t guide how to act

The revised version:
	•	Encourages discovery + reuse
	•	Fits FAIR principles (reuse, interoperability)
	•	Matches real engineering workflows

⸻

If you want, I can help you turn this into:
	•	a short callout box (like your Quarto style),
	•	a checklist for students,
	•	or a “bad vs good workflow” example (QGIS case is perfect).

🎯 Learning Goals / Outcomes

What should a reader understand or be able to do after following this tutorial/workflow?

• Goal 1
• Goal 2
• Goal 3

📦 Required Tools, Packages, or Data

List any software packages, datasets, or computing platforms used (e.g., R, Python, FASRC, GeoPandas, etc.).

• Tools:
• Libraries:
• Data source(s):

📄 Outline / Structure

Provide a brief outline of the sections or steps in the document:

1. Introduction
2. Setup
3. Key Steps
4. Conclusion / Next Steps

🔗 Related Materials

Link to related GitHub repos, issues, lab protocols, or previous examples:

• example-link-1
• example-link-2

🚦Status & Next Steps

What is the current status?

• Proposal
• In Progress
• Ready for Review
• Completed

Any notes on who will write or review the content?