• LCrawford (unregistered)

    The app frist began its design as an XML app.

    P.S. I can't solve the rhyme riddle?

  • danfal (unregistered) in reply to LCrawford

    string concatenation?

  • (nodebb)

    I love people whose only answer is "This is how we've done it". What, you don't evolve as you learn?

  • (nodebb)

    This is how we do, We make a move and act a fool, ..., Nobody do it like we do it, So show us some love.

  • ray10k (unregistered) in reply to LCrawford

    String Concatenation.

  • Anon (unregistered) in reply to DocMonster

    I can attest that this was often the excuse I was given by a former boss at my company when I asked about incredibly badly designed and written legacy code.

    And that wasn't even the dumbest comment.

  • RLB (unregistered) in reply to LCrawford

    @LCrawford: the determined Enterprise Programmer can write XML in any language.

  • Brian (unregistered)
    We know that governmental data-systems aren’t generally considered ‘cutting edge’ or ‘well architected’

    Heh, there's an understatement. I recall when I was still a naive young college graduate, and I thought it would be fun working for the DoD because of course the military has all the cool new toys, right? Man, I couldn't get out of there fast enough; to this day it was still the most boring job I've ever had. Working for a military contractor was marginally better, but everything they did still moved slightly slower than a snail's pace thanks to the mountains of bureaucracy involved.

  • Dave (unregistered) in reply to DocMonster

    'This is how we've done it' doesn't mean what you think. It means something more like 'granting mistakes may have been made in the past, it's not worth the investment needed to start from scratch again and fix it'.

    This probably started at as a very simple thing where it didn't really matter how it was done. Then it had a little bit added, and it wasn't worth rewriting it at that point. Another bit, still doesn't seem worth rewriting to do it properly. By the time it becomes obvious that it's the wrong way to do things, it's too complicated to be easily replaced in less time than it takes to modify the existing code. Eventually you end up here.

    There are no big mistakes involved in the process, just a series of slightly short sighted decisions.

    To avoid falling into this trap, there's a simple rule of thumb: you usually get zero of something, one of it, or many of it. When you find yourself adding the second thing, assume that two will probably become many.

  • (nodebb) in reply to DocMonster

    You're assuming that those people learn. They really don't. They just move on to make another mess while somebody like Oralee gets stuck maintaining the last one. "This is how we've done it" is a warning much like an animal's growl. Keep poking the bear and it'll fire you.

  • Simplifier (unregistered)

    Simplified, that JSON is something like:

    { "Registrations": [ { "IdRegistration": "94", "CaptionActive": "EF_PRE_CR", "DateEnd": "2019-01-01", "DateStart": "2019-01-01", "Units": [] }, { "IdRegistration": "92", "CaptionActive": "EF_PRE", "DateEnd": "2019-01-01", "DateStart": "2019-01-01", "Units": [ { "Value": null, "IdUnit": "1", "CaptionUnit": "Hour" } ] } ] }

  • Russell (unregistered) in reply to Dave

    You can possibly also add a "the person(s) who originally developed this are gone, and the technical understanding of the series of steps that brought us to this point has gone with them" to your translation.

    This is at least partly true of our organization (although I'm still here), and is part of my own "this is the way we do it" explanation i have to offer to other developers when attempting to explain / justify our "JSON" based messaging system, that gives us wonderful data messages like

    { "XIP" : 1, 17, 8, 0, 2, 9, 54, "XFR" : 20, "SID" : "aCdfg10xn5t", "PID" : "tnDFgh100Z", // etc }

    It's elegant, it uses short keys so its QUICK TO SERIALIZE AND PARSE and if you want to retrieve the actual structural data it represents, all you have to write in every consumer is an 800 line parsing routine (some of the fields contain data to tell you how to divide other fields up into structural objects).

    Thank the gods, i think I have now convinced managers / the devs on the other team that its time to overhaul the server / client messaging api.module.

  • ooOOooGa (unregistered)

    In addition to the '[C|c]ode/[V|v]alue' pairs, don't forget about the 'code/Configurations' pairs or the 'code/[V|v]alue/Configurations' pairs.

  • Gumpy_Gus (unregistered)

    I once worked for a certain government agency. Adding one sentence to a contract took three days. Why you ask? The word processor, female, aged 50, civil service, only know how to input one page per file. So adding a sentence to page 3 of 12 required editing pages 3..12. That's govt for you!

  • Mike (unregistered)

    Ordered keys though!

  • (nodebb)

    I tried to change what I thought was a simple thing. In the beginning, the program used a hard copy terminal (think Teletype), and printed out something like:

    "Password: \r          XXXXXXXX\r         MMMMMMMM\r          "

    For the prompt. The idea was to strike over where the password was to be entered. The problem was that on a soft copy terminal, the prompt was overwritten by the leading blanks, so it was a dumb prompt. I tried to change the order of the overstrikes, but to no avail. That was the way they had always done it, and any change punted their regression tests, so they didn't want to change it. That was about 10 years ago, and I suspect that it still that way. This was a company that airlines used, so you make conclusions.

  • Friedrice the Great (unregistered) in reply to Gumpy_Gus

    Or a very old wordprocessing system. The Lanier No Problems system could only work with one page at a time. I think the IBMK DisplayWrite system had the same limitation. Automatic pagination wasn't something those systems had memory for. So adding a line to one page meant you had to move another line to the next page, and so one down the line. Actually, probably had to move the last line of the next to last page to the last page and work backward from there.

    You young whippersnappers thinking that wordprocessing has always been done the way it is now!

  • (nodebb)

    I think, as a customer, it's hard to ignore the elephant in the room, when you notice the company's inabilty to produce 'nice, easy-to-consume JSON objects'.

    I hope marketing never uses this phrase as their selling-point.

  • (nodebb)

    "How is the data represented?" Joe asked.

    "In code-value pairs," Moe answered.

    "And how are those code-value pairs represented?" Joe persisted.

    "In code-value pairs," Moe answered.

    "Look, somewhere down there, there has to be characters or something!" Joe exclaimed.

    Moe tilted his head forward, peered at Joe over his glasses and said, stubbornly, "You're wrong, Sonny. It's code-value pairs all the way down.

  • (nodebb) in reply to Gumpy_Gus

    female, aged 50, civil service,

    You forgot to mention this person's religion, nationality, marital status, level of education, and skin colour. Did I miss anything?

Leave a comment on “The Value of Your Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article