Need help naming an "unmaintainable" VI

[Aristos Queue]

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"? :-)

[hooovahh]

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.

[crossrulz]

Brittle?  Highly Coupled?

[jcarmody]

Paintainable?

[Aristos Queue]

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.

[ShaunR]

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.

[Aristos Queue]

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 October 18, 2017 by Aristos Queue

[ShaunR]

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 October 18, 2017 by ShaunR

[Aristos Queue]

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.

[infinitenothing]

Low resilience code

Fragile?

Edited October 18, 2017 by infinitenothing

[ShaunR]

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 October 18, 2017 by ShaunR

[jacobson]

Maybe rigid or fragile?

 

[JKSH]

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 October 19, 2017 by JKSH

[Mads]

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  
8. High-maintenance VI
9. Costly VI
10. Slow-moving VI
11. Detour-VI
12. Roundabout VI
13. Brick of a VI 

....

 

204. Unpliable VI...

 

[shoneill]

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.

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

[Aristos Queue]

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

[smithd]

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 October 19, 2017 by smithd

[LogMAN]

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

[Jordan Kuehn]

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.

[shoneill]

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.

[Stagg54]

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

[gb119]

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?

[shoneill]

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)