This article is a joke, but a joke cruelly missed by it's own author.
Point in case: holding 'enterprise programming' as a paragon of software craftsmanship.
A realization I've had, seeing true 'enterprise programming' at work, is that most of the time processes acts like pass-band filters for quality: on the lower side some sort of garbage is avoided by adherence to processes, and on the upper side true software excellence is made impossible, or at least way harder than it ought to be.
A few examples:
- A simple CRUD app got a less-than-ideal data-flow, with routing and data-passing between pages were treated as an afterthought. The reason? The (Scrum) process-heavy organization understood work solely as defined through JIRA tickets, and they naturally created 1 JIRA ticket per page and per component, and of course heavily parallelized the work between many coders. As a result, each page matched the specs, but the overall data architecture fell through the cracks.
- We had one member of a previous team who alternated between 'okay' to '-1x coder'. His main issue is that he didn't really thought about the impact of his code, he just kinda appeased the gods of linting until they were quiets. The issue is that it was often just breaking stuff, or straight up putting deceitful typing in a way that would have spread in the applications. Automatic checks were all in the green, but everything was subtly wrong.
- Over-engineered types in Typescript. Some (usually junior) ambitious programmers see the power of types, and dream of creating types so perfect that the whole program will be created just by pressing 'tab' at the end. It sometimes work, but it also often create ungodly monstrosity where a KISS approach would have been less painful. We've all went through this stage, but some people just saw "The sorcerer's apprentice" section of the 1940 Disney movie 'Fantasia' and then stopped midway, too busy automating everything.
- Over-reliance on outside library, and a organizational incapability of creating anything remotely custom. Yes you should avoid reinventing the wheels, but if your job is also to make wheels, and none of the ready-made wheels fits the situation, then you better be making wheels sometimes.
- Over-reliance on fads and marketing. Process-heavy environments penalize individual initiatives. As a result, the "way everybody do something" becomes the only possible way, and this is very susceptible to fads and content marketing. And your soul dies a little when you cannot stop the "Sure, Redux seems very heavy for the needs of this project, but Redux is very powerful! That's why it's in every project!".
In general, processes and systems attracts 'system people'. They can be useful, but too much will just create a dogmatic, un-pragmatic work environment where business consideration are swept under the room.
very good examples pretty much every one I've come across, the over-engineered types one (add python typing to the list too) feels pretty spot-on and common
Point in case: holding 'enterprise programming' as a paragon of software craftsmanship.
A realization I've had, seeing true 'enterprise programming' at work, is that most of the time processes acts like pass-band filters for quality: on the lower side some sort of garbage is avoided by adherence to processes, and on the upper side true software excellence is made impossible, or at least way harder than it ought to be.
A few examples:
- A simple CRUD app got a less-than-ideal data-flow, with routing and data-passing between pages were treated as an afterthought. The reason? The (Scrum) process-heavy organization understood work solely as defined through JIRA tickets, and they naturally created 1 JIRA ticket per page and per component, and of course heavily parallelized the work between many coders. As a result, each page matched the specs, but the overall data architecture fell through the cracks.
- We had one member of a previous team who alternated between 'okay' to '-1x coder'. His main issue is that he didn't really thought about the impact of his code, he just kinda appeased the gods of linting until they were quiets. The issue is that it was often just breaking stuff, or straight up putting deceitful typing in a way that would have spread in the applications. Automatic checks were all in the green, but everything was subtly wrong.
- Over-engineered types in Typescript. Some (usually junior) ambitious programmers see the power of types, and dream of creating types so perfect that the whole program will be created just by pressing 'tab' at the end. It sometimes work, but it also often create ungodly monstrosity where a KISS approach would have been less painful. We've all went through this stage, but some people just saw "The sorcerer's apprentice" section of the 1940 Disney movie 'Fantasia' and then stopped midway, too busy automating everything.
- Over-reliance on outside library, and a organizational incapability of creating anything remotely custom. Yes you should avoid reinventing the wheels, but if your job is also to make wheels, and none of the ready-made wheels fits the situation, then you better be making wheels sometimes.
- Over-reliance on fads and marketing. Process-heavy environments penalize individual initiatives. As a result, the "way everybody do something" becomes the only possible way, and this is very susceptible to fads and content marketing. And your soul dies a little when you cannot stop the "Sure, Redux seems very heavy for the needs of this project, but Redux is very powerful! That's why it's in every project!".
In general, processes and systems attracts 'system people'. They can be useful, but too much will just create a dogmatic, un-pragmatic work environment where business consideration are swept under the room.