[marcus_holmes]

I have nightmare stories to tell of Access Forms from my time dealing with them in the 90's.

The usual situation is that the business department hires someone with a modicum of talent or interest in tech, who then uses Access to build an application that automates or helps with some aspect of the department's work. They then leave (in a couple of cases these people were just interns) and the IT department is then called in to fix everything when it inevitably goes wrong. We're faced with a bunch of beginner spaghetti code [0], utterly terrible schema, no documentation, no spec, no structure, and tasked with fixing it urgently. This monster is now business-critical because in the three months it's been running the rest of the department has forgotten how to do the process the old way, and that process is time-critical.

Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that. We have to fix what we can and get it working immediately. And, of course, these fixes cause havoc with the project planning of all our other projects because they're unpredictable, urgent, and high priority. This delays all the other projects and helps to give IT a reputation as taking too long and not delivering on our promised schedules.

So yeah, what appears to be the best solution from a non-IT perspective is a long, long way from the best solution from an IT perspective.

[0] and other messes; in one case the code refused to work unless a field in the application had the author's name in it, for no other reason than vanity, and they'd obfuscated the code that checked for that. Took me a couple of hours to work out wtf they'd done and pull it all out.

[nradov]

Of course this is ultimately the IT department's own fault for not responding quickly enough to legitimate business requirements. They need to actively look for ways to help rather than processing tickets.

[marcus_holmes]

Yeah, this is always the response. But it's wildly impractical - there are only so many developer hours available. The budget is limited, so not everyone gets what they want immediately. This should be obvious.

Part of the problem is that the novices that create these applications don't consider all the edge cases and gnarly non-golden-path situations, but the experienced devs do. So the novice slaps together something that does 95% of the job with 5% of the effort, but when it goes wrong the department calls in IT to fix it, and that means doing the rest of the 95% of the effort. The result is that IT is seen as being slow and bureaucratic, when in fact they're just doing the fecking job properly.

[nradov]

In most organizations the problem is lack of urgency rather than lack of developer hours. The developers sit in isolated siloes rather than going out and directly engaging with business units. This is mostly a management problem but there are plenty of individual developers who wait to be told what to do rather than actively seeking out better solutions for business problems.

[marcus_holmes]

This usually comes back to maker time vs manager time.

If you want a developer to write good code quickly, put them in an isolated silo and don't disturb them.

If you want a developer to engage with the business units more, be prepared for their productivity to drop sharply.

As with all things in tech, it's a trade-off.

[TeMPOraL]

I think that's the lesser problem. The bigger problem is the attitude of IT is wrong from the start. When they start doing something, they want to Do It Right. They want to automate the business process. But that's the wrong goal! You can spend years doing that and go all the way to building a homegrown SAP, and it will still suck and people will still use their half-assed Excel sheets and Access hacks.

IT should not be focusing on the theoretical, platonic Business Process. It never exists in practice anyway. They should focus on streamlining actual workflow of actual people. I.e. the opposite advice to the usual. Instead of understanding what users want and doing it, just do what they tell you they want. The problem with standard advice is that the thing you seek to understand is emergent, no one has a good definition, and will change three times before you finish your design doc.

To help company get rid of YOLOed hacks in Excel and such made by interns, IT should YOLO better hacks. Rapid delivery and responsiveness, but much more robust and reliable because of actual developer expertise behind it.

[thyristan]

> They should focus on streamlining actual workflow of actual people.

If you streamline a shitty process, you will have diarrhea...

Unfortunately, most processes suck and need improvement. It isn't actually IT's job to improve processes. But almost always, IT is the only department that is able to change those processes nowadays since they are usually tied to some combination of lore, traditions, spreadsheets and misused third-party software.

If you just streamline what is there, you are cementing those broken processes.

[nradov]

Actually there is no trade-off. That's a common misunderstanding. Reducing latency creates more business value than increasing productivity.

http://lpd2.com/

[thesumofall]

That depends if one measures productivity in LOCs or business impact. As always, it’s not black or white, but my experience is that higher proximity is a net benefit

[scott_w]

> In most organizations the problem is lack of urgency rather than lack of developer hours.

