Jump to content
Aristos Queue

Need help naming an "unmaintainable" VI

Recommended Posts

I'm writing a shipping example for next LV. I have a series of VIs: one shows an incorrect solution, one shows an inefficient solution, one shows an unmaintainable solution, and one shows a good solution.

I'm naming the VIs accordingly. The problem is with "unmaintainable." At several NIWeek presentations, I have described some X as "unmaintainable" and gotten arguments from audience that, "Hey, that's my architecture and I maintain it just fine." And they're right -- it is their architecture, and they are successful with it. When I (or most of the "Room G" presenters) use the term "unmaintainable" we mean "when part A of the code changes, the process to update part B is error prone, either because it is hard work or it is easy work that is easily forgotten."

Is there a better shorthand term that I should/could be using other than "unmaintainable"? In many cases, I can explain what I mean by the term, but in slide titles or -- as today -- in VI names, it would help a lot to have a singular term, without triggering the kickback reaction. Something like "Uneasilymaintainable"? :-)

Share this post


Link to post
Share on other sites

Difficulties with scaling?  Non scale-able?  Less efficient development?  More work in maintaining?  More Error Prone?  I get the issue of the language, but when you mentioned 'unmaintainable' I knew what you were saying so maybe my opinion isn't as important as someone who didn't immediately understand what you were talking about.

Share this post


Link to post
Share on other sites
5 minutes ago, jcarmody said:

Paintainable?

SO TEMPTING. Last I checked, I was a member in good standing with the Illuminati Unseen Templar Knights Of The Oxford English Dictionary, licensed to coin new English terms.

Share this post


Link to post
Share on other sites

Unmaintainable is an amalgam of factors including coupling, architecture, readability and compromises. I fail to see how you would demonstrate that in a succinct way with one VI. Any one on their own is maintainable with effort but as the factors compound the effort required increases exponentially until it is "unmaintainable". That is why many people struggle after the first couple of new feature requests when they grow their software organically.

Share this post


Link to post
Share on other sites

ShaunR: I agree. But within context, the term "unmaintainable" is used (by many presenters and book authors and professors) to describe any pattern of action that contributes to the overall unmaintainability of the system as a whole because that pattern is known to break down at scale. The problem is with the term itself -- it implies an impossibility that is clearly rejectable with a single counterexample. Therefore, I'm looking for a different term of art.

Edited by Aristos Queue

Share this post


Link to post
Share on other sites
16 minutes ago, Aristos Queue said:

ShaunR: I agree. But within context, the term "unmaintainable" is used to describe any pattern of action that contributes to the overall unmaintainability of the system as a whole because that pattern is known to break down at scale. The problem is with the term itself -- it implies an impossibility that is clearly rejectable with a single counterexample. Therefore, I'm looking for a different term of art.

You have answered your own question then 

Quote

because that pattern is known to break down at scale

  Your VI is an example of unscalable but it may well be maintainable for small or even medium sized projects. You just need to quantify the "size" where it becomes a significant factor.

Edited by ShaunR

Share this post


Link to post
Share on other sites
23 minutes ago, ShaunR said:

You have answered your own question then 

  Your VI is an example of unscalable but it may well be maintainable for small or even medium sized projects. You just need to quantify the "size" where it becomes a significant factor.

