Classic WTF: The Developmestuction Environment
We continue to enjoy a brief respite from mining horrible code and terrible workplaces. This classic includes this line: "It requires that... Adobe Indesign is installed on the web server." Original --Remy
Have you ever thought what it would take for you to leave a new job after only a few days? Here's a fun story from my colleague Jake Vinson, whose co-worker of three days would have strongly answered "this."
Having personally seen this system, I want to share a fun little fact about it. It requires that, among a handful of other desktop applications, Adobe Indesign is installed on the web server. I'll leave it to your imagination as to what it could possibly require that for and the number of seconds between each interval that it opens and closes it. [Advertisement] Ensure your software is built only once and then deployed consistently across environments, by packaging your applications and components. Learn how today!One of the nice thing about externalizing connection strings is that it's easy to duplicate a database, duplicate the application's files, change the connection string to point to the new database, and bam, you've got a test environment.
From the programmer made famous by tblCalendar and the query string parameter admin=false comes what I think is the most creatively stupid implementation of a test environment ever.
We needed a way to show changes during development of an e-commerce web site to our client. Did our programmer follow a normal method like the one listed above? It might surprise you to find out that no, he didn't.
Instead, we get this weird mutant development/test/production environment (or "developmestuction," as I call it) for not only the database, but the ASP pages. My challenge to you, dear readers, is to identify a step of the way in which there could've been a worse way to do things. I look forward to reading the comments on this post.
Take, for example, a page called productDetail.asp. Which is the test page? Why, productDetail2.asp, of course! Or perhaps test_productDetail.asp. Or perhaps if another change branched off of that, test_productDetail2.asp, or productDetail2_t.asp, or t_pD2.asp.
And the development page? productDetaildev.asp. When the changes were approved, instead of turning t_pD2.asp to productDetail.asp, the old filenames were kept, along with the old files. That means that all links to productDetail.asp became links to t_pD2.asp once they were approved. Except in places that were forgotten, or not included in the sitewide search-and-replace.
As you may've guessed, there are next to no comments, aside from the occasional ...
' Set strS2f to falsestrS2f = falseNote: I've never seen more than one comment on any of the pages.
Additional note: I've never seen more than zero comments that are even remotely helpful on any of the pages
OK, so the file structure is next to impossible to understand, especially to the poor new developer we'd hired who just stopped showing up to work after 3 days on this particular project.
What was it that drove him over the edge? Well, if the arrangement of the pages wasn't enough, the database used the same conventions (as in, randomly using test_tblProducts, or tblTestProducts, tblTestProductsFinal, or all of them). Of course, what if we need a test column, rather than a whole table? Flip a coin, if it's heads, create another tblTestWhatever, or if it's tails, just add a column to the production table called test_ItemID. Oh, and there's another two copies of the complete test database, which may or may not be used.
You think I'm done, right? Wrong. All of these inconsistencies in naming are handled individually, in code on the ASP pages. For the table names that follow some remote semblance of a consistent naming convention, the table name is stored in an unencrypted cookie, which is read into dynamic SQL queries. I imagine it goes without saying that all SQL queries were dynamic with no attempts to validate the data or replace quotes.