I am very susceptible to the ‘Misapplied Genericity’ anti-pattern. When given a problem, my default approach seems to be building a solution which ends up looking more like a framework that allows you then to build the solution in it. For example - if I were creating a metrics dashboard, I would end up building a dashboard builder which I could then create my metrics dashboard in, rather than just ‘hardcoding’ the dashboard I need right now. Something I need to work on!
I do that as well, but I have eventually managed to train myself to do the hard-coded version first, find out I need to make it more generic anyway and thus validate the need for the genericity, but also at that point I have a much better understanding what exactly benefits from being flexible and where I can take some shortcuts compared to what in my mind is the perfect design. That way I end up building something in between which usually works quite well and I am pleased with.
Yup. Early in my career I was susceptible to this as well. Partly immaturity and partly business pressure (we need this thing now, and when the business adapts, we don't want to spend more engineering resources on it! make it work for the future!)
turns out that's nearly impossible, in most cases (businesses change)
I definitely take a more iterative approach now. There's a short spike window to architect the rough plan, get buy in from other engineers, and as long as we feel like we're directionally going the right way and we're not digging ourselves into a corner, we ship it.
Sometimes that has resulted in redoing things (we made a mistake in our thinking), but those redos are minimal compared to the weeks/months we may have spent over-architecting something
I cannot give a yes or no answer in this case. "Generic" is too generic a term, to use it in this argument.
It depends on the whole project and circumstances. Usually I go with specifics and later refactor. The reason is simple: too often did I experience the case, that in order to change something in view, we had to alter the "generic layer". On the other hand, how can you build something generic, when you have not at least 2-3 use cases?
"But we will never refactor" - I am one of the very few, who do just that. I worked my way up from dev to senior manager in order to give people the freedom I always missed.
I feel that the framework for integration is the programming language itself, it's Turing complete.
Getting things to glue together in the right way is a challenge though which is probably why you want it to be data driven. But inevitably you need some flexibility or logic in your data processing so you end up building an expression engine and we get into "creating a inner system/platform effect".
