[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.

[TeMPOraL]

That's precisely the mistake I'm talking about. You think you're smarter than people on the ground, and know better how they should do their job.

It's because of that condescending, know-it-all attitude that people actively avoid getting IT involved in anything, and prefer half-assed Excel hacks. And they're absolutely right.

Work with them and not over them, and you may get an opportunity to improve the process in ways that are actually useful. Those improvements aren't apparent until you're knee-deep in mud yourself, working hand by hand with the people you're trying to help.

[littlecosmic]

In my experience, it’s often the business side - rather than IT - that tries to use a technical change to force change to the business process that they have failed to change politically… and it usually turns out that a technical change isn’t enough either.

[skydhash]

The problem with hackish solution is that they get put in places they don’t belong. In other professions, there’s regulation in place to prevent these kind of shortcuts.

Also, if you have ever worked with anyone trying to get specifications worked out, you’ll see that most people (including devs) rely on intuition rather than checklists and will always forget to tell you something that is critical.

The thing is that cost of changes in the business can be a simple memo. But for software that usually means redesign.

[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.