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:
- 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.
- 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.
- 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:
- 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).
- Began adding and encouraging various DB constraints to improve data integrity.
visicalc_is_best@reddit
Whatever you do, DON’T do a few things:
Instead, make your list of improvements PRIVATELY, assess your list honestly for potential impact (“does this REALLY make things better? Can it be measured and proven?”), pick the one with the HIGHEST impact, measure before state, implement the change yourself, measure after state, and then HUMBLY publicize the hell out of the quantified improvement.
Then rinse and repeat, one impactful thing at a time, until you’ve got the credibility to make a sweeping rearchitecture proposal.
confusedanteaters@reddit (OP)
How do you go about proving and quantifying improvements? I would have to create a different branch of an app and spend a non trivial amount of time implementing something "my way" to show the performance difference. Would this be how you'd go about doing it?
Zulban@reddit
If the biggest low hanging fruit will take a non-trivial amount of time then the code base is not nearly as bad as you make it out to be.
Wonderful-Habit-139@reddit
This makes sense on its own but are you really going to say that for an app that fetches buttons from the db?
Zulban@reddit
There is no app on the planet that does something that bad but doesn't also have trivial to implement improvements.
Conscious_Support176@reddit
BadOf course there will be low hanging fruit, and tackling those may get you credibility, but will they help with the bad quality code? Pretty much by definition, this is code that is hard to change, because of high coupling etc.
ShoePillow@reddit
Looking at the items op mentioned in the post, I can't see how they would take a non trivial time to fix, because the code base is a mess.
Do you have any examples of low hanging fruits from your own experience?
Zulban@reddit
If it's really that bad then there are also trivial to implement improvements. You never see projects with huge design problems but no smaller, low hanging fruit problems as well. OP's understanding of the project doesn't seem to be adding up.
ShoePillow@reddit
I'm looking for any examples that you or anyone else on the forum has come across.
I don't think it is vague, I'm interested in literally any thing you have to offer.
horserino@reddit
Here is a generic low hanging fruit for this specific example:
Make it easier to add a "button" to that weird DB thing. How do you do that? For starters, add documentation and tests to make that "dependent obscure business logic" clearer and not obscure anymore. There, low hanging fruit.
Once that is done you can more safely decide if some of that can be trimmed or have a better idea if it's even worth re-doing in some other way.
You can do the first step privately, everyone benefits from it. Then you also get a better view of some of the obscure code which is the first step into reworking/fixing/rewriting any amount of non trivial existing code in an app.
Conscious_Support176@reddit
Yes makes a lot of sense to do this, but it’s unlikely to be low hanging fruit. It’s likely to be a moving target littered with edge cases that don’t deliver any real business value, but will still take a significant effort just to capture them all accurately.
visicalc_is_best@reddit
Bravo!
visicalc_is_best@reddit
Depends, that’s definitely one way, but it’ll vary and require a good degree of creativity. The benefit is that you’ll have solid data to back up your opinion, which builds credibility and silences critics.
opideron@reddit
Agreed. Find the low-hanging fruit. Look for examples of current issues that are arising because the code is fragile. Propose a really obvious way to make it less fragile without changing it too much. Code architecture changes presented as solutions to specific, measurable problems are much easier to digest than big overarching changes that require a lot of buy-in.
mistyskies123@reddit
I bet that part of the reason the code is like this is everyone is too scared to make changes to it, for fear of what might/might not happen.
alohashalom@reddit
> suggest that your ancestors were idiots
You mean this is bad practice? Every SWE I've ever worked with does this.
eviltalkingpie@reddit
Fully agree, but I will add that I see these as the first pass filters. There are more complex questions to ask yourself about the company too. I've had a hard time with my current company that I'm now looking to leave, because ultimately you also need to understand the culture and politics of the place and sometimes it's just not possible to change as one person recently joining the team. It's actually the culture and leadership mindset where you need to make your changes, and you will get no-where if you can't will the political fight and sway the culture of the whole team. It's unfortunately never as simple as just 'fixing the code'.
ThlintoRatscar@reddit
sigh I have done all of these.
Can confirm - doesn't work well.
"I have seen the enemy, and it is me."
Additional-Bee1379@reddit
This. I have had several instances where trying to convince people something was a good idea and to allocate some time took more effort then just making the PR and asking 'I made it, do you want it?'
alohashalom@reddit
Not your circus
horserino@reddit
Lisp languages, a.k.a "code is data" languages would like a word :p
Wooden-Glove-2384@reddit
You work for idiots.
You may possibly be the smartest guy in the room
However you're new and you're young and the entrenched and stupid do a great job nacking each other up.
GrogRedLub4242@reddit
why is there a database table for buttons?
Additional-Bee1379@reddit
Some attempt at making a content management system is my guess.
snchsr@reddit
Double this with the same guess. Probably, at some earlier point of the lifecycle of their system they intended to built UI that should’ve been manageable via admin panel or so.
GrogRedLub4242@reddit
this is the most generous interpretation of its origin, yes
otherwise it reeks of poor engineering
dead-fish@reddit
This had me cracking up. Exactly what I was thinking though. I can’t even imagine the cursed design pattern that created this madness.
Particular-Cloud3684@reddit
Thank you lol, I was so confused when I read that. I've never heard of that in my life.
Is that an extremely old way of doing something? I cannot even think of why that would be true, even 30+ years ago.
confusedanteaters@reddit (OP)
There are many moments of me asking "why are doing it this way" around these neck of the woods unfortunately. Not that I'm advocating for this design choice, but one of the proposed advantages is easier deployment. Want a new button to pop up on your toolbar? Just write a DB script to insert the row into a table. No need to deploy anything. Again...I am not advocating for this.
OhMyGodItsEverywhere@reddit
Easier for anyone intimately familiar with the DB schema and its stored procedure logic, but no one else! Sounds like a hollow, magical sales pitch: "poof! instant new button! no code changes! easy!" ...right... Someone apparently bought that pitch.
Easy deployment practices exist across the industry that aren't so error-prone and gives you so much more development velocity. Sounds like somebody there is really, really comfortable with databases and running the show.
confusedanteaters@reddit (OP)
Bingo. It's easy if you just happen to know why something isn't working.
If you don't, you have to read through hundreds of lines of SQL to try to trace through why a button isn't showing to find out that a bit column somewhere is set wrong.
Alternatively, you guess why it's not working because you think a column somewhere is set wrong based on the name of the column. If you're lucky, changing the column will result in the intended behavior in the UI. Well what about potential side effects? That's tomorrow's problem.
Particular-Cloud3684@reddit
Huh. That's extremely interesting. Not in a good way, but I was genuinely curious and couldn't think of why that would ever occur haha.
Today I learn! I wouldn't ever implement a solution like that, but it's interesting nonetheless.
markvii_dev@reddit
I'd just leave or divorce myself from the project and try to work on something else.
At this stage in tech, I would have thought everyone was aware that relying on data to effectively program your application was an anti pattern - so if they are still using it, it's probably because a Lead or Architect still thinks this is the correct pattern and they deserve the codebase in all its glory.
NecessaryExpensive34@reddit
The interesting thing about these kinds of platforms/codebases is that the people working on them actually start to like it that way, since they invest a lot of time into learning how to do productive work and how to build workarounds. This develops over time into a kind of hero complex where the devs think they are on the top of their game for delivering any product feature since it's so complicated, when in reality their general skills / knowledge are falling behind since they are usually stuck in old tech stacks that they can't improve / upgrade.
This leads to a situation where new people come into the org and are like "omg this is insane why do you live like this", but the existing people see any change as a threat. These are difficult situations that are usually only resolved with strong backing from management, new eng leadership and usually a few ICs leaving who can't emotionally handle the change.
I think you as an individual can have very little impact, and you should focus on learning as much as possible (good or bad lessons), reducing friction with your co-workers and lobbying for small improvements where you think there won't be much resistance to change. Make sure you keep your skills up to date, even if the company is behind, and look for something better as the job market improves in a year or two.
Main-Drag-4975@reddit
OP, you’re stunting your growth if you’re anywhere close to being the best at your shop this early in your career. Find some better mentors, find a better job.
Doom_Taco@reddit
This. If you're always the smartest person in the room, it might be time to find a better room.
confusedanteaters@reddit (OP)
Yeah...I agree with you. Market's rough out there unfortunately.
themilkyninja@reddit
Dan Luu is always insightful, and his Normalization of Deviation post is relevant here.
OhMyGodItsEverywhere@reddit
Thank you for this. Some highlights that hit home:
ActiveBarStool@reddit
in my experience, unless it's a very small org/company (<100 people), you won't. just accept the chaos & work with their practices otherwise your coworkers will start to despise you for organizing their chaos
OhMyGodItsEverywhere@reddit
Even if you're in a smaller company you still might not be able to make the change - so long as you have 1 person who is allowed to trump your suggestions and they would rather do things as they always have (for personal or financial reasons).
There's a better chance of skill rot at a place like this than making any change - unless OP finds themselves in a more clear leadership role on the team.
If I had to guess, the described pain points are needlessly self-inflicted from stubbornness to learn how to competitively build modern software, or the group is put under such unrealistic delivery conditions that they cannot afford to learn.
They're making a brand new application that already has the legacy issues of a 20 year old design without the compounded business value such an old program would provide. I don't see how that's sustainable. Allowing something like this to exist in the first place, especially without tests, seems like a massive blunder by the original author and management.
I guess if the tool is not meant to be that important, and the company can tolerate the slow development and debugging cost, maybe there is a future at this company where that tool gets avoided for the toxic ball of junk that it is, and you would be able to introduce better dev practices on future products. But I wouldn't count on that happening.
My advice to OP would be to work on resume updates and interviewing, as bad as the market might be. A different company would almost certainly offer better opportunity. Other comments give some good advice on how to manage the existing job in the meantime.
Your job shouldn't have to be a full-time uphill battle to get your group to where it should have been a decade ago when there's actual software to build instead. Heck, maybe OP can check in on this company in a few years and see where they're at - and if they got better they can get another shot.
Comprehensive-Pea812@reddit
you don't. you need at least one year to gain respect and get people to listen to you after understanding the organization constraint and being in the same boat.
until then you are just a newbie who just wants to change everything for your own convenience
Fluid_Classroom1439@reddit
Dude this is wild. Unfortunately I’ve gone down the road of showing an org how things can be done 10/1000x better and it’s almost impossible to land that message without everyone hearing you are wrong instead of this approach is wrong.
If you did want to show how this could be done then I imagine you could spin up an alternative site relatively quickly. Maybe the smart way to do this would be to couple it with a technology migration the entire team is on board with. Then just backdoor all the simplifications during the migration.
Honestly I would just find a new role. This company will go out of business. Not tomorrow but at some point their incompetence will catch up with them. If you were CTO or would be your job but almost anything below I would just keep my area clean and crack on.
Good luck! I’ve never heard of ui components constructed via db stored procedures 🤷
Empanatacion@reddit
I'm guessing there's a guy who's been there for twenty years and this is all his code.
adilp@reddit
Not gonna get any better. Technical Leadership has to do it by being empowered by management. That way everyone has no choice but to get on the train. As just a coworker, it's just not worth it. Been there done that. Those people have been living that way forver and probably have shown they will never change and will fight it. If anything they will start to hate you for trying to introduce change.
wirenutter@reddit
Man I hate to admit it but this is the truth. I’ve got a lot of grit but sometimes pushing for change just wears you down so bad. I’ve had success on small incremental changes but sometimes it’s like playing whack a mole.
TurboBerries@reddit
Write a doc explaining the problem and your proposed solutions.
One thing you need to understand when pitching this is what does it actually save you in business terms? Is this app still being developed? Is it on KTLO? How much dev time is being spent on it and how much can be saved with your ideas? Does the loading times have a huge customer impact?
Sometimes it doesnt make sense to fix everything on an app thats not worth investing into. However you can take those learning (using your doc) as a design starting point on what to do and not to do when developing something else.
Just remember that business needs come before development best practices so dont get butt hurt if you get push back.
The smaller stuff like git and dats constraints sure feel free to make improvements in your downtime but run it by your sr/lead devs to see if there was a reason that wasn’t done in the first place.