The way I heard it the law is only enforced when someone complains, and then only against the person that was complained about. That probably boils down to "not enforced" for most people, though, especially if most of the folks one is dealing with are convinced that software engineering isn't engineering within the meaning of the act. It's only slightly terrifying that serious legal trouble is plausibly just a public complaint away for me and plenty of other software developers. At least I have the excuse that I don't provide any services to the public whatsoever. :laugh:

Memtha wrote:

Since the other comments have established there is little to no relevant laws,

That's the $10k question though. Do the engineering licensure requirements written into state law (in the US, they may be at a different level in other countries) apply to people who work in software and choose to call themselves software engineers? The answer varies some from jurisdiction to jurisdiction, but to my non-lawyerly eye it looks like the answer may well be "Yes" in most or all US States, although lots of developers would probably fall into one of the exceptions written into the various laws and the rest would only be in trouble if someone actually decided to complain to the proper authorities. You'd have to talk to an actual lawyer to get a really reliable answer, though, preferably one that deals with engineering licensure issues. After all, it doesn't matter what you or I think ought to be the law or what we think the law means. It only matters what the legal system says the law means and will back up with stiff penalties.

All in all Jira's pretty decent as long as you either have an extremely experienced and empowered Jira admin running it or strictly follow the rule that anyone proposing complex and/or extensive customizations shall be summarily executed. Jira's problem is that it was designed to be flexible enough to handle pretty near any conceivable workflow including all the weird rules teams can come up with about moving tickets from one state to another (like only when Joe the manager has moved this other ticket to state B, which requires a third ticket to be in state Z, and only when the day of the month is prime). Once you've got workflows that complex, you can't hardly change anything without the whole thing breaking down, and heaven forbid you create more than a few custom fields or worse custom fields with the same name. One of the things I do at $dayjob is Jira administration, but they didn't make any attempt to contain the complexity early on so I've seen more than my fair share of Jira horrors. Anyway, Atlassian basically succeeded at making a super-flexible ticketing system at the expense of mind-boggling complexity, although reverse engineering the class hierarchy and relationships would probably make a decent project for a 500-level OO Design class. Oh, and keep your Jira small or it gets ridiculously expensive, especially since you pretty much have to get add-ons for it to work well. VSTS/Azure DevOps seems better to me for development teams, but business-only or help-desk teams would almost certainly be better off in Jira.