191–200 of 421 posts
– It’s built in. – The IDE is built in. – The syntax is beginner-friendly. – It’s stable and doesn’t change every six month. – It’s well-documented. – No build steps, it just runs, and fast. – It’s resource-efficient (CPU, RAM). – You can easily create dialogs and forms using the built-in visual GUI builder. – You can break into the built-in debugger from your Office document. – If you want to get fancy, it has inter…
Let's face it: IT is the bureaucracy department of modern times which can keep itself 95% busy with self inflicted problems and has 5% service orientation. Processes are opaque for outsiders and typically not helpful. I really had to lough when I read the following description of the IBM BPM but this sums up a good part of the issue: "...while IBM BPM does come with a REST API, this REST API is borderline useless to…
VBA is the ultimate agile programming language. The company's IT aka Bureaucracy Department is stuck with Scrum, Squads and what not. And meanwhile in the other departments people are just getting things done with Excel/VBA. Nothing has changed. In the last century this also happened and it was called islands of automation. In my bubble back then it was considered a good strategy, let departments first play around, a…
Earlier quoted context omitted.
This. My friend automated his whole job in Excel. He supposedly can do a days work in fifteen minutes and then just hang out. Their computers are super locked down, can’t install anything, can’t go to any non-whitelisted sites, but they have Excel.
I always read those “X automated their job, finishes it 15 minutes and then does whatever” and wonder how true are they? How could it be that nobody notices or cares?
They were slower, but they also chit chatted with half the office, went to lunch, etc.
Their jobs consisted of pulling some data from here or there, entering it into excel, sending a few emails, entering some data into another system, printing some checks. All stuff that's easy to automate (you'd probably need more than Excel in this case)
Earlier quoted context omitted.
And rightly so. Imagine for a moment that someone in accounting built a system in lisp to automate part of his job. As time goes on, he takes on more responsibility, which he writes more lisp for. One day, he gets hit by a bus. The lisp program he wrote is now an integral part of the running of the accounting department simply by accumulation and momentum, with tons of business logic baked in. Where do you look to fi…
this already happens with Excel and access. Entire companies rely on a spreadsheet some wizard invented years ago and now no one knows how to change it, and it goes weird if multiple users try to access it at once so make sure you copy it locally first and change the file name so you can track the versions
– It’s built in. – The IDE is built in. – The syntax is beginner-friendly. – It’s stable and doesn’t change every six month. – It’s well-documented. – No build steps, it just runs, and fast. – It’s resource-efficient (CPU, RAM). – You can easily create dialogs and forms using the built-in visual GUI builder. – You can break into the built-in debugger from your Office document. – If you want to get fancy, it has inter…
– It’s built in. – The IDE is built in. – The syntax is beginner-friendly. – It’s stable and doesn’t change every six month. – It’s well-documented. – No build steps, it just runs, and fast. – It’s resource-efficient (CPU, RAM). – You can easily create dialogs and forms using the built-in visual GUI builder. – You can break into the built-in debugger from your Office document. – If you want to get fancy, it has inter…
- It's what's available.
There is a bit baked into this statement which the article breaks down further:
- Companies won't approve anything else in the hands of ordinary users
- Companies' developers are too busy with too high priority items
And some things not mentioned in the article are also baked in:
- Even when developers get around to a project that could replace VBA, they don't understand the project, underestimate the time and resources required, and deliver a subpar product as a result
- Companies lay off people doing work IT and developers can't be bothered to support with no real plan other than overburdening the remaining ordinary users with extraordinary problems
– It’s built in. – The IDE is built in. – The syntax is beginner-friendly. – It’s stable and doesn’t change every six month. – It’s well-documented. – No build steps, it just runs, and fast. – It’s resource-efficient (CPU, RAM). – You can easily create dialogs and forms using the built-in visual GUI builder. – You can break into the built-in debugger from your Office document. – If you want to get fancy, it has inter…
Earlier quoted context omitted.
Worth also pointing out that sometimes when you're in a corporate dystopian hell hole do not expect to be able to actually request or install software on your device. What is there is what you have and trying to get it changed is an exercise in taking on the bureaucracy. It's not worth it. Many people have tried and failed. Back in the dark ages, we had a horrible reporting engine in Word VBA that pulled report defin…
What you call monkey hammer is actually the “golden hammer,” or “law of the instrument.” Idk if that matters to you, but it’s an already defined thing. https://en.m.wikipedia.org/wiki/Law_of_the_instrument
Earlier quoted context omitted.
I can find bad examples of how things work in basically every department I chose if I look long enough. Are there IT-Managed things that border on insanity? Oh yes. Are these a good excuse to build a shadow IT? No, they are not. Don't get me wrong: I'm not bothered at all when a couple analysts get together and hack away at their own little tools in VBA. Kudos to them for getting into the spirit of things, and maybe…
Shadow IT exists for a reason and that's the dysfunctional bureaucracy of IT. The "Circle of IT" is real. Small companies start out nimble, but then stuff gets crazy and someone decides to standardize it all under one department. This works for awhile, but eventually this organization becomes so useless that it can't serve any functions of the business anymore, so a shadow IT group is built that the business SMEs lov…
I am not here to talk about management-bureaucracy, of which IT depts; same as all other branches one can find in established corporate culture, have more than enough.
I am talking about the perceived "bureaucracy" of us tech guys here, aka. following established procedures to ensure smooth running of mission critical systems.
Yes, I want things to run through code reviews. Why? Because these things go to a production system that our customers (and thus the companies income) depend on. Yes, I want authentication standards. Why? Because there are a gazillion cryptolockers, and worse, out there, who would love nothing more than to run rampant on a nice and juicy production database.