Hacker News Reader

Comment by stestagg | Hacker News Reader

One reason, from our similar experience is that showing non-Technical business people (in some environments) text with brackets, semicolons and the general code annotations you show here effectively “scares” them.

This isn’t always true. But it tends to be institutional when it happens. In some places people learn deeply that code is the realm of the tech teams and they should not engage with it.

Getting them to engage with the executable tests can be fantastically useful but it can also be a delicate sales game, where simple things like using a DSL can be key

View on HN

That's assuming the "non-tech businness people" are actually going to spend time writing and reading such scripts.

I've never seen a situation where that ended up happening (because they're going to write the script wrong, they're going to need help debugging, etc...)

Their time is probably better spend doing something else. So they will write english in mails and powerpoint, and a tech will write code in a programming language.

The closest thing I can imagine to having biz people "write scripts", is if it's done in a GUI with a lot of assistance and a quick visual feedback loop (think Excel macros.)

Maybe writing the GUI is a better investment than writing a compiler.

The parent comment doesn't say the non-technical people wrote the scripts, but that they were shown the scripts.

Think of it this way: Writing iambic pentameter is hard. Without practice, you're almost certainly going to get the meter wrong at some point. However, reading it is easy, because it's just English.

The same can be true for scripts. You don't need to be able to have business people write them, but it's nice (and in some domains critical) to be able to have them read and validate them.

"So they will write english in mails and powerpoint, and a tech will write code in a programming language."

This reminds me of the old movies where the Executive calls in the secretary to transcribe his words.

"Miss Parker! Take this down!"

Something i've done in the past is write multiple backends for an internal DSL like this. One runs the tests, another one prints out the steps as nice-looking HTML to show to The Business. It means they can't read and edit the source code directly, but in practice, this doesn't matter. We even had one that produced Excel files that could be handed over QA as manual test scripts, so they could reproduce what we were doing.

An old boss once pulled off a hack where code drove a browser test, but you could run it step by step, with the element being inspected or interacted with being highlighted with a red border, and a separate window explaining what was happening in natural language. Non-technical people could follow along with what the test was doing. It was an amazingly effective way of explaining what automated testing was all about.

So show the laymen cute text without Scary Symbols, no? Heck, these days my tests with certain frameworks are automatically inundated with unsolicited fire emojis and green check marks. I'd imagine that isn't particularly difficult with C++, right?

Reply on news.ycombinator.com