• Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.

Midramble

Force of Habit
The Fallen
Oct 25, 2017
10,451
San Francisco
What is it called when end users write their own applications?

No punchline, just google is failing me and I need to update policy to include this more directly than it being with just vague Dev team policy.

In more context I mean the common situation where, as an IT admin or manager, you end up finding shadow IT (unmanaged/unregulated software) on a system that was written, usually very poorly, by an end user to automate and aid some of their own tasks. Generally you'll find these large vbscript monsters, monolithic Frankensteins of python, or the occasional java goblin only when a separate user comes to you (after the original author left the company) asking for IT support on said code chimera.

Now this underlying situation always has me on the fence. I am happy to support innovation by creative users in the workplace. If someone has the talent and the vision to create something that improves the workflow of a department, that is a wonderful thing. At the same time, the code is written and tested outside the bounds of coding best practices and comes with all the risk inherent with that. Even more so, since the code is almost always written by curious novices, it is usually very poorly written and thus takes on more and more technical debt the longer it goes without being reported. This may seem harmless because the coding work by the user isn't interrupting anyone's day; however, every poorly written line is a debt that will have to be remedied in the future. A debt taken out on other departments without their say so. As a result one day the company may have to hire contractors to come in and just focus on rewriting your code because it somehow became a core component of operation without any maintenance or care being given to it.

For these reasons I believe all departments should have policy sections dedicated to this phenomenon and is why I'm updating my own policy. Just need to find a better name for it than "jankware" since that doesn't look great in internal policy docs. That and I wanted to get a bit of that frustration off my chest.

That said, maybe I'm just unlucky in finding this in most companies and this is actually a rare thing that never happens. Am I alone in experiencing office jankware?
 

Syriel

Banned
Dec 13, 2017
11,088
If it's basic, non compiled stuff, it's just scripting. Otherwise it's a service or an app.

But really, what you're looking for is the word "unauthorized."
 

BasilZero

Member
Oct 25, 2017
36,335
Omni
Unauthorized or unofficial.

What you mentioned also fits (unmanaged/unregulated) because applications usually are licensed and maintained.
 

Meatfist

Member
Oct 25, 2017
2,289
I would probably refer to it as unmanaged or user-generated scripts or applications - "unauthorized" has a more negative connotation if that's what you're going for
 
OP
OP
Midramble

Midramble

Force of Habit
The Fallen
Oct 25, 2017
10,451
San Francisco
If it's basic, non compiled stuff, it's just scripting. Otherwise it's a service or an app.

But really, what you're looking for is the word "unauthorized."
Unauthorized or unofficial.

What you mentioned also fits (unmanaged/unregulated) because applications usually are licensed and maintained.

Only reason I haven't used those terms is because that would seemingly cover shadow IT, meaning consumer grade apps (usually cloud since installation is blocked without authorization) where what I'm looking for is custom written ones. The distinction is because the former is covered under employee responsibility/ToU policy and managed by CASBs where the latter is harder to control and capture. Hence the separated policy.
 
OP
OP
Midramble

Midramble

Force of Habit
The Fallen
Oct 25, 2017
10,451
San Francisco
I don't know what the act could be called, but let's call these people 'programateurs'.

I like this.


For another example of the distinction, large custom excel vbscripts would be a subset of this as the application itself is authorized and scripting is inherent with data work but at some point the collective script morphs into an app of it's own. I've seen large operationally critical extremely slow project management tools cobbled together this way.

I guess I could title the policy section under "scripting" however it becomes difficult to differentiate in the policy itself that it's ok to write small scripts in batch/vb or whatnot for small automation but when it is to become an application it needs to be reported. Also would require a term definition of "scripting" to include coding languages like python, as I've seen a lot of that as well.
 

Faddy

Member
Oct 25, 2017
9,124
Are they actual programs or just userscripts?

How easy/quick could IT get these programs properly made? If you think this is a problem then run it up the chain and get these things done properly with someone employed to maintain them. Unless you offer a solution people are going to continue to roll their own solutions.
 
OP
OP
Midramble

Midramble

Force of Habit
The Fallen
Oct 25, 2017
10,451
San Francisco
Are they actual programs or just userscripts?

How easy/quick could IT get these programs properly made? If you think this is a problem then run it up the chain and get these things done properly with someone employed to maintain them. Unless you offer a solution people are going to continue to roll their own solutions.

Sometimes full programs (like the project management "suite" mentioned above) and sometimes just userscripts. I want to keep userscripts as part of the employee culture while nipping the latter in the bud. Not easy/quick to rewrite. Beyond that, even if it would only be moderately time consuming to rewrite, it has to fit in the dev sprint pipeline which gets it pushed even further to the back on priority where it becomes a debt timebomb.

It is a known problem I've inherited in many positions before. As IT Operations Director I've already gotten the exec team on board and now I'm down to writing policy to address it. The policy itself has mechanisms and thresholds for when something becomes an app that must be managed, the risk assessment (operationally and fiscally) that is required when reaching a certain stage, roles and responsibilities of other departments in handling or curbing the behavior, and ITOps roles and responsibilities in supporting it. I am all too aware that these homebrew solutions are a product of users not being given fitting solutions. For that reason I'm updating biztech procedures and policies including OLAs for tracking/metrics. As for this, I know what to do with the phenomenon hahaha I just don't know what to actually name it. The thing is I have to name it in a way that clearly defines it succinctly so it can be brought up in conversation and be a part of user culture. For the policy itself, the name is just useful for making the section title shorter while defining it in more detail in the body of the section.