This is exactly what I see happening at the team I'm working at. Nobody really seems to notice that it's happening though. I try to bring it up sometimes but being the most junior developer on the team I don't really have many concrete experiences and examples with which to back those arguments up, so it can be difficult to articulate. Also I don't want to come across as thinking I know better than everybody else. It's kind of frustrating.
you just described me. Newcomer to a team and the codebase is just really freaking hard to read, in order to understand 1 functionality, i need to have 10 different files open at the same time to jump back and forth to try to understand what is being done. I have spoken up a few times, given that I'm a shy person inherently. I dont really care about what needs to be done to refactor the code, bu I care about the fact very few developers think that its a problem.....
Head up dude! There are many organizations and you will find your place. Please 🙏 do not stop asking questions and bothering seniors. I'm a software team lead and constantly encouraging juniors to be yourselves
Believe me, they know. They know very well. They are just not paid to care. I have no idea where you work, but I can confidently say that if youcheck your company and project KPI's and see how many of them relate to short term profits and how many on long term sustainability, you'll see all of them in the former and zero in the latter. So why would the project team risk their bonus and maybe even employment doing something that will not reward them? Instead they will push stupid middle managment targets. I've seen that everywhere, its ubiquitous and not only in IT. Evey industry I had contact with, had the KPI's being set by people who do not know shit about the technical process invloved, so they cannot even think of long term goals. And then they make suprise Pikachu face when things go to shit and start "streamlining the process" (firing half the staff) and "reorienting the business directon" (selling off their shares/company and bailing) leaving the line workers to fend for themselves. Then they get hired by new company, and process repeats. And they get rich in the process ofc, because why would you not get richly rewarded for running company after company into the ground.
I don’t even wanna talk about what’s wrong with or how to maybe fix our current system with my seniors, I just wanna get outta there asap. It’s too far gone, it serves no compelling purpose anyways and honestly the company doesn’t deserve anything better. It’s probably as least as much managements fault as it is my predecessors and seniors tho tbh.
I've learned so much from your videos, thanks! It's great how clearly you can explain these relatively abstract concepts and still make it relatable to actual pieces of software that we encounter. My 2 cents: I think that this data-first mentality mostly propagates from the initial proof of concept phase, at least in the corporate world. Software projects may start as a way to make it easier to interact with collected data - product catalogues, time management systems, customer satisfaction, business monitoring. When a new project is conceptualised, it's generally thought from the perspective of 'I want to see X and Y data' as initial requirement. On the developer's side, this is easy and quick to implement as a CRUD application with database models as api resources. No issues or behaviour descriptions on the horizon. Then, as you're working towards a MVP or got a green light for continuing development, that's when the 'actual' business requirements slowly get discovered over time. But, as we're already approaching it from a data-centric PoV it's difficult to change the perception of both team and stakeholders towards a behaviour-centric mentality. So we continue building what we are familiar with, and since every other system we've worked with does it this way, we rarely challenge this mindset (until stumbling on a video like this that is). Especially since we're often working 'agile' in 2-week sprints with deliverable increments, it's actively discouraging people to take a step back and re-evaluate their goals. While I despise excessively detailed planning and processes, I really dislike the current focus on delivering short-term value over looking ahead at where you're going. It's like we're tailgating on a highway and then being surprised when we might crash into an oncoming traffic jam. We need to spend time and work closely with analysts in the team, so we can better understand our user's behaviours/requirements and what business capabilities extend from that.
We mostly code from a data-first, single table angle like you showed. If the single table becomes too unwieldly, we refactor at that point. I tend to err on the side of relying on refactoring and evolution than starting with things all split up. But I find lots of developers are hesitant to change a design of just about anything once it exists. I would argue doing the easy thing can go both ways: you could not split up something like Product when it becomes too unwieldly, or you could decide not to combine Product when an aspect of it becomes non existent. There was an article going around that a bad abstraction is worse than no abstraction. People seem to mostly take that to mean "don't abstract". But their point was that you need to be willing to ruthlessly chop up the current design if it is no longer fit for purpose. Obviously depending upon the scope of your team and those depending upon your project this may not work out - you might have to do more upfront thought and split everything out ahead of time. But one thing I always try to beat (metaphorically speaking) into juniors is that the current design is not holy, and you can rip it up if new features require it. As an aside, this whole problem with something like "Product" feels like it's played out across a lot of software industries. I'm reminded a bit of the games industry that went through their phases of "god objects" to entity-component to the currently popular (but not really well understood) entity-component-systems design. Really it's all about splitting up a single "thing" into multiple slices to reduce cognitive load for developers. When you have lots of little different "things", or a single small "thing", the answer is obvious - that's OOP 101. But when you have a single large "thing" with multiple aspects it can be difficult for some people to do what needs to be done, and in unfamiliar domains drawing the correct boundaries can be difficult.
Great video. I really appreciated that you were honest with your bit about managing technical debt by always having some crap present since it seems impossible to have a system without some kind of tech debt.
My co-workers are like this ... Every time I try to get them to follow good practices, they get angry at me for, apparently according to them, wanting to over optimize. Apparently choosing clear names is ... Over optimization. Or keeping functions and components small. I've given up, so our code is now a hard-to-change spaghetti mess
I think simplifying the problem of Technical Debt and "Quick" Changes/Fixes down to coupling/cohesion and data modeling is missing out on the actual problems, which take different forms in different companies or teams. Sure you pointed out one potential problem, but the problem with only covering one potential problem is that it makes it seem like that's the fix for everyone.
I don't think a complex topic like this can be covered in a 10 minute video. I hope there is a thread in my video's which is to be pragmatic and think for yourself given your own context. Based on your comment, you realized that I mentioned a single potential problem or reason for technical debt. I'd assume that others will do the same and see their own context and situation to understand that of course there are others reasons. I don't think I put a "THIS ONE TRICK SOLVED ALL LIFES PROBLEMS" in the title?
It is far too common that there is no such effort in making sure that code quality is being upheld. You can blame it on management not being clear enough or even putting pressure on you to finish tasks - in the end, it is up to the developers to make sure that the code that they write is good code and that unnecessary complexity in both code and dependencies are not added.
Agree. It can be pretty difficult if you don't have ownership or feel pressure from management. Everyone needs to be on the same page, which can be incredibly difficult.
I've seen a company churning developers due to unrealistic and unhealthy pressure for a huge project. By trying to micromanage a few weeks off the development time, it easily increased the total time with years and a bug ridden delivery.
@@CodeOpinion I have been in a couple of strict projects that have to follow planned tasks. I don.t work well in them. I have learned to be flexible, that usually doesn’t work. The management requires clear direct communication and status updates. A lot of meetings to clear stuff up. It is not what encourages the best out of software developers. If you are flexible, then you separate the knowns from unknowns and don't let that stop you. Do what you can do, leave it, and return when you have what you need. For instance, details in how to integrate with another system. Mock it. Strict projects require you to progress by handling tasks and not to iterate within the current iteration. I think that experience also plays a part in this.
@@BboyKeny I’m leaving such a project now. The management is pressured by the customer and their increasing demands. It is a big project and many teams to coordinate. A lot of unknowns. I have my opinions about development approach and code quality.
Yup went on a two week vacation came back and saw a bunch of hardcoded shit. Divergence from our standards. Single use services that mutated an object based on context. Yeah... Took more time getting that shit over the line than it did to fix it in the next sprint which comprised of deleting a bunch of code and fixing w damn query.
So this video is about turd management... understood 😂 Now seriously, I'm a big fan of refactoring culture which is basically build something that is uncertain, take some time to let it mature and then re-work or refactor that in a better way. Excellent video!
I am trying to apply this way of thinking about technical debt in my case. We have class that basically is stateful object. This stateful object is storing its state in redis. I am seeing that we are adding more and more to the state. The code is getting more and more complicated. So basically if I apply the same pattern here I should try to divide up the state and let the state be managed by several classes? Or maybe first define behavior and then create state after the behaviors?
This is a very difficult challenge especially as engineers progress in their career. Negotiating time to do things right when it is needed, and getting more POCs out the door in the hands of customers to see what "sticks". Sometimes I write stuff that just dies in production and I'm glad I didn't spend too much time trying to make it a creampuff piece of code. Sometimes stuff takes off and technical shortcuts get in the way when it needs to be extended or scale. I think I've come to the conclusion this is simply the nature of the beast, and learning based on experience is just that, something to learn from and reflect on, and also to be reactive based on the culture of a specific job or company. Communication is a challenge if you are trying to tell a customer-facing roll that you can get something out but will need more work if it takes off and needs to be extended, as often this invokes selective memory of conversations. Using your project tracking software for written notes and backlog item creation can sometimes be an aid, and a less aggressive but tracked way to remind people of trade offs in timeliness and thoroughness. No quick hacks here on how to do that, it takes experience, and takes some contextual knowledge of the business and culture. As you say in the other comment, it's a much deeper topic than a single video, but good points throughout.
100% communication is a huge problem, and organizations are usually aware about it, but tech debt is a shy problem which engineers don't like to share and owners don't want to hear about
Another good video that I agree 100% with. One comment/question though. If you think about the product catalog and having a team responsible for that alone I would imagine they being responsible for the search page as well. For a search page to function well you need data from other systems as well. Would you recommend having the catalog subscribe for data from the other system or would you create some aggregator service that is responsible for the data for the search page?
A small amount of tech debt can be a good thing, if you are aware of it and repay it consistently. The problem is when there's always pressure for new features and it's difficult to find the time to pay back existing tech debt. If you can't get time to pay back tech debt, it's better to try to avoid it in the first place. This is ultimately slower but it's not as bad as a mountain of tech debt that stops you completely.
This is exactly what I see happening at the team I'm working at. Nobody really seems to notice that it's happening though. I try to bring it up sometimes but being the most junior developer on the team I don't really have many concrete experiences and examples with which to back those arguments up, so it can be difficult to articulate. Also I don't want to come across as thinking I know better than everybody else. It's kind of frustrating.
I feel ya
you just described me. Newcomer to a team and the codebase is just really freaking hard to read, in order to understand 1 functionality, i need to have 10 different files open at the same time to jump back and forth to try to understand what is being done. I have spoken up a few times, given that I'm a shy person inherently. I dont really care about what needs to be done to refactor the code, bu I care about the fact very few developers think that its a problem.....
Head up dude! There are many organizations and you will find your place. Please 🙏 do not stop asking questions and bothering seniors. I'm a software team lead and constantly encouraging juniors to be yourselves
Believe me, they know. They know very well. They are just not paid to care.
I have no idea where you work, but I can confidently say that if youcheck your company and project KPI's and see how many of them relate to short term profits and how many on long term sustainability, you'll see all of them in the former and zero in the latter. So why would the project team risk their bonus and maybe even employment doing something that will not reward them?
Instead they will push stupid middle managment targets.
I've seen that everywhere, its ubiquitous and not only in IT. Evey industry I had contact with, had the KPI's being set by people who do not know shit about the technical process invloved, so they cannot even think of long term goals. And then they make suprise Pikachu face when things go to shit and start "streamlining the process" (firing half the staff) and "reorienting the business directon" (selling off their shares/company and bailing) leaving the line workers to fend for themselves.
Then they get hired by new company, and process repeats. And they get rich in the process ofc, because why would you not get richly rewarded for running company after company into the ground.
@@gloowacz omg, first time somebody speaking as I do, so I'm not thinking bullshit
This channel is criminally underrated.
😂 spread the word and share! Appreciate the comment
I don’t even wanna talk about what’s wrong with or how to maybe fix our current system with my seniors, I just wanna get outta there asap. It’s too far gone, it serves no compelling purpose anyways and honestly the company doesn’t deserve anything better. It’s probably as least as much managements fault as it is my predecessors and seniors tho tbh.
I've learned so much from your videos, thanks! It's great how clearly you can explain these relatively abstract concepts and still make it relatable to actual pieces of software that we encounter.
My 2 cents: I think that this data-first mentality mostly propagates from the initial proof of concept phase, at least in the corporate world. Software projects may start as a way to make it easier to interact with collected data - product catalogues, time management systems, customer satisfaction, business monitoring. When a new project is conceptualised, it's generally thought from the perspective of 'I want to see X and Y data' as initial requirement. On the developer's side, this is easy and quick to implement as a CRUD application with database models as api resources. No issues or behaviour descriptions on the horizon.
Then, as you're working towards a MVP or got a green light for continuing development, that's when the 'actual' business requirements slowly get discovered over time. But, as we're already approaching it from a data-centric PoV it's difficult to change the perception of both team and stakeholders towards a behaviour-centric mentality. So we continue building what we are familiar with, and since every other system we've worked with does it this way, we rarely challenge this mindset (until stumbling on a video like this that is).
Especially since we're often working 'agile' in 2-week sprints with deliverable increments, it's actively discouraging people to take a step back and re-evaluate their goals. While I despise excessively detailed planning and processes, I really dislike the current focus on delivering short-term value over looking ahead at where you're going. It's like we're tailgating on a highway and then being surprised when we might crash into an oncoming traffic jam. We need to spend time and work closely with analysts in the team, so we can better understand our user's behaviours/requirements and what business capabilities extend from that.
We mostly code from a data-first, single table angle like you showed. If the single table becomes too unwieldly, we refactor at that point.
I tend to err on the side of relying on refactoring and evolution than starting with things all split up. But I find lots of developers are hesitant to change a design of just about anything once it exists.
I would argue doing the easy thing can go both ways: you could not split up something like Product when it becomes too unwieldly, or you could decide not to combine Product when an aspect of it becomes non existent.
There was an article going around that a bad abstraction is worse than no abstraction. People seem to mostly take that to mean "don't abstract". But their point was that you need to be willing to ruthlessly chop up the current design if it is no longer fit for purpose. Obviously depending upon the scope of your team and those depending upon your project this may not work out - you might have to do more upfront thought and split everything out ahead of time. But one thing I always try to beat (metaphorically speaking) into juniors is that the current design is not holy, and you can rip it up if new features require it.
As an aside, this whole problem with something like "Product" feels like it's played out across a lot of software industries. I'm reminded a bit of the games industry that went through their phases of "god objects" to entity-component to the currently popular (but not really well understood) entity-component-systems design.
Really it's all about splitting up a single "thing" into multiple slices to reduce cognitive load for developers. When you have lots of little different "things", or a single small "thing", the answer is obvious - that's OOP 101. But when you have a single large "thing" with multiple aspects it can be difficult for some people to do what needs to be done, and in unfamiliar domains drawing the correct boundaries can be difficult.
Nodding in agreement.. 😀
Great video. I really appreciated that you were honest with your bit about managing technical debt by always having some crap present since it seems impossible to have a system without some kind of tech debt.
Thanks. Everyone wants or has a vision of a gold plated system that is perfect. It's not happening. And that's ok! But still push to make it better.
My co-workers are like this ... Every time I try to get them to follow good practices, they get angry at me for, apparently according to them, wanting to over optimize.
Apparently choosing clear names is ... Over optimization. Or keeping functions and components small.
I've given up, so our code is now a hard-to-change spaghetti mess
Yikes. That's a bummer.
I think simplifying the problem of Technical Debt and "Quick" Changes/Fixes down to coupling/cohesion and data modeling is missing out on the actual problems, which take different forms in different companies or teams. Sure you pointed out one potential problem, but the problem with only covering one potential problem is that it makes it seem like that's the fix for everyone.
I don't think a complex topic like this can be covered in a 10 minute video. I hope there is a thread in my video's which is to be pragmatic and think for yourself given your own context. Based on your comment, you realized that I mentioned a single potential problem or reason for technical debt. I'd assume that others will do the same and see their own context and situation to understand that of course there are others reasons. I don't think I put a "THIS ONE TRICK SOLVED ALL LIFES PROBLEMS" in the title?
It would be great Brandon to see your scenario. I had before in a same situation as Derek. Data coupling is much too often problem
It is far too common that there is no such effort in making sure that code quality is being upheld. You can blame it on management not being clear enough or even putting pressure on you to finish tasks - in the end, it is up to the developers to make sure that the code that they write is good code and that unnecessary complexity in both code and dependencies are not added.
Agree. It can be pretty difficult if you don't have ownership or feel pressure from management. Everyone needs to be on the same page, which can be incredibly difficult.
I've seen a company churning developers due to unrealistic and unhealthy pressure for a huge project. By trying to micromanage a few weeks off the development time, it easily increased the total time with years and a bug ridden delivery.
@@CodeOpinion I have been in a couple of strict projects that have to follow planned tasks. I don.t work well in them. I have learned to be flexible, that usually doesn’t work. The management requires clear direct communication and status updates. A lot of meetings to clear stuff up. It is not what encourages the best out of software developers. If you are flexible, then you separate the knowns from unknowns and don't let that stop you. Do what you can do, leave it, and return when you have what you need. For instance, details in how to integrate with another system. Mock it. Strict projects require you to progress by handling tasks and not to iterate within the current iteration. I think that experience also plays a part in this.
@@BboyKeny I’m leaving such a project now. The management is pressured by the customer and their increasing demands. It is a big project and many teams to coordinate. A lot of unknowns. I have my opinions about development approach and code quality.
Yup went on a two week vacation came back and saw a bunch of hardcoded shit. Divergence from our standards. Single use services that mutated an object based on context.
Yeah... Took more time getting that shit over the line than it did to fix it in the next sprint which comprised of deleting a bunch of code and fixing w damn query.
So this video is about turd management... understood 😂
Now seriously, I'm a big fan of refactoring culture which is basically build something that is uncertain, take some time to let it mature and then re-work or refactor that in a better way. Excellent video!
Turd Management. That's accurate.
I love the way you say the same thing in couple of different practical ways.
binge watching all your videos sinces weeks, every day
thanks for your work 👍
Glad you like them!
I am trying to apply this way of thinking about technical debt in my case. We have class that basically is stateful object. This stateful object is storing its state in redis. I am seeing that we are adding more and more to the state. The code is getting more and more complicated. So basically if I apply the same pattern here I should try to divide up the state and let the state be managed by several classes? Or maybe first define behavior and then create state after the behaviors?
Splitting up the behavior that relates to the same underlying state.
This is a very difficult challenge especially as engineers progress in their career. Negotiating time to do things right when it is needed, and getting more POCs out the door in the hands of customers to see what "sticks". Sometimes I write stuff that just dies in production and I'm glad I didn't spend too much time trying to make it a creampuff piece of code. Sometimes stuff takes off and technical shortcuts get in the way when it needs to be extended or scale. I think I've come to the conclusion this is simply the nature of the beast, and learning based on experience is just that, something to learn from and reflect on, and also to be reactive based on the culture of a specific job or company.
Communication is a challenge if you are trying to tell a customer-facing roll that you can get something out but will need more work if it takes off and needs to be extended, as often this invokes selective memory of conversations. Using your project tracking software for written notes and backlog item creation can sometimes be an aid, and a less aggressive but tracked way to remind people of trade offs in timeliness and thoroughness. No quick hacks here on how to do that, it takes experience, and takes some contextual knowledge of the business and culture. As you say in the other comment, it's a much deeper topic than a single video, but good points throughout.
Ya, it's a giant topic and the dynamic between management and dev teams is an interesting one.
100% communication is a huge problem, and organizations are usually aware about it, but tech debt is a shy problem which engineers don't like to share and owners don't want to hear about
great video, the one problem we have and discuss it constantly ..
Another good video that I agree 100% with. One comment/question though. If you think about the product catalog and having a team responsible for that alone I would imagine they being responsible for the search page as well. For a search page to function well you need data from other systems as well. Would you recommend having the catalog subscribe for data from the other system or would you create some aggregator service that is responsible for the data for the search page?
I'm going to be finally converting this soon, which is about UI/View Composition.
🤯🤯🤯 100% spot on.
Great video. Havent seen a topic like this very much
Glad you liked it!
thank you so much for you videos
how i can access to discord channel ?
Join as a member on Patreon or TH-cam.
www.patreon.com/codeopinion
th-cam.com/channels/3RK.html...
A small amount of tech debt can be a good thing, if you are aware of it and repay it consistently.
The problem is when there's always pressure for new features and it's difficult to find the time to pay back existing tech debt.
If you can't get time to pay back tech debt, it's better to try to avoid it in the first place. This is ultimately slower but it's not as bad as a mountain of tech debt that stops you completely.
Yup. I never even touched on the pressure to "push out features" from non-developers (eg managers).
Proper testing (e2e) will allow you to modify the app with confidence :)
Yes, testing absolutely helps regression. But not necessarily preventing you from over time building a highly coupled mess.