> I’m pretty sure this couldn’t happen. I’d end up in jail myself for filing false police reports before I got anywhere close to double digits.
To your point, just this week Chicago Alderman Proco "Joe" Moreno was charged with "disorderly conduct, obstruction of justice and insurance fraud" for saying a woman stole his car after he lent it to her.
Anyone want to speculate on what percentage of Angie's List reviews are fake? On one hand you have to pay to leave a review. On the other hand, Angie's List gets paid if a business registers twenty fake accounts to post fake reviews.
There was a text-based GUI but the application programmers never used it. It was too limited and wouldn't let them accomplish what they needed to do, at least through the GUI. That is an interesting point: the underlying VM mechanism was more capable than could be exploited through the GUI. The method of working with text files described here had been established prior to my arrival. I was given training on the GUI, and then advised not to use it.
Why didn't anyone ever write a compiler for a saner (probably custom) language that targeted this VM for its output? Certainly that would be my first thought if the only choices were a GUI that was insufficiently capable or writing a bunch of comma-separated integers by hand.
I assume either the transition was too gradual so nobody quite realized the absurdity to a sufficient degree, or everyone was too busy running around with hair on fire getting the day's tasks done to spend any time on long-term improvement, or management forbade it as a waste of time. I'm curious which it was, or if it was something else.
You correctly identified the causes. Mostly, it was lack of time; keeping up with compliance changes is a full-time job at any bank, and there wasn't time for 'science projects'. What tools did get written were done to scratch a personal itch, and were done late at night and on weekends, outside of work hours.
I think, as I said in an earlier comment, that there was a general lack of awareness amongst the programmers on the team that anything better was possible. Most were not computer science graduates. Professional programmers they were. But I'll bet money that most had never heard of trees.
Management interest evolved over time from indifferent to actively hostile. The first generation LIST annotator improved productivity of the team and reduced errors probably at least fifty percent. Management took no notice at the time. Improvements to the tool, also developed out-of-hours, finally met with angry demands from management to stop and bury the results. Shortly afterwards the entire team was laid off.
Thanks for the details. I find these environments fascinating, although I'm sure they're best observed from a great distance in both space and time.
One more question, if I may: once you got used to it, what was the productivity like? I imagine these sorts of things as taking days or weeks to make the simplest of changes, but maybe the horror I imagine becomes routine after a year or two of experience.
It took less than two weeks to become fluent (I started writing the annotator tool around that time). Probably, it was the well-developed---if informal---methodology that Annie, the experienced programmer who took me under her wing when I arrived, taught me. She made a little ceremony of it, giving me my copy of the binder that held all of the accumulated knowledge about the reverse-engineered language in its photocopied pages, showing me how she used different coloured highlighter pens to tie together things in a listing, and giving me little example programs to understand. I studied diligently; it was like working crossword puzzles. About two weeks later, I was promoting my first changes to the test environment.
Edited to add: I never got over the white-knuckle feeling of it: everything global, limited supply of working-storage variables that were constantly being re-used, and interactions that could bite from a distance. One of the most useful features of the LIST annotator was that it generated an ordered cross-reference listing that could be directly compared. That feature made choosing safe working-storage variables a much safer activity.
> the underlying VM mechanism was more capable than could be exploited through the GUI.
I don't think that is uncommon. VM's are (almost?) always more capable than whatever language compiles to them (as are processors). I particuarly annoying example I have had to deal with is the Java VM. It has an instruction to take/release a lock on a variable. However, there was no language level feature that exposed this directly; and the synchronized construct added try/catch blocks so that you released the lock in a different scope than you took out the lock. This was espesially annoying because I was working on a 'decompiler' based on the idea of compiling JVM bytecode to Java source code. This meant that I basicly had to resort to pattern matching how javac compiles synchronized, so my solution was non generic. Also, Java for some stupid reason does not let you subclass Enum.
They might have some other activities. I've never been.