Data-driven programs are a type of software that I often see in smaller enterprises. Those companies need to support their day-to-day operations with computers, not the other way around. Every company needs internal tools, and many needed them yesterday.The reason is simple; every company is unique. Because it’s unique, due to its business model, leadership, or employees, it also needs unique tools to help with its day-to-day operations. Those small tools are often simple user interfaces over a database, controlling access to that data. In these cases, you don’t need over-engineered solutions, as long as everyone is informed that the tool will not evolve beyond what it is: a small tool.In real life, this one is tough to explain to non-programmers because they tend to see complex use cases as easy to implement and simple use cases as hard to implement. It’s normal; they just don’t know, and we all don’t know something. In these scenarios, a big part of our job is also to educate people. Advising decision-makers about the differences in quality between a small tool and a large business application. Educating and working with stakeholders makes them aware of the situation and make decisions with you, leading to higher project quality that meets everyone’s expectations. This can also reduce the “it’s not my fault” syndrome from both sides.I’ve found that immersing customers and decision-makers in the decision process and having them follow the development cycle helps them understand the reality behind the programs and helps both sides stay happy and grow more satisfied. Stakeholders not getting what they want is no better than you being super stressed over unreachable deadlines.That said, our educational role does not end with decision-makers. Teaching new tools and techniques to your peers is also a major way to improve your team, peers, and yourself. Explaining concepts is not always as easy as it sounds.Nevertheless, data-driven programs may be hard to avoid, especially if you are working for SMEs, so try to get the best out of it. Nowadays, with low-code and no-code solutions and all the open-source libraries, you might be able to save yourself a lot of this kind of trouble, but maybe not all.
Remember that someday, someone must maintain those small tools. Think of that person as you, and think about how you’d like some guidelines or documentation to help you. I’m not saying to over-document projects, as documentation often gets out of sync with the code and becomes more of a problem than a solution. However, a simple README.md file at the project’s root explaining how to build and run the program and some general guidelines could be beneficial. Always think about documentation as if you were the one reading it. Most people don’t like to spend hours reading documentation to understand something simple, so keep it simple.
When building a façade over a database, you want to keep it simple. Also, you should make it clear that it should not evolve past that role. One way to build this would be to use EF Core as your data layer and scaffold an MVC application as your presentation layer, shielding your database. You can use the built-in ASP.NET Core authentication and authorization mechanism if you need access control. You can then choose role-based or policy-based access control or any other way that makes sense for your tool and allows you to control access to the data the way you need to.
Keeping it simple should help you build more tools in less time, making everyone happy.
