LiveCode Forums.

A 'work around' is a concept that has kept bubbling up round these parts for years,
and, as a philosopher I would like to try to pin down (if possible) exactly what each
of us mean by this (there may be as many definitions as there are users of the term)
as it might be useful in future discussions.

I would like to offer 2 or 3 possible definitions and hope that other contributors come forth and
take part in a healthy discussion.

1. A 'work around' is JUST another way of doing something that does NOT

1.1. slow down work.

1.2. prove arduous or "a pain in the bum" to implement.

2. A 'work around' is a fairly tedious bother that involves writing more complex
code than one might choose to otherwise to effect something that one feels
should be fairly simple to manage.

3. A bit of both.

OBVIOUSLY there is a whole world of difference between #1 and #2,

and I feel that any decision to work within a system (whether a programming language or
anything else) should be determined by considering these points.

For myself, a workaround is a temporary solution to a problem, implemented while looking for a more permanent one. It allows me to continue working until I have time to find a more elegant solution.

The difficulty of implementation doesn't matter, the goal is to produce working code to prevent total blockage.

the goal is to produce working code to prevent total blockage.

The ONLY possible problem re that is that a 'work around' may eventually become
an intrinsic part of of a way of working with a programming language to such an
extent that it blocks other, more efficient ways of effecting what the 'work around'
effects from being implemented.

Oh yes indeed, workarounds are a form of technical debt. We do what we need to get through it day.

If LiveCode, or CSS, or XCode, is whatever else we're using later enhances their tooling to make a workaround obsolete, awesome - I never mind hunting down my flags in my code base to update things no longer relevant.

But I never bank on that. The limitations of CSS selectors drove many of us crazy for years, but they didn't stop us from delivering or put us at any disadvantage over anyone else. I'm super glad we have query-level selectors now, but I understand the process needed to add them and found ways to get things done until they arrived.

At any given time, the only software that exists is software that exists. Plans, hopes, dreams, aspirations - all of only minimal value until they become evident in delivered code.

I waited a long time for HTML's Grid but never held anything back waiting for it, because implementation time was unpredictable. Like everyone else I made do by (ab)using FlexBox, and I was no worse off than anyone else.

Technical debt is real. So real that we account for it as a just part of project management.