Every artifact that you create, and then decide to keep, will need to be maintained over time. If you decide to keep seven models, then whenever a change occurs (a new/updated requirement, a new approach is taken by your team, a new technology is adopted, …) you will need to consider the impact of that change on all seven models and then act accordingly. If you decide to keep only three models then you clearly have less work to perform to support the same change, making you more agile because you are traveling lighter. Similarly, the more complex/detailed your models are, the more likely it is that any given change will be harder to accomplish (the individual model is “heavier” and is therefore more of a burden to maintain). Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with stakeholders). Never underestimate the seriousness of this trade-off. Someone trekking across the desert will benefit from a map, a hat, good boots, and a canteen of water they likely won’t make it if they burden themselves with hundreds of gallons of water, a pack full of every piece of survival gear imaginable, and a collection of books about the desert. Similarly, a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.
I tend to apply that Agile Modelling principle to pretty much everything in life. Travel light.
Including TW’s features. If I can do everything I need with a small subset of the features, then I only use that subset that facilitates no sticks in my cognitive wheels and no cognitive wheels in the mud.
When I need to solve a problem that can only be solved by a feature I’ve never needed, then I add that feature to my “go to” toolkit.
BTW:
Some folk see this is a negative for some reason. If you dogmatically insist on using every feature provided to handle every single thing intended to be handled by every specific feature, cool. Whatever floats your boat. Respect, but I don’t care. It is your boat, and you should do everything needed to keep your boat afloat. I have no intention of sinking your boat.
If whatever floats your boat is something that sinks mine, why would you be bothered by me doing whatever is needed to keep my boat afloat?
I’m assuming this is in response to our recent discussion; perhaps that’s presumptuous of me. But if so, this comment again misunderstands what I was saying. It’s no skin off my nose if you don’t want to use the tool that seems to be custom-designed to handle your requirement. I thought it was a shame for your sake that the tool that was written to handle such scenarios is one you’d rather not use. I think it will be difficult to recreate that feature without using JS, which I know you also don’t like. I wish you luck, though, in trying to do so.
I don’t know if we’re in the “can only be solved” category, but I do imagine it will be fairly difficult.
That doesn’t describe very many people I know. It’s certainly not me. I just looked at the 172 filter operators in the core. I found that there are 89 of them that I’ve ever used, and 56 that I use regularly. When I have some time, I investigate others I don’t use in case there’s something that simplifies my work, but I certainly don’t use them just to use them.
You’re looking for a solution to a question. There is a solution that will work for many users. But it won’t work for you. That’s unfortunate. That’s all. “Too bad”, “a shame”, “a pity”, etc. are not expressing any disapproval of you, only noting disappointment in the circumstances.
And to be fair, each of us has our idiosyncratic sense of what feels like our “native language” cognitively and perceptually.
My colleagues are sometimes incredulous that I do not do PowerPoint. They think it’s the obvious presentation tool for anyone giving a lecture or talk, and I’m pretty much allergic to it (and to all of those similar linear presentation tools). I do have reasons of course, but it’s also deeper than reason.
I hope you’re not making fun of his methods. He might just have been using “a small subset of the features… that facilitates no sticks in his cognitive wheels and no cognitive wheels in the mud.”
Hammers have there uses, and Occam’s Razor is a great governing principle. I totally support the argument at the top of this thread to Travel light. I also value those that rigorously apply these principles.
However I have seen many times people prematurely simplifying things or simplification through neglect, ie avoiding the complexity in systems that are complex. I am not saying this is necessarily happening here. Sometimes things are irreducibly complex.
Now I am not simply opining on this, it has being a personal and professional quest to delve into complex systems and extract value without erasing information. So much so I am currently writing a book on this subject - working subtitle “Design and Solutions in the face of complexity and uncertainty”. This is supported by life long interest in Philosophy, Science, Cosmology, Evolution, Chaos/Complexity theory, the human brain and other sciences of the complex.
Now whilst I could assert my cognitive differences I will not, I will just be one of the many diverse contributors here.
Note I accept others will have other approaches, and I respect diverse viewpoints and cognitive needs, and in fact if permitted we can learn from each other and it starts with opinions being contestable, and permitting the ability to “agree to disagree” respectfully.
Well, the advantage here is that all of you have the happy ability to ignore every single one of my posts.
Nobody had the luxury of ignoring the deputy minister. (I thought the guy was awesome; easy because he never needed anything from me. Other than sharing some laughs once in a while.)
Just about BUILDING. Nothing in that code about RUNNING. The subfilter operator DOES NOT apply in this code, which is just showcasing an approach to BUILDING a filter dynamically.