Writing for
Good
Insights
In Brief
Let’s explore the challenges of maintaining complexity in edtech reporting design, where shared queries can lead to unexpected issues.
Learn how applying the Single Responsibility Principle can help design more robust and maintainable reporting modules in your edtech software.
The Downside of One-Size-Fits-All.
A recurring challenge in our edtech software projects is modifying or adding new features to reporting modules.
These reports were originally designed to re-use common queries across multiple reports; a decision that made perfect sense at the start.
But as years have passed and new requirements have piled up, this approach has made it increasingly difficult to update one report without inadvertently “breaking” others.
The Real-World Problem.
Recently, our client asked us to modify a student list report to add four new columns. Sounds simple, right?. But after reviewing the report’s functionality, I discovered that the query I needed to change was also used by three other reports.
The data for the new columns had to be pulled from a JSONB column and required joining two additional tables to an already complex base query. This would inevitably impact the performance of the three other reports that didn’t need this extra data.
This isn’t a one-off situation.
In that same query, I found that the system was retrieving admin-exclusive data — again, not needed by all reports. The performance impact and the risk of introducing errors due to this coupling were clear.
The original design aimed to follow the DRY (Don’t Repeat Yourself) principle, but not considering other software design principles has come back to bite us.
Clean Architecture
to the Rescue
Uncle Bob on The Single Responsibility Principle
As part of my Connect & Thrive (our professional development program here at Edify), I’ve been reading Clean Architecture, which covers the SOLID principles in its opening chapters. This helped reinforce and even redefine my understanding of these principles—especially the Single Responsibility Principle (SRP).
I used to think of SRP as simply “make methods with only one responsibility.” But the book reframes it as: don’t mix processes that affect different actors (groups of users, departments, etc.) within a single class, method, or component.
“A class should have only one reason to change”
Robert C (Uncle Bob) Martin
American software engineer and author
Clean Architecture principles can significantly improve EdTech reporting design.
This new perspective gave me a clear path forward. I created a new method to handle a query specific to the group of actors I needed to affect: students. I removed columns and tables the report didn’t need and added only the requested ones, avoiding unnecessary performance hits and reducing the risk of breaking other reports.
But the benefits didn’t stop there. Other methods in the report logic had conditionals to differentiate between students and admins. By decoupling this logic and creating actor-specific methods, I could write clearer, more descriptive code. While it might seem like there’s more repeated code, the clarity and maintainability gained by distinguishing between the actors far outweigh the downsides.
A quick Takeaway.
In edtech software, where reporting needs evolve rapidly and different user groups (students, admins, teachers) have unique requirements, it’s tempting to over-optimize for code reuse.
But as this experience shows, respecting the Single Responsibility Principle and designing for clear actor separation can make your codebase more robust, maintainable, and adaptable to change.
The next time you’re tempted to reuse a query or method for multiple actors, ask yourself: are their needs really the same? Or is it time to give each group the attention—and the code—they deserve?