I can't say I've worked anywhere as strict as that, however I'll say that like any other career field, there are good and bad work places. Places that like to overly restrict things are going to lose good developers, and likely don't pay well to begin with.
I worked for Meta/Facebook for a year before I got laid off last year, and I'll say that it was very much not like this. While you had regular projects and whatnot going on, you were free to make changes you thought were necessary or good changes to make. Now I didn't work on anything public facing, as I'm certain there are certain controls on making changes to what users can see, but otherwise any change just required approval from any other developer, and it would make it into production 6 hours or so later.
On Thu, Apr 25, 2024, at 12:58 PM, David Schwartz via PLUG-discuss wrote:
>
> > On Apr 25, 2024, at 11:49 AM, trent shipley via PLUG-discuss <plug-discuss@lists.phxlinux.org> wrote:
> >
> > I think we're seeing the effect of Arizona being a provincial, 3rd world location for headquarters and software development options.
> >
>
> I don’t think this is the case. Anybody who’s ever worked for a company committed to getting ISO 900x and CMMI certificated knows these programs are designed to remove variability and unpredictability from the workforce. That’s fine for manufacturing, but CMMI in particular strives to make programmers at all levels fungible — that is, easily replaceable.
>
> We do have a lot of big companies with their SW Dev HQs here, and they are very committed to meeting these “standards”.
>
> I worked at a place a while back that was working on getting CMMI Level 3, and they started pushing all sorts of ridiculous policies on us that were all outgrowths of CMMI mandates.
>
> One was that every line of code changed in the source had to tie back to a specific change request, and be commented as such. Thus, general refactoring on-the-fly was no longer allowed.
>
> During this time, I found evidence of over 100 bugs based on visual code inspections and tried mightily to get them fixed. Their policies said that only the client can submit bugs and they must be accompanied by documentation that showed exactly how to reproduce said bugs in order for us to fix them. Even though the Dev Team supposedly “owned” the backlog (under general Agile practices), we had no access to it or the ability to add to it. Most of these bugs were data-dependent and would be impossible to reproduce. To make matters worse, the errors they generated were all downstream and it was impossible to tie those errors back to the code errors I discovered.
>
> Moving up CMMI’s ladder requires a company to remove variations between individual developers and ensure that anybody with the requisite skills can be put into a job role and accomplish the same work as the previous person without any variations.
>
> This is where a lot of big corporations are moving towards, and this will have the net effect of turning most of us into robots — and probably being easily replaced by AI bots.
>
> When you write a software app, there’s a period of time when the code is being constantly revised and optimized. At some point, someone waves a magic wand and declares it’s “stable enough” for a release, and that code becomes instantly calcified under CMMI rules. From that point on, it cannot be touched without specific directives, either from the customer(s) or someone in charge of that stuff.
>
> There are growing numbers of SW Dev Managers who are opposed to unfettered code refactoring and “bug fixes” done by programmers because they believe their code changes create as many bugs, if not more, than they fix. Of course, regular code reviews would fix that, but I’ve never worked in a place that did code reviews, even though they touted them as a supposed “regular (best) practice”.
>
> Programmer time is expensive, and they don’t like wasting it.
>
> CMMI’s approach meets two goals: (1) reduces risk; (2) lowers costs.
> ---------------------------------------------------
> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list:
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)