• Factory Improvement (unregistered)

    Been there, done that

  • DFYX (unregistered)

    There is a really easy way to avoid people asking why: document the thought process. A lot of people still seem to not understand that comments are not (mainly) there to document WHAT a piece of code does. Well-written code is usually easy enough to understand. Comments are there to document WHY that code does what it does. A single line "Using CSV because JSON is not supported in Office 2013 and XML is too slow" prevents this from ever becoming a submission.

  • DFYX (unregistered)

    There is a really easy way to avoid people asking why: document the thought process. A lot of people still seem to not understand that comments are not (mainly) there to document WHAT a piece of code does. Well-written code is usually easy enough to understand. Comments are there to document WHY that code does what it does. A single line "Using CSV because JSON is not supported in Office 2013 and XML is too slow" prevents this from ever becoming a submission.

  • bvs23bkv33 (unregistered)

    seen that shit, swam in it

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    TRWTF is Microsoft

  • RLB (unregistered)

    And, let's be quite honest here: if CSV suffices for your data, CSV suffices and why complicate things? Yes, it's old. Yes, it's imperfect. So is English, and we're not reading this site in Lojban or Esperanto.

  • Shadow (unregistered)

    The main WTF is that this guy seems to think that old=bad and new=good. Though when it comes to CSV he might have a point.

  • Philip Storry (unregistered)

    These things happen.

    It's 2019. Earlier this year I had to write a small C# program to replace a component in a workflow. We were migrating an infrastructure we inherited when buying another company to our own slightly newer version of the same platform. 99% of the purchased platform could be re-used but a few small parts needed to work a little differently to meet our newer requirements.

    So I had to write code that communicates its state to other components by... updating an entry in a .INI file.

    Seriously. Updating INI files to communicate status.

    My documentation shows that it's not how we'd do it if we had the choice. But either we use the INI file, or we rewrite everything else in that infrastructure. And we'd rather spend our time working on the migration of customers and data to our most modern platform - which assuredly doesn't use INI files.

    I'm not a professional developer, but occasionally write code for fun. If you'd told me in January 2019 "This year you'll write an application that uses an INI file" I'd have laughed at you.

    But the customers still pay the company, and none of them care how the applications coordinate and communicate. They just want their data processed. My job is to make sure that happens. So I get to write code that updates INI files. In 2019.

    (I've recently left that job. But not because of that project!)

  • (nodebb) in reply to Philip Storry

    Re: INI files to communicate status. Yeah, that's wrong tool for the job. Any disk file is wrong tool for that job. But INI stands for initialization. And as such it is braindead simple. Easy to parse and highly human readable.

    Seriously, one of the things that apparently must be cluebatted into people of this generation is "don't overcomplicate things" or YAGNI. When your platform (C#) provides config for you, by all means use that. If not, you can't go wrong with INI. Not in a way you couldn't do with any other format.

  • Ernesto (unregistered)

    This is not a WTF. As Scotty said: «The right tool for the right job». If you must send only a table, json can be overkilling. XML is overkilling (and gigantic). If you must vehicle structured data too along tables (so not just one query, but several queries) json (or similar structured format) can be the right choice in order to have just one format to rule them all.

    So, unless it is not a CSV+JSON+XML+XAML+(other format that no one knows) depending on the client, it is fine. Must be coherent.

    The real WTF is "why on the earth someone would use Office 2013 in 2019? (really why would someone use Office in first place?) With the cost of Zen's job to make the sw compliant with an old piece of junk they probably would have bought an upgrade of Office suite. Am I wrong?

  • Dlareg (unregistered)

    Personally I always liked Xev better.

  • Scott (unregistered) in reply to DFYX

    I cannot second this enough. Philosophical documentation is key when writing what you feel is clumsy, hard-to-understand code.

    Sometimes, it's just out of necessity, as in today's example. Sometimes, it's that you can't see the forest for the trees. Writing a couple lines of "this seems wrong, but here's why I did it this way" will help other developers (or yourself, in six months' time) understand why, and (maybe) with a fresh perspective be able to un-munge that part of the code.

  • Jaime (unregistered)

    You guys don't think that Excel/Access is the WTF? This whole project would have gone a lot better if he had simply used C#/SSRS for reporting. I don't mean an SSRS server and an instance of SQL, I mean having C# call the API, then passing that data to a local report (*.rdlc). It's ridiculously easy, gives you a professional report designer, a decent report UI, and decent export capability.

  • Gumpy Gus (unregistered) in reply to Shadow

    Memory is fading, but I once worked at a place that kept everything in CSV files. One big problem, one of the major parts, don't remember, could have been Access, did not know how to escape double-quotes. So some horrendous work-arounds had to be done to keep from breaking the CSV files. The exact details have blissfully left my memory but they were awful. Also, CBASIC and using drive-by WiFi as a data download method..

  • (nodebb) in reply to Jaime

    RDLC is a head-desking pile of implicit behavior compared to Crystal Reports, which unfortunately suffers from integration and scaling headaches. (Sometimes it's easier to do some rearrangement of the data within SQL first.)

  • (nodebb) in reply to RLB

    "we're not reading this site in Lojban or Esperanto."

    Parolu por vi mem.

  • Jaime (unregistered) in reply to emurphy

    I don't disagree, but I find the management and architecture advantages of Microsoft's technology outweigh the advantages of Crystal's better report builder.

    Besides, if what you're doing requires too much is the way of fancy report features, you are probably embedding logic in your UI.

  • (nodebb)

    I'm going to second DFYX here. At least back in the stone age when I was in school teachers handled comments horribly. A professional programmer should be able to read the code fine--to me a comment saying what it going on is a code smell, 99% of the time it means you need more descriptive names and the like. Comments should be for why things are the way they are, especially documenting why "better" solutions aren't.

    I also occasionally end up with something hard to read but more efficient, then after it // optimized version of // easy to read but slow version

  • Philip Storry (google) in reply to Applied Mediocrity

    Yeah, I'll admit that YAGNI was a big influence on how I wrote the application module. I had to use an INI file for communication, but I didn't use it for configuration - I used the XML config file that the C# application gets by default.

    Why? Because the historical application we were replacing had all kinds of weird cruft. We knew exactly which parts we wanted to use, so it was easier and faster to just use the built in .NET tooling and to only implement the parts we needed. So it wasn't worth writing anything for the future, or preserving any functionality that wasn't still being used in Production. The goal was to get it working reliably in the new infrastructure. Nothing more. That did include logging so that people could diagnose issues, but that was our only luxury. (And I don't like regarding logging as a luxury!)

    Also, thirding or fourthing the idea of comments that show thought processes and help understand the why of the code. The old application was written in a compiled batch/scripting language from the 90's. And whilst we had the source code, the sole comment was a copyright date of 2002. No other comments. At all. Some commented out code blocks, but otherwise it was a proper software archaeology job...

  • Officer Johnny Holzkopf (unregistered) in reply to Dlareg

    Goooood fooood, baby - Zev of B3K.

  • CdrJameson (unregistered) in reply to Ernesto

    "Why on the earth someone would use Office 2013 in 2019?" Completely. I mean, Office 2003 still works fine. And oddly all the operations are really quite quick. I certainly don't find myself waiting for imports to complete.

  • eric bloedow (unregistered) in reply to Philip Storry

    oh, i've heard of worse:a company sending information from computer to computer by changing the Windows System Registry! talk about inviting disaster!

  • (nodebb)

    TRWTF is migrating to the cloud with no clear goal in mind. Everything became worse. But the company is now in the cloud. Such cringe.

  • Barf4Eva (unregistered)

    The WTF is a CSV? My personal hell covers every possible format of data. Lucky me. Customers are sometimes the deciding factor on what a format will be. So, sometimes there is no choice. Sometimes, there is. And because of that, CSV will be here till we are all well dead and in the ground. Drink up!

  • Pk (unregistered)

    They are trusting you to run vba. Why not install an excel addin with that vba, bundled with one of the myrriad json parsing libraries out there?

  • Heinebold (unregistered)

    It is about transferring tables, and of all the mentioned formats, CSV is the only one that natively represents them. TRWTF is thinking that "modern" == "good" and "not new" == "outdated" == "bad"

  • (nodebb) in reply to Philip Storry

    I'm not a professional developer, but occasionally write code for fun. If you'd told me in January 2019 "This year you'll write an application that uses an INI file" I'd have laughed at you.

    OK, it's not for communicating status, but my company's products use what are essentially .INI files to store configuration, and every time someone stores new configuration for something, bingo, a new .INI file. In 2019, and very soon in 2020 as well.

  • nope (unregistered)

    TRWTF: people thinking that XML is superior to any other data format in the first place. CSV > XML

  • Dave (unregistered)

    Depressing, but not surprisingly, no-one has pointed out that the real wtf is in fact that Excel 2013 has built in functionality to do what has been hacked together using csv.

  • (nodebb)

    Zev is a real software engineer. I wish I worked with him. Real engineers solve problems in ways that work for their customers. Real engineers don't blame their tools. Read about the project to upgrade the New York City Subway signaling system sometime.

    As for the embarrassment factor, one simple comment somewhere in his solution containing a summary of this WTF post would explain everything to the next person to hit this stuff.

  • Argle (unregistered)

    Maybe it's just me, but I get preemptive about these things. If I'm stuck with a load of garbage from a predecessor, I just own the lunacy and add some comments. "Why the H.E. double toothpicks did Argle do it this way? He must be an idio.... oh, here's a comment. Dang. Poor Argle." My daughter is 31. I recently converted BASIC code to C# based web pages. I cringe when I look at parts of the conversion. But it was so highly technical that I even had to reproduce the bugs. Ugh.

  • Argle (unregistered)

    Left out part of my last comment. The code was older than my daughter.

  • (nodebb) in reply to Dlareg

    If that's the reference I think it is, then I agree (not sure why everyone liked Zev more).

  • Seperated by a common language (unregistered)

    No doubt CSV was required for this project. And JSON is too new, and XML is too fat. But what people who haven't used CSV don't remember is that CSV is not a standard. Not oven for one provider. Not even for one product. Not even for one version. Not even for Excel*. 5 years from now, someone is going to say "it's just CSV. We can connect to that". And they will be wrong, and when it goes to production, it will fail, because the new connection will have a different rule for parsing CSV..

    *As in, you can't export it, then re-import it.

  • isthisunique (unregistered)

    I remember this system I integrated with that would drive me crazy because it would upload sort of CSV clearly just the output of some database CLI so it would look like this:

    | FIELD | |

    Padded out even if not needed but then also truncated because apparently everything would have some fixed width, etc.

  • Zander (unregistered) in reply to Philip Storry

    Well it's quite clear you don't work with Linux

    DBus services are INI, as are systemd units (think COM and Services)

    Desktop Entries (app launchers) are also INI

    If your working with GLib the fallback settings store is INI (though it prefers dconf, basically the registry)

  • ch (unregistered) in reply to isthisunique

    CSV is a standard - https://tools.ietf.org/html/rfc4180

    I would have been inclined to implement the JSON solution by adding a JSON->XML converter for feeding files to Office 2013. That way, when Office is upgraded to something that understands JSON, the converter can be discarded and you're left with the proper solution.

  • eric bloedow (unregistered)

    this reminds me of an old game review in a gaming magazine: the makers of a game wrote it in ASSEMBLER so it would run smoother!

  • Game Developer (unregistered)

    You could've written a custom JSON parser in the VBA.

Leave a comment on “Out Of Necessity”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article