Untangling the Knot

[Symbology]

So in the last two weeks I have tried something new. It takes several hours of documentation, but it then allows for virtual planning in my code instead of direct manipulation.

 

In this particular set of problems (aka Tangled Knot) I have been assigned, there are about 60 different calls to the same function with varying input patterns.

 

First I create a spreadsheet listing out all the calling functions and then painstakingly recorded the inputs.

 

Second I color coded the inputs to their sources so that variables coming from the same source class were of the same color.

 

 

Then I could treat the whole problem as a Rubik's Cube (metaphorically) and rearrange the rows and columns in Excel until I found consistent patterns in the calls.

 

Then (for this particular problem) I was able to create wrapper functions that consolidated all the redundant calls. I was also able to rearrange the order of the original function arguments to put the least used optional arguments in the back and also greatly reduce the footprints of the original calls.

 

So using that approach I took out about 400 lines of code.

 

 

I got three lessons out of that:

 

1)

Weeks of coding can save hours of planning

2) That whole Rubik's Cube trick might be pretty useful for other problems - basically tag the categories, and then work with the abstract categories to reduce the apparent complexity of the problem.

Complexity is just a disarrangement of simplicity.

- George Abell

(former UCLA Aerospace Engineering professor)

3) The PFM is in the the ability to hide stuff :phones: that is still there (optional arguments) and still can be used behind the scenes and pulled out at the drop of a hat when desired.

 

3a) There is of course, the alternative:

 

[Pyrotex]

Yes - Thanks Overdog. Would you agree that such things tend to be "meta data" - data about the data. And that it acts metaphorically like scaffolding to hold the once tangled lines apart so that things can move in and out of them?

AHA!! :shrug: You have opened up an amphora of vermicelli, Little Meta-Hopper. :lol:

 

You cannot understand the DATA until you understand the META-DATA. Mdata describes all aspects of the data's organization, key-orientations, value discretions, uniquosities, table relationships, data types, constraints, limits, groups, mortastats, fotticytes and befuddling pins.

 

Mdata doesn't just serve as "scaffolding" to the data, it gives MEANING to the data. To say that the data "wvy035a" is a unique key infuses it with meaning that cannot be gleaned otherwise. Now you have some power over an entire record of data that you did not previously have.

 

And THIS is why we design, build and speak of "databases" -- so that we may wield POWER over the apparently random and meaningless strings of naughts and unities that we use to capture the Past. For this enables us to recall and (indeed) manipulate the Past -- thereby giving us MASTERY OVER THE FUTURE!!!

 

BWAHAHAHAHAHAHAHA!!!!!!!!!!!!!!!!!!!!!!!!!!

[Symbology]

-- Deleted... rewritten in the next entry

[Symbology]

So I have been in this new position for about 4 months now. I have been diligently documenting their enormous network of applications, processes, and their expert system's main code. Their change process alone takes up 8+ hours of overhead per problem record using 5 major change control systems.

 

Most all of it is a complete patchwork. It is a combination of managers not allocating enough time to clean up and redo, as well as some programmers complete lack of interest in the concept of code reuse. So every time I step into a new function, I see yet again another variation of the same ol same ol - (Same S#!% Different Database).

 

One of the scariest aspects is the almost complete lack of use/understanding of Instance level methods. Everything is written as static (class level) methods that have 40-100 lines of code using the same pointer variable. I have begun recoding some of those, and hope that they will serve as a template to follow. But the challenge of training such important Object Oriented concepts to non-CS Majors is a challenge to introduce and still protect egos.

 

To be humble to Superiors is Duty,

to Equals Courtesy,

to Inferiors Nobleness

~ Benjamin Franklin

^ Personally I find the irony of identifying someone as "Inferior" and still being humble in their presence to be a humorous conundrum.

 

 

In one case I got permission to recode 40 function calls. I took out about 400 lines of redundant code in the process. But the culture shock, testing cost, and impact of me not knowing some particular impacts on the code have made it a VERY expensive change (about $10k+ in programmer time).

 

Ultimately I think it will be viewed as worthwhile. But right now it teeters on the "is it worth it" scale for me as well as everyone else.

 

This is about the 5th time I have taken on a major cleanup like this in as many years. And each time I have been more successful, primarily because my ability to document (and therefore explain) has improved each time.

 

On the other side of the lesson fence though - my martial arts and Eastern philosophy study constantly advocate "Letting it go" - "Being willing to live in Chaos", "Roll with the punches" - and of course the all important Star Trek philosophy "Resistance is Futile!"

 

I still remain bound and determined to find the optimal balance point that can still manage to transform a F#@ing Mess of a knot into something that has some appearance of order and consistency.

 

So any positive and/or critical thoughts beyond what has already been offered remain appreciated. :)

[Buffy]

Congratulations on biting off something you could chew without choking! :)

 

Now the trick is to move that little project from the "was it worth it" column into the "thank God he did that" column, which will take a LOT of marketing within the team, most importantly, convincing someone--quite frankly anyone on the team--to lead the meme....

 

Oh, what a tangled web we weave when first we practice to believe, :)

Buffy

[Pyrotex]

So I have been in this new position for about 4 months now.

...So any positive and/or critical thoughts beyond what has already been offered remain appreciated. :shrug:

Yes.

Take care of yourself.

Never work more than 60 hours a week.

Listen to your body.

When it yawns, take a nap.

When it thirsts, drink water.

When it hungers, feed it food worthy of a code warrior.

When it hurts or cannot function at 100%, listen to it.

Keep the mind rested and inspired, or it will not be there for you when you need it most.

Let go all attachments, especially attachments to your own invincibility.

Life is short, so prioritize, prioritize, prioritize.

Enjoy what you are doing--if it becomes burdensome, it is not worth doing.

In the end, when you face eternity, it will not ask you how much code you reused, or what your cost/benefit ratio was, or how smart you were -- it will ask you only two things: have you loved? have you lived in despair?