Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Crost manglement.
-
It starts with "it's very simple", passes through "other tools have waaay to many features, ours neatly fits our needs" and ends with "it the way we always did it, I don't know how it works, it was the people who left who built it. we just need a smaaaal change"
Repeat this last part a thousand times. -
@Crost "if it pays enough, i don't care much" attitude
Related Rants
Two unit tests, no integration tests.
Small chaotic startup that never grew up (15 years atm).
Hosts/maintains a number of apps/sites for various customers.
At some point, someone decides that a CMS would be usefull to maintain the content across all products. Forgoing all sense, reason and the very notion of "additional maintenance and dev" it is decided that one should be built in-house.
Fast forward a number of years.
Ops performs routine maintenance on prod-servers. A java-patch accidently knocks out one of the pillars a 3rd party lib the CMS uses for storing images. CMS basically burst in to flames causing a.... significant incident.
Enter yours truly to fix the mess.
Spend a few days replacing the affected 3rd party lib. Run tests on CMS in test and staging environments. Apply java-patch. All seems fine.
When speaking to frontenders and app-devs, a significant hurdle present itself:
All test/staging instances of all websites/apps/etc ALL USE PRODUCTION CMS. Hardcoded. No way around.
There is -no- way to properly test and verify the functionality of any changes made to the home-brewed CMS.
My patch did indeed work in the end.
But did the company learn anything? Did they listen to my reasoning, pleading or even anguished screams for sanity?
No.
rant
cms
testing
java