Untangling the Knot

[Buffy]

Originally Posted by LaurieAG

...but we must admit that things aren't perfect everywhere and somebody has to come along afterwards and clean up the crap when it hits the fan.

Well, even at places like mine where I get to pretty much run the show, its hardly perfect!

In my case, the first version of the system was written by a bunch of typical "web developers": they knew how to "script" but the concept of modular code, or coding for supportability were alien concepts (that's why we're in the middle of our 3rd rewrite!).

Originally Posted by LaurieAG

So any suggestions about Symbologies repeating problems?

If you take Symb's bullets above:

Originally Posted by Symbology

• Do I just "Git 'er done" and mash in my changes....
• Do I spend the time to (sometimes document and) clean up the other pages that I had nothing to do with...
• Or do I gut the whole system and put in a centralized set of functions, web pages, and/or procedures where changes can be made in one central place?

The answer--really between the lines of Pyro's and my posts--is "yes."

The specialist sees these options as mutually exclusive: the generalist sees them as pieces of the only practical solution.

Obviously you can't carry all three to their logical--but in reality absurd--extremes. Its essential to see the fact that hacking, clean-up, and rewriting each are a piece of the solution, and the cleverness is not in the coding but in balancing the approaches to not just maximize the value of your time, but to make it *look* to the outside observers that you're doing them a huge favor in getting them out of the mess the previous gang of idiots got them into.

Forget about what the "perfect" approach is, realize its all about communications, alignment of goals and getting people to understand what they're really getting for their money.

This isn't about strictly following some ideal, its about making sausage, and its never pretty, but it sure can taste good with the right combination of "perfection" and "git'r'done," and remembering that those silly garnishes make the difference between fast food and haute cuisine.

Art is never finished, only abandoned,
Buffy

[LaurieAG]

There are other options Symbology.

