0

What is the standard or commonly used terminology used in software engineering circles for this scenario that uses "widgets" and "FFT" as a fictitious concrete example:

I have a software library (let's call that the "widget library") that defines GUI widgets for display and interaction for building user interfaces. During refactoring operations, I discovered that, at some point in time, a developer added a set of functions to compute the Fast Fourier transform of an input signal into that widget library (lets call that the "FFT engine"). This was noticed because during dependency analysis of the widget library, it was found that there were a significant amount of additional dependencies (software artifacts, libraries, functions etc.) required by that FFT engine that led to the widget library being much larger when it is deployed.

Thus, I have already come to the conclusion that said developer added the FFT engine into the widget library in a way that does not "feel right" to me, as it drags in more dependencies than "should be" inside the widget library. But I do not know the "right", "correct", "standard", or "commonly used" terminology to communicate to said future developers, that will maintain the widget library, that including such things as a FFT engine is "bad" other than using touchy feely terminology such as "that's bad", "that's wrong", or "that just doesn't feel right". I would rather use a phrase that reduces the English syntax bloat of this whole question down to one, two, or three words that I can used to just say no to introducing "wrong" dependencies.

So, is there such a succinct, minimal phrasing I can use and that has something standard that has some online reference/citation, such as a link to a Wikipedia page, or other source?

My attempts at finding an answer are:

  1. Low Thematic Congruency: Because of the concept of Thematic Maps?
  2. Thematic Misfits: The FFT engine is not a good fit for the theme in that widgets library.

But I could not find software related websites that use those terminologies, but only advertising and marketing related data science areas.

1
  • To echo Greg Burghardt's comment in a below answer - whatever term or buzzword you decide to use here is unlikely to make any difference. You need to be very specific about the actual problems and consequences. In particular, look at it from a business risk and financial perspective, or from the perspective of users/customers. For example, what impact do all these unnecessary dependencies have on users? And how much time/effort will it take to fix? Being able to quantify it in objective and measurable terms also helps stakeholders decide how to prioritise fixing the problem. Commented May 19 at 14:15

2 Answers 2

5

We usually don't give names to the properties a software component does not have, we give names to the properties it has. Then we might speak about the presence or absence of that property, or the degree of presence or absence.

In this case, we could describe your lib in terms of cohesion. The library you mentioned lacks a certain degree of cohesion, because there are parts which don't belong together.

1
  • 3
    I think this is about as good a term as you'll find. This might be a bit of an X/Y problem. The OP is asking for a term to describe the design problems when they should be describing the design problems. A word or phrase won't convince people that something needs to be restructured, but pointing out design flaws could. Commented May 17 at 21:00
1

There is a common anti pattern of the "helper library" where lots of random functions get thrown together precisely because they don't have any binding concept. They are just reused "helpers" or "managers" or "widgets"

It sounds like this is what you might have here. The bigger helper function is just the one that stands out the most. If your library was called TheGUIEditorControlLibrary you might have a solid reason why only GUI editor controls were in it and not FFTs

Another anti pattern can be putting all your code in a single assembly rather than splitting it up into library assemblies. This is sometimes called "separation by namespace"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.