I disagree: it's a business prioritisation issue (not necessarily a problem). Ultimately, a lot of the processes are there because the wider business (rightly) wants IT to work on the highest impact issues. A random process that 3 people suffer from probably isn't the highest impact for the business as a whole.

Also, because it's not high impact, it makes sense that an intern is co-opted to make life easier (also as a learning experience), however it also causes the issues OP highlighted.

The problem is solvable, I think, but it's not easily solvable!

[HeyLaughingBoy]

Yes, but often the "business priorities" get so screwed up that people's needs go unmet, and the business ends up wasting money as a result.

My best example was a conversation I had with one of the scientists at my job when she mentioned that she had people spending hours every day generating reports from data our instruments produced. I pointed out that with the code we had it would be simple to generate the reports automatically.

Her response that she had asked repeatedly for a developer to be assigned to the task, but she kept being pushed away because it was low priority.

I couldn't just change the codebase on my own (it was for a medical device), but it was easy enough to spend a lazy afternoon writing a tool to consume the output logs from the device and generate the reports that she needed. That's it: about 4 hours of work and produced something this person had asked for a year prior, and that people were already spending hours each day doing!

The people in charge of vetting requests never even bothered to ask a developer to estimate the task. They just heard that there was a work around, so it immediately became "low priority."

[scott_w]

> That's it: about 4 hours of work and produced something this person had asked for a year prior, and that people were already spending hours each day doing!

This leads to the exact problem OP brings up: who fixes it if it breaks? If it becomes critical, now other priorities go unhandled as a person or team are dragged into resolution.

I’ll bring a couple more counter arguments:

- When I was running an internal enablement team, I reckon I had 12 months worth of work of these simple requests at any given point in time.

- Even that time saving might not be worth it, if it means those 4 hours could have been spent building something the company can sell (which for a SaaS product, is literally millions over its lifetime).

Just to be clear, I’m not saying you did the wrong thing at all. Hell, I’ve done this stuff myself. I’m just pointing out it’s not as easy as “just spend 4 hours on it and it’s done!” I’d go on but I think I’d just end up regurgitating the article.

[listenallyall]

> wildly impractical - there are only so many developer hours available

Which is a huge reason that learning a RAD (rapid application development - emphasis on rapid) tool is a pretty useful skill.

[bccdee]

What makes it rapid is taking shortcuts. There's no silver bullet for increasing speed while preserving maintainability and extensibility. Prioritizing speed is exactly the problem described in the post you're responding to.

[listenallyall]

Not implementing any solution and blaming it on "only so many developer hours available" is the problem I'm responding to.

I'm not "prioritizing" anything. The scenario we're discussing is when an intern or low-level employee is able to successfully automate, enhance, or simplify a manual, inefficient business process that management has not seen fit to improve - so the worker does it themselves.

Access and similar platforms aren't "rapid" because of shortcuts, they are rapid because they are visual-based, drag-and-drop, object-oriented and often make a component's properties and methods customizable also via a visual interface. It's a different way of programming, yes, accessible to the masses (which is likely the reason you have so much disdain), but not "shortcuts".

[bccdee]

I don't have a problem with accessible development tools like that, but they do have tradeoffs. An Excel spreadsheet is an excellent tool for some business calculations, but once you start asking questions like, "can we add some authorization to this? Can we add some permissions? Can we pipe this into a UI?" we've passed the limits of Excel and we need to implement a real application. The more you implement in your spreadsheet, the more you may end up re-implementing in a real database.

[RobotToaster]

Which is ultimately the c-suite's fault for not requiring that and allocating a budget for it.

[nradov]

Nah. It's usually a culture and organizational structure problem, not a budget problem.

[chasd00]

This has been my experience. Usually a department gets nowhere for months dealing with IT and then goes shopping for consultants. I make my living bringing things online for directors and other biz leadership who just couldn’t get IT off their ass.

[ozim]

Downside is that it quickly turns to idea people coming over directly to dev team pushing BS ideas and requiring work to be done on that ASAP.

You need a structure if you have org of 100+ employees. If it is smaller than that I don’t believe you get dev department.

[loki-ai]