I'm afraid that "unscalable" runs into the same problem, doesn't it? "Well, I'm at scale X and I keep ours working fine." :-(

I think I need a term that means "harder than it needs to be." That's kind of why I like "paintainable." It implies, "Yes, you can do it this way. It works. You may not even realize how much energy you're exerting keeping it working compared to what you could be spending."

In terms of real words, I'm leaning toward "inefficient". Usually that word is reserved for actual run-time performance of the code, and I hate to muddy it, but it is the term that describes the developer's effort as well.

Share this post


Link to post
Share on other sites
1 hour ago, Aristos Queue said:

I'm afraid that "unscalable" runs into the same problem, doesn't it? "Well, I'm at scale X and I keep ours working fine." :-(

No. Because that is where it "becomes a factor".

Think of it like trying to go faster. Sure you can increase the speed by increasing the power but at some point you get diminishing returns. At 20Km/h you can quadruple your speed with double the power (say). At 200Km/h, if you double the power you get just a couple of Km/h increase. It is not a finite tipping point but a scale of diminishing returns above a certain criteria (when the wind resistance becomes a significant factor, in the analogy). add to that crap tires, out of spec parts and no service history and you maintaining top speed is impossible.

This is why it's difficult to get across in a single VI because once that is added to the other factors the whole system becomes a big black hole of effort when in isolation, pointing to any one aspect may seem fine.

So OK. How about "Diminishing Returns.vi"?

Edited by ShaunR

Share this post


Link to post
Share on other sites
13 hours ago, Aristos Queue said:

When I (or most of the "Room G" presenters) use the term "unmaintainable" we mean "when part A of the code changes, the process to update part B is error prone, either because it is hard work or it is easy work that is easily forgotten."

Is there a better shorthand term that I should/could be using other than "unmaintainable"?

So you want to convey the idea that the code resists/frustrates efforts to maintain and scale it...

I quite like brittle that others have already suggested.

Throwing some more ideas out there:

  • Inflexible
  • Intractable
  • Tangled/Entangled
  • Over-coupled/Excessively coupled
  • Unmodular(?)/Non-modular
  • Restrictive/Constrictive
  • Unbending

Note: The first 2 candidates fit your existing pattern of the "in-" prefix:

  1. Incorrect
  2. Correct, but Inefficient in performance
  3. Efficient in performance, but Inflexible in design

If you have time, I suggest asking at https://english.stackexchange.com/ for "harder than necessary" in the context of designing software. You'd get a lot more eyes and brains there.

Edited by JKSH

Share this post


Link to post
Share on other sites
  1. Rigid VI
  2. Implastic VI
  3. In-elastic VI
  4. Change-resistant VI
  5. Less adaptable / Low-adaptable VI
  6. High-friction VI
  7. Dodo-VI  :D
  8. High-maintenance VI
  9. Costly VI
  10. Slow-moving VI
  11. Detour-VI:blink:
  12. Roundabout VI
  13. Brick of a VI :frusty:

....

 

204. Unpliable VI...

 

:o

Share this post


Link to post
Share on other sites

I like the term viscosity.  But it's not a generally applied term int his area.  Increasing viscosity (resistance to flow) is not a problem until you need to adapt to a new surroundings.

Then I searched for some syntonyms of Viscous and fould "malleable".  Hmm. Sounds familiar. :wub:

Or how about a currently totally underused word in Software Development: "Agile" :P

Share this post


Link to post
Share on other sites

@Mads Inelastic... I like the economic implications. "High maintenance" is right vector, but still implies a particular threshold... and "higher maintenance" sounds weird.

@shoneill I've used "viscous" in the past to describe practices "that resist [data]flow". I'm tempted by it.

"Inelegant" has a good balance of subjective/objective judgement.

"Brittle" does seem like the idea many people keep coming back to. I like its factual aspect (sure, you can use it, you can make it work, but it is still brittle) and the fact that it is not a negation of some other term, which keeps us out of the "which way do you mean for that negation to work?" problem (which is the heart of "unmaintainable").
 

Share this post


Link to post
Share on other sites

Terms like unmaintainable (and, probably more so, the flip side terms of "maintainable", "scalable", etc) bother me because even if they had a meaning, they really mean "code I don't feel like dealing with" (or on the flip side, "this is the style of code I like"). Personally, people who use these terms turn me off to the potentially valid arguments they are making.

Before you respond: yes, I understand this is exactly why you want a new name. 

My main point is that they are not in any way specific, and I don't think this thread can help because you are not specific about how this particular function is more difficult to maintain, or about who you think will have sufficient difficulties with the code to call it "unmaintainable". 

I think the who is especially important because I think all of us have at one point or another done something completely "unmaintainable" but were happy to do it, and happy to "paintain" it, because it solved the problem and was the best we knew. It wasn't all that long ago when I was learning labview and had like 30 boolean control references bundled into an array for dynamic registration and someone said "why dont you just put them in a cluster and get the children"...but I was fine with the 30 stupid controls because it solved my problem and wasn't an important enough part of my code, and I didn't know any better.

Besides the who, there are vectors of difficulties with maintenance. Is it hard because you end up with a bunch of runtime errors (eg the standard argument against variant payload messages)? Is it hard to teach a newbie? Does any change cascade into 37 dependencies? Are you consuming a globally shared resource with many undocumented writers? These are all valid reasons the code might be "unmaintainable" but they are far more specific.

 

tl;dr: I vote paintainable. Thats an awesome word. Already added it to spell check.

Edited by smithd

Share this post


Link to post
Share on other sites

Paintainable is very nice, I like it a lot!

If you want to describe code behavior rather than the impact on the developer, I suggest "Melodramatic Solution".

Share this post


Link to post
Share on other sites

I'm a fan of paintainable as well. In a presentation just toss some quotation marks around it and explain what you mean. The point is instantly conveyed.

Share this post


Link to post
Share on other sites

I recently watched a few Presentations on "Technical debt".  I suppose you could say that bad code is beneficial in itself (assuming it works), but with high interest.  If you don't come back to fix it, eventually it will bankrupt you.

Or if your audience is male-only, the phrase "High maintenance" might work.  I hesitate to add this term because it's often used in a very non-technical way which may offend some.

Share this post


Link to post
Share on other sites

You could call it the jenga or house of cards solution...  It works, but if you want to make changes, you better be careful!!

Share this post


Link to post
Share on other sites

Assuming that "crap" is not a vialbe option, I like "brittle" too. "fragile" to me would imply code that is susceptible to runtime errors as opposed to one that is easily broken by subtle changes in editing. Perhaps "chaotic"in the maths sense might suit?

Share this post


Link to post
Share on other sites

I personally don't like "chaotic" (In a maths sense) because chaos results from incredibly complex physical systems which are complex by definition whereas the code is typically complex by implementation.

IANAM (I am not a Mathematician)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.