>While this is a much quicker solution in the short term, an engineer will have to context switch out of their work, watch the release go out and make sure nothing goes wrong—that all hurts productivity.
Do you think this has caused a productivity increase? I would guess the additional overhead (unit tests for data files, training sessions for git, engineers doing code reviews, documentation, etc.) would cause more of a time suck.
I do like the idea of letting the stakeholder take care of it themselves on their schedule though without having to code up a GUI. The initial time investment for a GUI usually isn't that bad for us but the added maintenance is a huge PITA.
Take for example a scoreboard with targets on it. The simplest version is to have a dictionary of datetime to target. We would start with that, show the metric owner how to edit it, and let them maintain their targets. Won't need many tests, total time probably 30 mins max to get that solution set up (not including GitHub training, but that's amortized over multiple uses).
The alternative is building a data model, migration, editing interface which is probably at least 2 screens (list, edit) and 3 endpoints (list, modify, delete), needs validation on the input, needs to be put in a menu somewhere, might need a date input library on the frontend, etc.
This solution would probably end up being at least several hours all-in (code review, etc), and this is a simple data model that can easily be put in the database, there are others, with logic for example, that would need a lot more thought to get into the database. For an interface that might be used quarterly for 10 mins, it's not worth it.
Don't forget history, because someone will eventually make a mistake and a finger will need to be pointed :)
In my current org I would still lean on engineers making the config changes, but if we had a group of more tech-savvy stakeholders I could see this being useful. I hope you all post an update down the road on this process.
>While this is a much quicker solution in the short term, an engineer will have to context switch out of their work, watch the release go out and make sure nothing goes wrong—that all hurts productivity.
Do you think this has caused a productivity increase? I would guess the additional overhead (unit tests for data files, training sessions for git, engineers doing code reviews, documentation, etc.) would cause more of a time suck.
I do like the idea of letting the stakeholder take care of it themselves on their schedule though without having to code up a GUI. The initial time investment for a GUI usually isn't that bad for us but the added maintenance is a huge PITA.