• MiserableOldGit (unregistered)

    Sounds fairly normal, I've worked in many places like that.

    FWIW, his home-baked ORM thingy doesn't sound much more of a dog than the regular tools.

  • my name is missing (unregistered)

    This sounds like the banking software when I worked for a Financial company that had a bank. It was written in a home grown language; you sent the code to the vendor to be compiled into the application which was shared among all the vendor's clients. Yes this is a banking system vendor: your money managed by a homegrown language in a shared binary with other banks.

  • JR (unregistered)

    I Been there, am there, and will be there. Always suffering the "Super Trooper Guru" insights.

  • Dave Hemming (unregistered)

    Ah, the old "I've used a database platform to build a database IN WHICH I have built a database platform IN WHICH I have built a database." It always seems such a good idea when you start out.

  • Steve (unregistered)

    Given the layers of WTFery I'd say that 40 hours to turn round an interface button is pretty good going ...

  • (nodebb)

    I've seen these things more than once.

    They usually start out as a quick and easy little tool that takes away some repetitive manual work. And because of that, everyone starts to use it. And it becomes part of the process. Then features get added. And more features get added. And more...

    At a certain point, usage of The Tool takes more time than bypassing it alltogether. But by then, you must use The Tool, because it is part of The Process. And The Process Should Always Be Followed.

  • Dlareg (unregistered) in reply to nerd4sale

    At which point some one create a quick and easy little tool that takes away some repetitive manual work in working with The Tool. And because of that....

  • Raj (unregistered) in reply to my name is missing

    I've seen even better than a homegrown programming language: a homegrown programming language that relies on a homegrown database engine. That's how ASG Rochade works. A real pleasure to work with.

  • sizer99 (google)

    The biggest thing with these tools that grow out of control is that they're never designed, just accreted. Like bash. There's always some tiny core that was designed, but you would have made much different choices early on if you knew where it was going eventually. And that's the usual way you get a 'fiendishly complicated schema with opaque and inconsistent validity rules'.

    TRWTF here seems to be that you have to get each layer approved separately before you can even TEST it. No test server?

  • grasshoppa (unregistered) in reply to Dlareg

    A fun side effect of this..."process" is you will sometimes have random boxes sitting around doing "something". If you're lucky you have an inkling which "process" it's doing "something" for, but even if you do it's likely you're wrong.

    Worse case scenario some manager gets it in their head to "clean out the cruft". Since no one knows what Box A does, that's the first to go. That was a fun week; damn thing hadn't been shutdown in years, and the person who had known something about it had left AND it had been running an unsaved configuration ( I think ), so shutting it down didn't just destroy a "process", bringing it back up didn't "fix" anything.

    End result? Now there are documentation processes. None of which would have prevented this ( had they been in place at the time ), but they do add a layer on to any "process", so I guess there's that.

  • eric bloedow (unregistered)

    i remember an old story where some company forced the employees to use a Windows Emulator...that RAN IN WINDOWS! EVERYONE hated it, but management though it was wonderful.

  • (nodebb)

    In my last job, there was a guy who literally wanted to create a table with 2 columns, name and script. The idea was to write a simple C# wrapper which took name as input, looked up the script, and executed. I brought up the fact that it's precisely what stored procedures are for. But he was the DBA so he went ahead with and I didn't really care too much to fight over it. His contract expired a couple of months later and a few weeks after that, we got rid of his invention. But still, for a few months, it ran in production.

  • xtal256 (unregistered)

    "...few weeks after that, we got rid of his invention"

    That's the real WTF right there. I expected you to say that after he left you were assigned to take over maintenance of his horrible tool.

  • (nodebb)

    Well, he did take over maintenance of it, and managed to tighten up the code significantly.

  • löchleindeluxe (unregistered) in reply to sizer99

    TRWTF here seems to be that you have to get each layer approved separately before you can even TEST it. No test server?

    Does that thing sound like you could replicate it onto another system and it'd still work? One that doesn't write into prod data, even?

  • 516052 (unregistered)

    I am always confused as to why these people don't just find a better job. It's not like there aren't plenty of programming jobs out there.

  • Ultracommenter (unregistered) in reply to xtal256

    I expected you to say that after he left you were assigned to take over maintenance of his horrible tool.

    "Maintained" by removing and replacing with something better

    Captcha made me do like 10 of those stupid puzzles :|

  • RLB (unregistered) in reply to eric bloedow

    some company forced the employees to use a Windows Emulator...that RAN IN WINDOWS!

    I've used something like that, at one point, for a semi-good reason. For security reasons, the company had updated to a (much) newer version of Windows, but there was this one critical tool which only ran on Windows Pre-history and could not be updated. A replacement "was coming" (and IIRC, surprisingly it eventually did), but in the mean time, the tool was being used in a sandboxed emulator. Clunky and painful, but necessary. (Sorry, I don't remember the details and I don't think I want to.)

  • RLB (unregistered) in reply to 516052

    It's not like there aren't plenty of programming jobs out there.

    Not all of us live in That There London Town, or want to, or can.

  • MiserableOldGit (unregistered) in reply to RLB

    Also, the places with the vacancies they are always trying to fill have a attractiveness/staff retention issue for a reason.

    I spent a while in the noughties on the job agency merry-go-round where you got placed, 6 to 12 months later the phone would start ringing again with one of the agents telling you how they "had no idea" about the issues in that place, "here's another offer for you". They just had a list of half a dozen shit places in each area, and they place you in one each turn, get their commission and move you on.

    Not good for the sanity, but I did gain an awful lot of experience in how not to do this job, and cogged up my salary each time.

  • (nodebb)

    I worked for a developer who fell in love with Smalltalk-80 and decided to implement an object oriented system using the Unix shell. Each object was a separate executable passing data on a pipeline, receiving data on a pipeline. This on a miniature NCR Tower with 32 megs! of memory and a 400 meg disk drive. Some of the lookups would require thirty programs in the pipeline. This machine was so slow, it took 15 minutes just to launch emacs (emacs users would launch it early in the AM, get coffee, then stay in the same session till quitting, using emacs as the shell). It also required our users to use object oriented terminology.

  • (nodebb) in reply to eric bloedow

    Windows 7 Professional 64-bit actually came with Windows XP mode thus allowing you to run all your old 16-bit software after a fashion.

  • (nodebb) in reply to urkerab

    And before that, there was Microsoft Virtual PC, VirtualBox, VMware Workstation, etc.

    Windows XP mode was nice in that it was more seamless than most other solutions and the licensing was a lot less dodgy.

  • Bitter Like Quinine (unregistered)

    Ah yes, "data-driven" applications that are more data than application.

    Just worked on one where the layout of a web interface, control types, contents, rules, and relations are all in tables, that are read by queries that are stored in other tables, against keys that are in a hierarchy described by yet more tables.

    I spent weeks hammering through the sparse and frequently inaccurate specification of the "architecture", involving quite a lot of trial and error discovery and more than a few bug reports, to eventually get a report interface that looked and worked to the requirements. Then I was half-way through the single stored procedure that would drive the the output when I was furloughed and the job was passed to my boss to finish up the last couple of days work. For which he got all the credit.

Leave a comment on “Ultrabase”

Log In or post as a guest

Replying to comment #:

« Return to Article