+972 52-548-6969
Paranoid decisions and OMG customers
I used to be a consultant for a long while, and that meant that I worked on a lot of customer projects. That led to me seeing and acting is some really strange ways.
Sometimes you go into a codebase and you can’t really believe what you see there. I think that this is similar to how an archeologist feels, seeing just remnants of something and having to deduct what were the forces that drove the people who built it. In some cases, what looks like bad code is actually a reaction to a bad policy that people are trying to workaround.
I think that the strangest of these cases was when I was working for a customer that refused to let external consultants to use their internal source control system. Apparently, they had sensitive stuff there that they couldn’t isolate or something like that. They were using either Team Foundation Server or Visual Source Safe and I didn’t really want to use that source control anyway, so I didn’t push. I did worry about source control, so we had a shared directory being used as a Subversion repository, this was over a decade ago, mind.
So far, so good, and nothing really interesting to talk about. What killed me was that their operations team flat out refused to back up the Subversion folder. That folder was hosted on shared server that belong to the consulting company (but resided at the customer site), and they were unwilling to either back up a “foreign” computer or to provide us with a shared space to host Subversion that they would back up.
For a while, I would backup the Subversion repository every few days to my iPod, then take a copy of the entire source code history with me home. That wasn’t sustainable, and I was deeply concerned about the future of the project over time, so I also added a twist. As part of the build process, we packed the entire source directory of the codebase as an embedded resource into the binary. In this way, if the code was ever lost, which I considered to be a real possibility, I would have a way to recover it all back.
After we handed off the project, I believe they moved the source to their own repository, so we never actually needed that, but I slept a lot better knowing that I had a second string in my bow.
What is your craziest story?
Comments
I have two stories to share:
The first one starts back around ~8 years, I was a young political scientist eager to find a job in market research. Well, I found a "online" market research firm who searched for a statistician who could also program. Well, I learned to programs in the mists of time, so I was hired. This worked well for both of us, since I could refresh my programming skills and I could help them automate some of the boring stuff. After a while, the charting team noticed that I reduced the workload of our statistics department considerably and asked if I could help them automate "charting". Charting is taking incredibly boring: Take the standardized output of the statisticians, put it in a powerpoint presentation and hand it of the guys or gals who interpret the stuff. I was ordered to automate the "put it into powerpoint" stuff - but I had no experience at all with creating powerpoints using the OOXMl library, but even worse they wanted to be their layout to be pixel perfect according to rules which where impossible to code in OOXML, since you had to measure pixel distances, which the OOXML library cannot provide. So I build a giant VB.NET - Powerpoint interop frankenstein monster which build every page from scratch, added diagrams, data, resized and colored the sentences. It was ...beautiful in a way, to see how the screens got build. The main drawback was that it was slow as molasse and furthermore automating powerpoint can lead to spontaneous crashes of Powerpoint, so I had a watchdog process which detected such hangs and killed the whole program. It worked but was unmaintainable due to my inexperience and the tight coupling between business logic and design. I was let go after a year because of financial difficulties but stayed on as a contractor for multiple years just to expand this program.
The second story happened mostly before I started at my current company. We have a reporting product which is written in C# and it used silverlight as it's frontend - due to massive NIH, every diagram was custom made, but the small team could no keep up with the demand for new and even more intelligent charts (intelligent means prediction etc, proto data science...). So a brilliant engineer who knew python hacked in a way to send data to python and use it's matplotlib library to generate diagrams. The demonstrator worked, but there was a problem: how to integrate that into the server product which uses C# and runs in the IIS? In that time, running a python webserver in IIS was next to impossible, so they build their own "webserver": A c# process hosted in IIS used .NET - Python interop to start a python process who was used to process incoming requests. It even worked way better than I would have expected: the .NET - Python binding was stable and could be used to transfer data using WCF. I have never seen two such disparate languages and concepts married, there was even a matplotlib backend for XAML(!). There where threading problems since there was only one python process which served all requests, but careful usage could circumvent most problems. For a customer I even wrote the ultimative abomination: I used a python - R interop package to allow the usage of R in the system. The downfall of this system was maintainability: It was literarily hacked together at night, python and c# codes were mixed and there where more design bugs than anyone would like. So we finally replaced it with a WSGI based solution, which had come available in the meantime - it cost a lot more than we had anticipated, but it works rock steady. Sadly, it will probably canned soon, since the remaining team still views python as a crappy diagramming language better to be replaced with JavaScript (where I would agree), but does not understand how powerful python data processing capabillities are.
Aaahh, the memories! shudder Given the same set of requirements, I opted for using Powerpoint VBA instead of Interop which allowed me to fill predesigned template pages reading from data from CSV previously written in a batch. Slow as well, but way more stable. Only drawback was having to write Powerpoint VBA instead of Interop .NET code...
@Felix Deutsch Fascinating that you build the same thing - I thought it impossible to create that kind of madness twice ;) I used VB.NET because I had to do a lot of data munging before I could the data into the presentation. Fortunately, the data munging was well defined: Read from an excel file, split the single sheet according to some weird rules and transform it and put it into the file. And I really hate VBA - it's just lacking everything I expect from a modern language.
Taking over from a guy that was using his "old pc" as a source control server for a few business critical projects that the department of a major global bank depend on.
His "old pc" was a really stuck somewhere in an attic and he connected via RDP. All code and source control was in there.
On my first day of the job I RDP'd and faced a very slow connection. So I rebooted the machine.
When I went upstairs to investigate why the machine was not responding to requests, I smelled that burnt plastic odor as I opened the door... yep, no more machine. My first day on that job was spent with sleeves rolled up extracting an early 2000s era hard drive and praying to God that it didn't burn out (in the end it was the PSU).
Comment preview