more often than not it’s the development team that skips engaging with users, putting in minimal effort to understand their real needs.

most of these teams only wants a straightforward spec, shut themselves off from distractions, just to emerge weeks or months later with something that completely misses the business case. and yet, they will find ways to point fingers at the product owner, project manager, or client for the disaster.

[marcus_holmes]

I have met the occasional person like this, sure. But only ever in really large organisations where they can hide, and only a minority.

The huge majority of devs want to understand the business and develop high quality software for it.

In one business I worked for, the devs knew more about the actual working of the business than most of the non-IT staff. One of the devs I worked with was routinely pulled into high-level strategy meetings because of his encyclopaedic knowledge of the details of the business.

[TeMPOraL]

The mistake is in trying to understand the business case. There is nothing to understand! The business case is the aggregate of what people actually do. There is no proper procedure that's actually followed at the ground level. Workflows are emergent and in constant flux. In this environment, the role of a dev should not be to build internal products, but to deliver internal hacks and ad-hoc solutios, maintain them, modify on the fly, and keep it all documented.

I.e. done right, it should be not just possible but completely natural for a random team lead in the mail room to call IT and ask, "hey, we need a yellow highlighter in the sheet for packages that Steve from ACME Shipping needs to pick on extra evening run, can you add it?", and the answer should be "sure!" and they should have the new feature within an hour.

Yes, YOLO development straight on prod is acceptable. It's what everyone else is doing all the time, in every aspect of the business. It's time for developers to stop insisting they're special and normal rules don't apply to them.

[skydhash]

It would be nice if the computers could be that nice to work. It’s a completely dumb machine that needs everything spelled out. Humans are very flexible. To get flexibility out of a computer require great effort.

The main reason you want a computer is cheap emulation (cad, daw,…) or fast (and reliable) automation. Both requires great deal of specifications to get right.

[TeMPOraL]

That's not what most people use computers for at work. And it's not what magic Excel sheets and Access forms are made for.

[skydhash]

Are you sure? Almost all excel sheets are emulations of some process. They’re not great at it, but they work better than the alternatives. But organizations need automation more than emulation, i.e. they want to improve their process, not merely replacing them.

[bccdee]

The thing about that is that you can only ever YOLO the superficial layers of your architecture, and only ever in certain ways. Having a YOLOable system requires deliberate and considered architectural choices deeper down.

[TeMPOraL]

YOLOable systems are built out of flexible pieces. That's why Excel "abuse" is a constant theme in enterprise :).

We should not be thinking about architecture at the business process level. This is just repeating the mistake that needs to be avoided here. This is, and will ever be, a pile of ad-hoc hacks. They're not meant to add up to a well-designed system in a bottom-up fashion, because there is no system to design. The structure we naturally seek, is constantly in flux.

The right architectural/design decisions to make here is to make it possible to assemble quick hacks out of robust parts that fulfill additional needs the people on the ground may not consider - logs/audit trail/telemetry, consistency for ergonomic reasons, error handling, efficient compute usage, tracking provenance, information access restrictions dictated by legal obligations, etc.

The most important change needed is in the mindset. Internal dev needs to stop thinking of itself as the most important part of the company, or as a well-defined team that should own products. To be useful, the opposite is needed - such devs need to basically become ChatGPT that works: always be there to rapidly respond to requests to tweak some software by people on the ground, and then to retweak is as needed. They need to do this work rapidly, without judgement, and never assume they know better.

Only then people will stop weaving ad-hoc Excel sheets into business-critical processes.

[HeyLaughingBoy]

An hour is a stretch, but otherwise, yeah.

[savolai]

And yet, even ”knowing about the working of the business” is different from actually understanding user needs at UI level, which involves a lot more variables.

The single most valuable tool is user testing. However it really takes quite a few rounds of actually creating a design and seeing how wrong you saw the other person’s capabilities, to grok how powerful user testing is in revealing your own biases.

And it’s not hard at all at core. The most important lesson really is a bit of humility. Actually shutting up and observing what real users do when not intervened.

Shameless plug, my intro to user testing: https://savolai.net/ux/the-why-and-the-how-usability-testing...

[swader999]

