To be clear, every dev must understand and delight their users (including internal stakeholders).
But we also need a better way to empower and serve business teams by letting them control and manage the business logic. Keep in mind, we slow down the business teams if we cannot implement fast enough.
Carrying the mindset that devs must own everything can be harmful and counterproductive. In this case, there seems to be a mutual benefit to both sides. If you don't believe so, let me know.
- use a config library (or write your own) it should read the settings.config from the root home folder.
- This library should also read settings.local.config (or equivalent.) make a git IGNORE rule for the settings.local.config so you would put credentials here and they won't be checked in to the repo.
- This local config should be read and merged into the base config by your config library (deep merge).
- Further, I like to pull additional config from the DB (for user level settings.) the fs is necessary for bootstrapping into the DB, which then may load additional preferences.
- This config format should be whatever you're comfortable with, JSON , YAML, TOML, .py/js, etc. your stack will have its own selection (and behavior) for config libraries.
And now, make sure that config is loaded and made available at the earliest point in code, and everyone can use it EASILY.
You could have this stashed into a user or system cache which your tools can then spy on to see what settings are available whichever place in code.
Settings, access control, preferences, etc. can all fit this format.
By using the git excluded '.local.' layer you can ensure API keys are never checked into git.
* root home folder; that's the application home, one level ABOVE whatever passes for web root. This file should not be accessible to anyone outside of the application.
We’ve done this using Django’s admin portal to let non-technical stakeholders work with database records, and it works well enough. It creates a self-serve scenario for some users, for some kinds of tasks.
The challenge is (as always) finding the right level of abstraction. A premature, wrong abstraction is way worse than making it work by hard coding some logic in the code, or (gasp) just copying and pasting the code a few times, until it’s clear which direction the abstraction is pointing, and at which level it’s operating at.
Like if you start building some generic workflow engine that doesn’t match your actual needs, you’re going to build something that’s clunky to work with, and that it’s hard to backtrack from the design decisions made. It’s better to hard code or duplicate something and remain noncommittal about architecture and design choices until you have clarity.
In practice it’s always a dance. You have to push the boundary to some degree or you’ll never build anything tangible. The usual advice of “just ship something” is not bad here, as shipping a complete failure will be a more information-rich data stream about the right direction than more planning.
I would say there are different "ground truths". For engineers, this is computer science theory, and for business, it's what makes sense from a market perspective and what's best for the customers. This is why having engineers worry about customer needs is a huge mistake, at least in my opinion, because it takes away from engineers focusing on what they do best.
The solution could be something like creating two distinct domains, and then bridging the gap. You would have the engineering domain, in which abstractions follow information theory, and then you would have the business domain, which follows whatever the business wants. Then you would need some kind of bridge, whether it's teams or roles in each team, that translate and mediate back and forth. This way the business can ask for XYZ feature, the bridge teams or roles would then consult with engineers how to break these up, and then engineers would implement it. Additionally, engineers would have complete ownership over their domain.
I think the reason it doesn't work that way, is because the business side wants complete transparency over engineers, which constrains them for no reason. I also think these constrains are impacting the business value in the long run because software isn't being used to its full potential.
But we also need a better way to empower and serve business teams by letting them control and manage the business logic. Keep in mind, we slow down the business teams if we cannot implement fast enough.
Carrying the mindset that devs must own everything can be harmful and counterproductive. In this case, there seems to be a mutual benefit to both sides. If you don't believe so, let me know.