Alternatively you could do a cost/benefit analysis of all of the available options (there's probably still many more) including the current status quo (just doing things in an ad hoc manner). Work out an estimate of all costs to date (pick a suitable time span, 1-5 years or however long) fixing things under the current process and then project these expenses into the future including a percentage increment each year. Do the same for each potential solution.

Once you have justifiable figures on current/projected costs, which are hopefully much more than at least one of your (palatable) solutions, you will know which path to proceed along with management. If it can save money the option will be listened to. I hope this helps.

[Symbology]

Originally Posted by LaurieAG

There are other options Symbology.

Alternatively you could do a cost/benefit analysis of all of the available options (there's probably still many more) including the current status quo (just doing things in an ad hoc manner). Work out an estimate of all costs to date (pick a suitable time span, 1-5 years or however long) fixing things under the current process and then project these expenses into the future including a percentage increment each year. Do the same for each potential solution.

Once you have justifiable figures on current/projected costs, which are hopefully much more than at least one of your (palatable) solutions, you will know which path to proceed along with management. If it can save money the option will be listened to. I hope this helps.

I figured the correct answer would involve more work for me. And that is ok. Like I said it seems to come down to us to properly "edumacate" our managers and fellow team mates. Creating the cost/benefit analysis requires the time to put some concrete estimates on (some ridiculous) things. But that then lets the authors of the ridiculous things see that they are... well... ridiculous.

So thank you. That makes good sense. And I think I would rather spend some personal hours working up the cost benefit analysis and keep the decisions above the table, than instead coding after hours and sneaking in the changes - and deal with the fall out of resentment from programmers having their code replaced, and "I didn't tell you do do that" from the managers, and any blame for reworked code that isn't perfect the first time.

Of course then the hazard is they may still decide to cram it all in there, and that there isn't time to do the reworks (typically the opinion). But then I can let it go that I clearly warned them in writing.

I'm looking forward to finding the utopian job where none of this is an issue, and everyone believes that doing things right the first time is the most important thing.

[LaurieAG]

Originally Posted by Symbology

I'm looking forward to finding the utopian job where none of this is an issue, and everyone believes that doing things right the first time is the most important thing.

Don't forget to do the analysis on this option too, you never know.

[TheBigDog]

If everything were done right the first time there would be no place for innovation or improvement. I have no problem with redoing things so they are better. I know that I do the best I can with what I am given for each project, and I know that it will be replaced down the line by someone who may well think I was a fool.

Bill

[Pyrotex]

Some of the valuable lessons I have learned on the job:

1. Learn to write well, and express a coherent thought persuasively -- on paper. People are far more likely to follow you if they understand you.
2. Learn how to use a graphics application (like Canvas) to draw the kinds of diagrams that are worth at least 1,000 words. Suddenly, two hour meetings become 30-minute meetings. Any programmer who can draw intelligent diagrams automatically becomes a lead programmer.
3. Learn the Ladder of Abstraction!! If the only way you know to explain what you did is to give a blow-by-blow description of the sequence of all the individual actions you performed, then I'm talking to YOU. You need to rise above the "sea of details" and be able to describe software, requirements, problems and schedules at an appropriate level of understanding that fits your audience and the time available. So you can give the 1-sentence answer, the 1-page answer, the 15-minute summary, and the 1-hour detailed presentation (all to the same question) -- without bogging your listeners down in petty minutiae.
3a. If while giving a listener an explanation of your software, you see his/her eyes start to flicker shut, you are at too low a level of abstraction. Go up one rung.
3b. Learn to listen to yourself talk while you are speaking.
4. Prioritize functionality! Code the most important features FIRST. Bells and whistles have to wait.
5. Show the programmers a DESIGN before they get caught up in the coding. By definition, a "DESIGN" is on paper. If it's in your head, it is NOT a DESIGN -- it's just an idea.
6. Design your interfaces with utmost care. That way, a poor programmer might produce poor code that can be "isolated" from the rest. As long as the ONLY contact his code has with the rest of the system is, say, four well-defined integers, then unintended consequences can be kept to a minimum.
7. Design the User Interface FIRST!! Write a 10-page User's Guide before the first line of code has been generated. Whoever circulates the first clear User's Guide, controls the design of the system.
8. Design the database SECOND.
9. Learn to perform at least a basic Cost/Function/Risk trade study.
10. Be generous. Give away all your secrets! Give away all your experience! Hold nothing back.

[Pyrotex]

Originally Posted by TheBigDog

If everything were done right the first time there would be no place for innovation or improvement. I have no problem with redoing things so they are better. ...

Well, there's "right" and then there's "RIGHT". One is a reflection of functionality, and the other is a reflection of quality.

In the sense of correct functionality, everything MUST be done right the first time, or the project fails. A compiler that produces execution aborts, or a database that becomes corrupted through normal use, is worthless. Projects that depend on such as these, are in grave peril.

Everything should be "right" in that regard. But you may still have a minimum solution on your hands, one that is difficult and cranky to use. Consider the original IBM job control language (JCL). It drove ordinary programmers insane--they quit their jobs and took up water colors and knitting. And yet, it performed exactly as required--it controlled the execution of everyone's jobs exactly as they requested. It wasn't IBM/JCL's fault if people did not know what they were requesting.

It is in the arena of being "RIGHT" (quality, performance, flexibility, efficiency) that TheBigDog is correct. We can't always afford to get it RIGHT the first time. We seldom know what RIGHT even is, the first time around. As with JCLs, it took 20 years of experience and innovation to understand what an operating system OUGHT to be doing, and how we should be conversing with it.

A database MUST be "right" the first time or you're screwed. But there is plenty of time afterwards for you and your descendents to make it RIGHTER and RIGHTER and RIGHTER.

[Symbology]

Originally Posted by Buffy

Forget about what the "perfect" approach is, realize its all about communications, alignment of goals and getting people to understand what they're really getting for their money.

By the way Buffy... could you give a concrete example or two of this? For example a case where you worded it the right way so that they "got it".

Thanks,
Symbology

[Symbology]

Here are a few thoughts from today's discussion between Pyro and myself:

The reason why we can untangle knots in algebra is because we have the equal sign to move things across.

• If something gets in the way of what we are working on, we just move it to the other side of the equation.
• Once something is isolated we can perform transformations on it.

Paraphrasing an earlier point made by Pyro: The difference between a genius and a wizard is that once a genius explains what he did, everyone goes "oohhh, I get it!" After a Wizard explains what he did, everyone is still left in amazement.

To my observations, illusionists are very good at hiding things "on the other side" just like we do on the other side of the equal sign in algebra. Just consider the equal sign the magic hat or the curtain. Similarly in computer science we use "tricks" like hashing to make a data entry disappear into the ether and reappear at will.

By getting obstructions out of the way, we can focus on the task at hand until we have solved that particular tangle or issue.

Following that metaphor relative to the start of this discussion, I have seen managers perform magic in getting obstacles out of the way so that the programmers can focus on the issue at hand.

To my experience the main way I have been able to accomplish it myself has been with documentation (as Pyro gave in his excellent list), and coding frameworks. The frameworks can hold partial or incomplete aspects in place, until such time as they can be completed or replaced with solid components.

I think it is these frameworks (often in the form of meta data about the original application) that may be the main tools which can be used to untangle the knots. Per Pyro's link to Layers of Abstraction: If a rule works at one layer, it is not normally going to work at another layer. I would say this is generally correct. But using functions we can usually abstract a collection of "cattle" and rewrite the function for "livestock" instead using proper meta data.

The cattle owners tend to get upset when I tell them I have a module that can be used for both cattle, sheep, and goats. But if I am just counting heads of livestock and running them into a chute, it's the same process. I just point it at a herd and let 'er rip! (By the way I would equate that chute with the equal sign metaphor. Using it we can isolate one animal at a time to transform them as needed.)

[Symbology]

An observation I was describing in my discussion with PyroTex today is one that comes from my experience. When I have to assimilate multiple functions which I observe are all serving a similar purpose (insert appropriate Borg reference here) :

• My first abstraction on a given case tends to be the "Prototype". It is very rough.
• Testing this prototype and adjusting it to fit the second concrete example is usually the toughest part, and is likely to introduce the most number of errors.
• After testing and applying the abstract code to the third concrete example, the code tends to be much more robust and ready to take on the 4th through Nth cases. Basically the skids have been greased at that point.

This falls in line with what I have observed of releases of major software such as Windows 3.0, 3.1 (yechth!), and 3.11
OS/2 v1 (as if), v2 (God help us!), and v3
and basically all other major software and drivers. The copy you want is always the 3rd version.


"Third time's a charm"