Ugly Solutions

[Daryl]

Do you ever find yourself doing a whole bunch of extra programming just to avoid an "ugly solution" that was robust and really had nothing wrong with it, but it just bothered you so much you put in the extra work for something "cleaner"?

Am I even making any sense?

[asbo]

Sure - in Windows API programming, I'll often go through the effort of making a pretty, typedef'd cluster to pass around instead of using an array of bytes. Both work (in most cases), but the cluster is much cleaner.

That what you mean? It's a pretty broad topic

[Mark Balla]

if it's someone else's subvi and all I need is to supply the correct inputs and get the correct output them no I usually leave it alone.

If I am given ownership and responsibility for making The code work then I will refactor it to my liking.

Sometimes it is worth it other times it's not.

One of my biggest fears is being caught in a high pressure situation with clients or operators waiting for me to fix code that I don't fully understand or can't fix easily. So I would say that I tend to do this more often than I need to but it's worth It for my peace of mind.

Mark

[LogMAN]

Of course!!

In many cases it makes sense to take the time you need to develop a

'better' solution (even If your collegues don't agree).

For example if you develop an test application which will be used on multiple

targets and get changed or more advanced over time.

The problem is, generally (In my job) you don't know if it will be used more often

in the future.

However in many cases if you use the 'easy' solution, someday it will kick you

back in the ass (or one of your collegues if you are lucky) and you will ask yourselve

why you didn't use the 'better' solution in the past.

<<-- you know that solution? | You may use this solution! -->>

But which solution is the best?

--> depends on your problem

My experience on this matter is that in many cases you will programm the

'better' solution someday, even if you program the 'easy' solution today.

So just programm the 'better' solution if you get the time.

Please notice:

There is often more than one 'better' solution.

Your solution is the best of course!!!

Greetings, LogMAN

Edited September 15, 2011 by LogMAN

[jgcode]

Do you ever find yourself doing a whole bunch of extra programming just to avoid an "ugly solution" that was robust and really had nothing wrong with it, but it just bothered you so much you put in the extra work for something "cleaner"?

Yes I do sometimes, but I always consider the lifetime of the code/application and what the trade-offs are (e.g. doing it now vs later etc...).

[Cat]

Yeah, when I program around trying not to use locals and globals.

[SteveChandler]

Do you ever find yourself doing a whole bunch of extra programming just to avoid an "ugly solution" that was robust and really had nothing wrong with it, but it just bothered you so much you put in the extra work for something "cleaner"?

Am I even making any sense?

A whole bunch of extra programming IS an ugly solution

Less is more.

But I know what you are asking and am guilty. I can't really give any specific examples right now.

[Daklu]

Do you ever find yourself doing a whole bunch of extra programming just to avoid an "ugly solution" that was robust and really had nothing wrong with it, but it just bothered you so much you put in the extra work for something "cleaner"?

Am I even making any sense?

I understand what you are asking, but a closer examination (triggered by Steve's comment) leads me to conclude your question is meaningless. How so? If there was really "nothing wrong with" the code you would have no desire to change it. The very fact that you made a change means you believe something was wrong with it. (Assuming, of course, your intentions are to improve the code base.) Why do I bother pointing out what appears to be an irrelevant non-issue over the question's semantics? Because underlying your question is an unstated assumption that, in my opinion, is the leading cause of software rot.

"to avoid an "ugly solution" that was robust and really had nothing wrong with it"

This phrase implies functionality is the only thing that matters--as long as the software functions correctly it is good. I disagree. Functionality only relates to the external quality of the software. Professional developers should be just as concerned with the software's internal quality as well. We all know block diagram style plays a huge role in how easy it is to read and understand what is happening. There are other things that contribute to internal quality as well: Choosing descriptive names for sub-vis, creating clean apis for the components, project explorer organization, consistency throughout the application, descriptive comments, application architecture, etc. Most LV developers do reasonably well keeping block diagrams organized, often to the point of obsession. (How frequently do we shift a wire 1 pixel just to fix a bent wire?) Somewhat fewer of them spend much time on the other things I listed.

I think I can boil down your question to this:

Is spending time improving internal quality worthwhile?

Absolutely. Continuous refactoring, one of the principles of agile development, is all about improving internal quality. The trick--and the root of many disagreements between developers--comes in figuring out how much quality is needed. What one dev sees as a quality improvement another dev sees as a waste of time or unnecessary obfuscation.

Less is more.

I know you smilied this comment, but I am compelled to respond to it as if it were a serious response anyway...

Less is not more. Less is just what it says it is... less. Promoting 'less is more' implies we should develop applications with minimalism being our goal. (Minimal what can be debated... minimal # of vis, minimal size, minimal dev time, etc. I'll collectively refer to them all as stuff.) That, imo, is the wrong way to think about it. We should be trying to create the correct amount of stuff to satisfy all the project's requirements, not just the functional requirements.

'Less is more' is a useful reminder when people are in the habit of overdoing something. (Makeup, salting foods, etc.) In my opinion the LV community by and large errs on the side of not enough stuff, not too much stuff.

[jcarmody]

(How frequently do we shift a wire 1 pixel just to fix a bent wire?)

Too often. OCD.