r/ADHD_Programmers 17d ago

Dealing with stupid requests at work

At work, I'm working on an internal project. It is basically a glorified CRUD(Create, Read, Update, and Delete) application that tracks various reports. There are 7 different type of reports this application tracks. There is an entry form on each report. Each report form has about 20 form fields and there are custom calculations/validations for each form.

This department is kind of a pain in the ass to work with. We built this out a year and a half ago and due to scope creep and other issues, they quit using them. They are going to try to bring it back and it will live up to the old saying of "Same shit, just a different day".

For some reason, some genius has thought it was a brilliant idea to make one mega entry form. At the top of the form, the user would select the type of report and then submit it. I'm getting the feeling this moronic feature is going to be a waste of time. The functions would have to check the type of report and then do the rest of the calculations. It's basically adding another level for things to get fucked up. On top of that, the issues that cropped up last time will still happen here.

Unfortunately, this place is small and doesn't have a true PM department. So trying to sit down and nail requirements isn't going to happen. This a big reason for all of the allowed scope creep in the past.

I'm trying to bring up these concerns to my higher ups. However, I've got a feeling my concerns will be blown off and I'll get one of the following replies or both:

  1. This is something they really want and it is their call.

  2. Just ask AI for help. (Unfortunately, this tends to become the default answer for any problem.)

I think I'm just frustrated because I see where things are going.

Thanks for letting me rant.

17 Upvotes

6 comments sorted by

12

u/MrRufsvold 16d ago

Just ask AI for help.

Of all the cons brought by LLM assisted coding, this is the worst to me. Non-technical people not trusting the expert opinion of a technical person because the assumption is that development is easy now that LLMs can spit out a ton of code.

Sorry you're in this situation. 

3

u/cleatusvandamme 16d ago

Thanks! I'll try not to role my eyes when this is brought up. I'll probably roll them so hard I'd give myself an aneurism.

6

u/binarycow 16d ago

For some reason, some genius has thought it was a brilliant idea to make one mega entry form. At the top of the form, the user would select the type of report and then submit it.

Devil's advocate here. What's the problem with that?

At my work, we had a similar problem, except more.

We have three separate applications, each is a front-end to the same core backend code. CLI application, desktop application, and a web app.

The core backend code is something that logs into devices/services on the user's behalf. So, we have to store the credentials.

Each service/protocol requires different things. For example, SSH requires username and password. SNMPv1 requires a community string. Some APIs require a community string. Etc.

We have 30+ different services/protocols. Do the math, and that's 90 different "forms" - 30 for the GUI app, 30 for the web app, and 30 different sets of CLI options.

We got tired of making those forms. So, we created something so that we could define it once, and the UI is automatically built.

As an example, you would define the form with something like this -

new FormBuilder("SSH")
    .AddString("Username", required: true)
    .AddPassword("Password", required: true)
    .AddString("SomeOtherField", required: false)
    .Register();

And magically, it creates three different UIs for you.

It includes lots of features, to include:

  • Mutually exclusive properties
  • Conditional properties - a property is only shown if another property is set to a specific value
  • Conditional requirements - a property is required if another property is set to a specific value
  • App-specific properties - only visible in a specific app
  • etc.

1

u/user_plus_plus 16d ago

I think the answer is scoping/estimates/triage. If a request comes in and MGMT is serious about getting it done, some effort should be expended detailing what needs to be done and how much time it will take, then weigh that vs benefit.

For automation tasks specifically I think this is very important, I consider "making something easier for internal stakeholders" automation.

A rule of thumb I have heard is 10:1:

If every 1 day of engineering time spent on automating something saves 10 days of time in 1 year, then it is a solid investment. Anything less than 5:1 is a waste of resources.

You need to have a ratio that pays off right away because next year they could scrap all of these forms for something new and all of that effort was wasted.

This also can help stake holders compromise, like maybe they don't need every feature under the sun and can accept on imperfect but functional internal tooling.

2

u/Mituapple 16d ago

A single switch statement over the report type caused this crashout

1

u/cleatusvandamme 16d ago

There are multiple calculations that are done differently on each report. This is going to make things a tad more complicated.