Because devops deemphasizes documentation in favor of "working code" you effectively build a project or department that can never be replaced, because the cost of your on boarding for new hires (eg, months and months if not years of word-of-mouth training) is untenable.

During churn or turnover, the goal is again, "working code" so every new hire is going to ignore the existing undocumented build environment and create a new one.

Eventually you're a ship of Theseus with 3 Dev environments that all sorta work, and an immutable automation that sorta tests, and 2 leads that have been there for a decade and don't need to give a shit about new hires because if the boss angers them and they leave, the project is sunk beyond recovery.
Follow

@Nimbius666 I think a robust test suite helps with this. I think a well designed test explains code better than comments ever will and also gives immediate feedback on how changes affect function, which is invaluable for new team members onboarding.

· · Web · 1 · 0 · 0
@RegalBeagle @Nimbius666 nah let's just go with "the code is self documenting" and toss the juniors at it.

@7666 @Nimbius666 Certainly easier to tell that to management vs actually creating a testing suite.

@RegalBeagle @7666 this level of degradation transcends the code. It is endemic to every team that adopts devops.

Network layouts are ignored because their specific rationale was never documented. Build flags become holy sigils because your teams are too terrified to remove them. Eventually even naming conventions for environments are abandoned because no one remembers how or why they were ever created.

The Dev environment now has two naming conventions and 3 vlans across 2 subnets and datacentres because a migration effort was abandoned and the only senior Dev maintaining it is six weeks from retirement and checked out.
Sign in to participate in the conversation
Merovingian Club

A club for red-pilled exiles.