Hacker News new | ask | show | jobs
by civilized 951 days ago
You are absolutely right that the VBA prototype should be seen as a blessing. But no matter how you approach an IT development request - upfront or after the VBA prototype is created - the problem is always the same. IT wants a very, very long time to create something, or allow for the slightest change once created. And lots and lots of emails and meetings before any functionality even might become available (of course, complete failure is a very real possibility).

There is no way for the IT customer to negotiate this "correctly". It always leads to the same result.

The problem is IT exists to administer computer systems, not to help business people create or maintain software. This brings the wrong mentality and skillset.

1 comments

What my old team did (at a major Fortune 100 no less) was a bit unconventional.

They embedded a technical developer into a business team, and had that individual write the "kludgy" business apps that needed quick automation for throwaway tasks or for data processing standup. The dev has access to more than VBA, specifically, Python, GitHub, the ability to spin up what amounts to VPS's in the cloud with access to all of the database infra. All tools are shared with the rest of the company through a tech sharing program that is being heavily promoted across teams, and of course hosted in a repo, often with docs or a website if possible.

This "fills the gap" of dev latency for small dev tasks that don't necessitate pulling in an entire IT team. I don't really understand why this isn't more popular. The business team this individual was hired onto was over-the-moon when this occurred because they were doing absurd things like copy-pasting and hand-modifying JSON payloads many times a day and simply lacked the skillset to fix the problem, due to the issues you described. These issues were immediately resolved in under a month for hundreds of man-hours saved.

Just give business teams a tech resource that's well-trained and understands proper dev for on-demand work that doesn't justify the agile scrum whatever nonsense, and you won't end up with a forest of Excel macros.