Good ways to overcomplicate your code and slow down development

[Robert Sneidar]

I suppose it really depends on the nature and scope of the problem.  
Recently I spent a day trying to sus out RegEx in order to write a  
function to determine if the "+" operator in Foxpro code was doing  
concatenation or actually doing math. I struggled with extracting  
just the portion of the statement containing a formula, seeing if  
there were other math operators, and then realizing in the end, there  
was no fool proof way to do it. It was all too complex. I wasn't  
making any headway, and in the end I would only succeed for about 60%  
to 70% of the instances. The rest I would have to visually correct.  
The code base is 400,000 lines, so that was out of the question.

Then I woke up the next morning and realized that if a quote was  
before or after the plus, it was obviously concatenating! DOH! Then  
it dawned on my a half second later that I already have a list of  
variables used throughout the whole project, and I only had to built  
a table of those variables and their types, and then filter for  
string types. I could then compare each word in the statement against  
that table. One hit on a string type variable in a statement and the  
plus operator HAS to be concatenating! Simple and elegant, and not a  
line of RegEx. So for that function I started from scratch. Twice.

Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

> We recently did a V2 for both ButtonGadget and eXpertSystem. While in
> both cases, the interfaces changed drastically, the underlying code
> didn't change that much.
>
> I remember something Mark Weider pointed us to a year or so ago. It
> said something about resisting the impulse to "wipe it clean and start
> over from scratch." It mentioned typically there is a lot of smart
> work-arounds, bug fixes and overall business logic in legacy code, and
> if one is not careful, the baby will indeed be thrown out with the
> bathwater.
>
> Previous to that article (Mark, ???), my inclination was to always
> start over and do rewrites, but after reading it, I've taken a more
> evolutionary, rather than revolutionaly, approach.
>
> -Chipp