Food for thought: "Travel light"

Café
#1

From The Principles of Agile Modeling (AM):

Travel light:

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?

3 Likes
#2

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.

2 Likes
#3

For who is anything a “shame”?

“Oh look, what a shame that Charlie won’t use that operand?”

“Why would it be a shame? Charlie is happier than a dog with two tails.”

For who do you have pity that I’m not using an operand that I’m not interested in ?

You find it a shame that I’m happy doing things the way I’m doing them?

I’m sorry, but that is weird to me. Must be some cultural thing I’m not getting.

EDIT: Weird to me that you would think it, and weird to me that you want to publicly express the thought.

#4

And your response is strange to me.

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.

#5

I do want to offer a minor apology here. I reread the original thread, which I’d picked up only at

That makes a lot of sense for all who like to use the subfilter operator.

I thought you were asking how to do something you couldn’t otherwise do. I now realize that you were trying just to showcase your approach.

That approach isn’t of interest to me, because I do use subfilter, but that doesn’t matter much.

Sorry I misinterpreted your post as a request for help. It was “too bad” because I thought you didn’t have another way to do this.

1 Like
#6

A huge part of joy in life is the journey.

The journey was very joyful.

Joy is subjective, not prescriptive.

Your prescription for joy is not joy to me.

For the same reason I do not want an electric can opener. The old-fashioned manual can opener brings me joy. Because of the journey.

Why on earth would I pick the journey that brings me less joy ?

#7

So I’m guessing you might have fun using just NAND gates to accomplish all that the full set of Boolean operations (not, and, nor, if-then) can do?

It certainly is a fun exercise!

:slight_smile:

#8

No joy there for me.

All of that just reminds me of my computer science “Digital Design” and “Discrete Structures” classes, and I seriously disliked both of them.

A “NOT” in a boolean expression stops me dead in my tracks. There is no greater stick in my wheels than a “NOT”. Total “glitchitis”.

Well, elevator buttons (for the doors) are right up there.

#9

I hear you.

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.

1 Like
#10

At one point in my career, my governmental department’s deputy minister, an engineer by trade, did everything with Microsoft Excel.

It did not matter what it was, it was done with Microsoft Excel.

A memo? Microsoft Excel.

A letter? Microsoft Excel.

If not Microsoft Excel, then a post-it note.

#11

“If all you have is a hammer, everything looks like a nail.” (Maslow’s Hammer)

1 Like
#12

If you could have attached a virtual post-it note to his excel sheet, you would have blown his mind! :slight_smile:

#13

That would have been cruel and unusual punishment inflicted on everybody in that department.

Although it would have been a hoot, the payback would have been a “female dog” of biblical proportions.

#14

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.”

#15

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.

#16

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.)

#17

I shared sample code for dynamically BUILDING a filter.

I did not share code on how to RUN that filter.

From that post, the code:

\define l() =[{!!p
\define r() _🧑}!is[blank]]
\define s() +[sort[]]

<$let f1={{{ [range[1],[12]] +[addprefix<l>] +[addsuffix<r>] [<s>] +[join[ ]] }}}>
''the filter I need:'' <<f1>><br><br>
</$let>

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.