After the first rejection, the only appropriate response is "Okay, do you have a spec, or at the very least a document detailing the format you want the email to be in? No? Okay, I'm not writing anything until I have one."

Herbie should be happy that atleast they changed their mind so quickly. Typically various drastic changes and additional requirements appear long after the code has been written, tested and put into production...

"You would wait for the first rejection to say that?" - Yes, because the first time it was asked they just wanted an order confirmation. While you can have some sort of "marketing and communication" department supplying the text for that, lots of (mostly smaller) companies don't.

After I write the code to generate the human-readable format and get told that is was wrong, my reply would be, "Why did you not tell me that in the first place? I just did 3 hours of billable work for nothing. What is the file format we should generate then? If you don't know, put me in touch with the "Me" over there so we can work out all the details."

While tests of some kind are helpful, Herbie's not really in a position to write tests that will verify acceptance by a parser he has no access to, which processes a language that doesn't seem to be documented anywhere and was discovered by trial and error.

At the same time, Herbie's code exhibits the kind of brute-force string-banging that is the bane of my existence. Factor that noise.

Honestly, this post makes Herbie sound like a noob. When the boss says "send a notification to our automatic system", it goes without saying that the notification has to be in the system's own input format, not some random made-up XML schema. There generally isn't a mirror-Herbie waiting around to write the translation code.

That is actually double ended python, not XML and it's actually easier to write a parser for that. It's also more human readable too. More human and machine readable than XML (lack of escaping aside). It isn't particular portable but I would parse anything over XML.

Nope, SGML, MIME and ASN.1 are all worse. ASN.1 and all the DER, CER, CRT shit spawned from it are particularly horrific, those are the binary formats used in certs. Generally, the whole x.500 standard is a nightmare of biblical proportions.

In a case like this can you just say 'ok well we don't support this custom format so we'll send it to you via XML and you can modify it to fit your custom format's requirements. I'm sure a dev team that writes a good custom format also can import industry standard formats such as XML and JSON, correct'?

The real WTF here is that "Herbie" wrote two iterations of the solution before bothering to find out what the requirements were. Frankly, the poor folks on the receiving end of his code have a better WTF to tell than "Herbie" does.

I'm quite sure that he tested his work, but I do not think he had any access to the acutal parser (and he likely didn't want access, in order to preserver sanity).

Who knows what quirks the parser has?

For all we know there may be a special case buried somewhere where only the 2 outermost # characters are used for delimiters and the inner most pair is included in the actual data:

###mangled_tag### Data ###mangled_tag### results in the value '# Data #' being used in the application.... (and as already noted, they are likely using regexes for parsing, neatly discarding the 'extra' # characters on the outside....

The worst part of ASN.1 (leaving aside the question of BER versus PER) is that it also infected SNMP, ILMI (which is essentially SNMP over AAL5 ATM frames), H.323, and many other things.

But PER is the worst. BER is just a binary TLV format - all the information to at least be able to extract the data values is in the encoded stream, even if you don't know what that "7" there means. PER deletes as much of that extra information as it can, on the assumption that anyone trying to read a particular piece of encoded data will know which data definition schematic thing to use.

The real WTF here is that "Herbie" wrote two iterations of the solution before bothering to find out what the requirements were. Frankly, the poor folks on the receiving end of his code have a better WTF to tell than "Herbie" does.

Well it could be that, but I quite often find I've got a middle layer of (mis) management or three and semi-competent business analysts between me and the client/end-user. In my current humiliating whore-ing out of my skills, I don't even know who or what is consuming my data, so I'm reliant on being drip-fed the wrong requirements and "correcting" stuff when I'm told it didn't work (usually without any meaningful indication as to why).

They've usually written some misleading bullshit functional spec to get the thing signed off by the project board, so you get given that second, the first iteration being based on the misleading summary of it given by your line manager. Then you get some business analyst giving you their incorrect assessment of what's really needed. If you are lucky by the sixth or seventh iteration you get to talk to somebody at the other end of the chain who actually knows what they are doing and has some notion of what is needed.

Of course at the end of all this, you'll get something working which might or might not make enough people happy along this chain that they all reappear to claim the credit for "another one of my projects has successfully deployed ... who are you? so what was your input on this? Hmm, right, is that a plate of doughnuts over there?"