This legit triggered me. I'm thirty years in now and only two failed projects. My first paid work was an access project for a small business and it failed and I didn't get paid. Luckily I kept trying.

[GTP]

> Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that.

I assume those processes weren't applied when deciding to use this application, why? Was there a loophole because it was done by an intern?

[dspillett]

Simple things, or even complex prototypes, get created in office apps because the office apps are their, have the flexibility, and you don't need to get IT to install something new (or allow you to), or convince finance to let you pay for something new, or convince compliance/security/other than the something new is safe anyway, etc. Also in a larger company, once the discussion of developing or buying something comes up lots of other potential stakeholders might raise their heads above the parapet and want to get involved (“Could our dept use this too?”, “We would need it to do Y as well as X…”, “That sounds useful, but it should be us doing it instead”, etc.), and suddenly the quick PoC that has been barely started has become a series of interminable meetings.

The loophole is that if you have Office or similar you have a variety of development environment, IT/compliance/finance aren't caring what files you produce with the applications you have, and no one else is paying attention initially either, but would have a say (and a procedure for you to follow) if you wanted to bring in or create a new application. The usual process is bypassed.

This is more commonly associated with Excel, but it applies to Access too (less so than it used to, but there are still plenty people out there who rely on it daily).

Once the demo/prototype/PoC is there it is a lot easier to “fix up” that than spin up a project in anything else, or get something else in that is already available, for the same reasons as why it was done in Excel/Access in the first place plus the added momentum: the job is already at least part way done, using something else would be a more complete restart so you need to justify that time as well as any other costs and risks.

[Note: other office suites exist and have spreadsheets & simple DBs with similar capabilities, or at least a useful subset of them, of course, but MS Office's Excel & Access are, for better or worse, fairly ubiquitous]

[rob74]

Well, if someone (especially an intern) who is not in the IT department decides to write an application, it's pretty obvious that they are not familiar with (and therefore won't follow) the processes of the IT department. That's the problem with these more "democratic" development environments: if something is beginner-friendly, beginners will use it...

[jyounker]

Another point of view is that the IT department isn't meeting the users' needs, and that they're bypassing IT because they just want to get their work done.

[GTP]

Yes, the intern will not follow the procedure, and likely isn't even technically required to do so. But, before the application becomes a tool actually used inside the company, there should be some quality control done.

[listenallyall]

Think of the management structure which arranges, and is satisfied with, tedious, repetitive, manual paper-pushing processes - such that an INTERN can immediately see the efficiency benefits that would come with automation, and doesn't just suggest doing so, but actually builds a program (in limited intern timeframe), that is so helpful it's quickly picked up by multiple employees.

Then think again of those managers getting paid manager salaries who couldn't figure this out themselves - or worse, the ones who want to shut it all down because he didn't "follow the procedure" (the procedure of not doing anything useful???)

[GTP]

Shutting it down due to a technicality about not following a procedure != shutting it down because it is an unmaintainable mess, while also tasking IT with implementing the same core idea, but in a proper way.

[listenallyall]

Lol, define "proper". If they were so knowledgeable, why hadn't they implemented something before the intern arrived?

[makeitdouble]

> The usual situation is that the business department hires someone with a modicum of talent or interest in tech

This reminds me of the "just walk confidently to their office and ask for a job to get one!" advice. This sounded bullshit to me until I got to stay with some parts of a previous company, where the hiring process wasn't that far really.

That's also the kind of companies where contracts and vendor choices will be negociated on golf courses and the CEO's buddies could as well be running the company it would be the same.

I feel for you.

[listenallyall]

Imagine taking a shit on a technology platform which made it easy for interns with zero experience to successfully automate key aspects of business processes!

Love the assumption "when it inevitably goes wrong." In real life, many of these applications work perfectly for years and assist employees tremendously. The program doesnt fail, but the business changes - new products, locations, marketing, payment types, inventory systems, tons of potential things.

And yes, after the original author is gone, nobody is left to update the program. Of course, a lot of programmers or IT folks probably could update it, but ew, why learn and write Access when we can create a new React app with microservices-based backend including Postgres in the cloud and spin up a Kubernetes cluster to run it.