• 0 Posts
  • 12 Comments
Joined 2 years ago
cake
Cake day: July 29th, 2023

help-circle

  • That your company has an in-house software dev team is impressive. Does the revenue-generating business have access to that team?

    Not OP, but in a similar situation. We have in-house dev for both tooling/infrastructure as well as revenue generation. For better or worse, leaders have neglected the software tooling and infrastructure that we use to build and deliver our revenue generating software for decades. Some serious cracks in the foundation showing and we might finally start fixing things.


  • I feel this in my bones. Even before the recent round of restructuring we’ve had a significant about of turnover. Our infrastructure is a massive rube golberg machine with multiple houses of cards built on top of it. Institutional knowledge was never written down and it has been leaving the company at an accelerating rate over the past 5 years. Tons of “new blood” making lots of assumptions on how things work is resulting in… humorous end results.









  • We have a test environment but it’s a hot mess. All the data is made up and extremely low quality. All the things you would normally interface with are also in test, but getting other teams to coordinate testing in the test space is… a chore. We do the best we can with mock services, but without having real services or representative data some of the data pattern assumptions don’t play out. Leaders value writing code and our lack of architects that span teams mean that when team architects either don’t meet ahead of time, make assumptions, or don’t ever agree on a design then…

    We always host UAT. We also track logins. Guess how many users even show up for UAT, let alone actually click on anything.

    This is why the vast majority of our testing happens in prod when our users are doing real work.

    Sorry for the baby rant :)


  • This can also be one of the frustrating parts of open source.

    Find something you don’t like? Fix it. Will the repo owner approve your pull request? Who knows. Maybe they’re a bit absentee. Maybe they view the original behavior as working as designed. Maybe your design doesn’t fit their architectural model, so they’ll (eventually) heavily refactor your changes and merge them in.

    You can always stand up a fork, but keeping those two at feature parity and going in the same general direction can become harder and harder with time.

    That’s not to say not to try! But it also means reaching out to the repo owners/maintainers before making your first change.