How do I, as a relatively new employee in the org, improve our development practices?

Posted by confusedanteaters@reddit | ExperiencedDevs | View on Reddit | 47 comments

4 YOE with 1 YOE in the company now. Our team (n=4) is very outdated in their dev skills I'd say. Our apps are all database-centered in terms of design and abstractions. Tables are poorly designed, no foreign key constraints, etc. Here are some concrete examples of specific pain points:

  1. Very slow development time due to database indirection and abstractions. Let's say we want to add a button to the screen, we can't simply do that. The frontend code is making a request to get data of this format:
    [
    { button_type: datepicker, button_text: Registration Date, styles: ... },
    { button_type: textfield, button_text: ..., styles: ...}
    ]

The database stored procedure that runs this code gives the UI data pertaining to buttons that is based on a \~50 line SQL query, which calls a DB function, which calls another DB function. There are times where implementing a simple UI button takes over an entire work day because while we insert the new button into the "buttons" DB table, there's obscure business logic with various dependent columns that prevents it from being rendered.

  1. Very difficult to make changes without break existing features. Last year, they made several abstractions while building the app. Now, when we build new features, we are required to reuse these abstractions. Except they frequently do not work with new features, so we have to mutate the abstractions to make them work for the new features without breaking existing functionalities. This results in a lot of the following:

if some_variable == "magic_string_related_to_new_feature" --> don't do original logic

Because all of this logic is embedded in DB stored procedures, it is extremely hard to follow and debug. Sometimes, trying to figure out why an API call is not returning an expected row will take hours/days. As you can expect, there are no tests anywhere. Our existing designs do not allow for unit testing because the .NET backend layer is just a tiny wrapper around the DB that does all the business logic. We cannot unit test the DB without superadmin roles, which is a no go.

  1. App is slow. We're talking 2-4sec rendering times for some API calls in our test environment with barely any data. Due to some of the issues mentioned previously, we keep mutating abstractions to try to fit new features. This results in a stored procedure returning a million fields that aren't needed. For example, let's say the stored procedure GET_FEATURE_DATA returns 20 fields related to feature_A. Now, we are adding feature_B that uses 15 of the original fields but also 5 new ones, we then modify GET_FEATURE_DATA to return 25 fields. This adds up. Some GET requests are returning over 100 fields and some POST payloads are sending over 100 fields.

To make things worse, the main app is new (1-2 years old), so they cannot excuse themselves by saying that they inherited a legacy app...they made it this way with intent. We're also an internal tools team so we're not exactly losing money due to bugs or poor performance. I didn't want to join a new team and be that one new guy that keeps insisting on changes, but at the same time, I'd like to make meaningful improvements. Some things I've done so far:

  1. Introduced git to the workflow...we were sending each other files on Teams before; they primarily use SVN so there's at least some VC (svn doesn't allow for remote branching).
  2. Began adding and encouraging various DB constraints to improve data integrity.