←back to thread

343 points tareqak | 2 comments | | HN request time: 0.621s | source
Show context
umeshunni ◴[] No.44469492[source]
The 2nd most annoying thing about section 174 was all the time you had to spend classifying each engineer's time spent as R&D or 'internal software'. At my last company, every year, me and my engineering lead counterparts would spent almost a day reviewing each engineer's JIRA tickets to reconstruct how much of their time was spent on R&D vs internal software.
replies(3): >>44469570 #>>44470728 #>>44470877 #
supriyo-biswas ◴[] No.44469570[source]
At a previous employer, they used to have this process where they would classify each project as being in active development or being in maintenance, and even the tiniest bit of development work required the "initiation" of a "project" with budget planning and approvals.

At the time I dismissed it as a bureaucratic process invented by the company; after all, they had no dearth of leaders adding bureaucracy to systems for the purpose of empire-building and, to a lesser extent, asserting self-importance. However, upon reading about Section 174, it made some sense, and I wonder whether they might just get around to removing these processes.

replies(1): >>44469831 #
viraptor ◴[] No.44469831[source]
> and even the tiniest of development work required the "initiation" of a "project" with budget planning and approvals.

That's fully automateable though, right? Sounds like my script to upload a PR, create a JIRA ticket with the same name, link them up, auto-Done on merge.

replies(2): >>44470142 #>>44470519 #
1. samrus ◴[] No.44470142[source]
You cant automate the tactical assessment of "do we want to incur this tax?" Not easily anyway
replies(1): >>44472055 #
2. viraptor ◴[] No.44472055[source]
I meant most of the process and boilerplate being automated. Someone still has to go through the rubberstamping process, but at least the BS and clicks can come from the BS and clicks generator.