This has been boiling in the back of my mind for a while now. A lot of developers talk about antipatterns, patterns, good practices and bad practices. But I rarely hear about how did a bad practice get established during the development process. Or in general, how do various tendencies work during software development.
Firstly I will start about features in general, in applications. Not all features are equal in an application, some of them are core part of the applications functionality. And usually these features are known by all the developers in the team, because the application can't work without them. Now imagine that a developer needs to do a new feature in the application similar a bit to a core functionality. Where will he look for ideas and inspiration about how to code the new feature? Of course in a similar core feature known by everyone.
So these core features are used as reference a lot of times. Now his can be a good thing or a bad thing depending on how those features are coded. If they have a bad design with plenty of antipatterns, then there is a very good chance that those bad practices will get copied into new features. But they can also have good design with good ideas. In this case, they will have a positive impact and encourage developers to use those practices and designs. And it's not just core features that can be used as reference but other clear, simple features which are easy to understand and figure out the code for them. Or when an application is developed from scratch, then the initial features of the application will be used as a reference.
Or when completely different and new feature is implemented in an application, then subsequent features similar to the new one, will have as a reference the new and completely different feature.
As a general rule, these reference features should be identified as early as possible in the application and then reviewed to see if they serve as good models and examples for the rest of the application.
Secondly, there is another case in which patterns and practices can be copied. When starting to use a new technology in an application, then the way of working with it and the patterns which are applied using that technology will also be copied later when new features will be developed using those technologies.
For example, at my previous project we started using a new ORM, Entity Framework Core. When we started using it, we also implemented a new pattern that works really well with that technology, the repository pattern. Then as we developed more features with Entity Framework Core, we looked at the initial feature that was developed with it and copied the same style, including the repository pattern. This in turn was a good thing because that pattern made writing unit tests easier.
Thirdly, when changing an existing piece of code, then that code and the code around it can be used a reference when making some changes. If a developer is adding new code to a feature, and that feature is coded like crap, then there is a very good chance that the new code will also be crap. Then things will get worse and worse from there. The code will become more and more confusing and harder to understand. Things can get ugly really fast. And eventually, things will be so convoluted ugly and complicated, that no one will know how that feature should have been actually coded, and a complete rewrite is required. I have seen this numerous times. It can get so complicated that it will be almost impossible to change without clearing up the code.
Sometimes, at some point in time a feature would have been well coded. But with many small changes that add crappy code or are themselves crap, the features loses it's structure and coherence, becoming a big bloated mess. I have seen this too happen. It's much more likely to happen with many small bad changes which are more likely to be overlooked at code reviews or during development. And if there are enough, they keep pilling up, changing the entire structure of the feature. Eventually there is tipping point, at which the coherence and structure is lost completely. After that, things go from bad to worse and eventually to an atrocious halt. So when changing existing features, adding new code to it, it important to keep the structure and coherence of that feature. That feature should have a sense of style to the code and structure. This is actually closely related to the broken window theory which actually has real implications in software development too.
Fourthly, an application might have a specific structure so that it allows news features to be developed in a specific way. Usually, it has some points of extensibility when parts of a functionality that meet a given criteria can be plugged in, in a controlled manner. These entire applications can be just a series of plugins that are loaded into a bare skeleton sometimes. The soul purpose of the core of the application is to link, load and allow plugins to communicate with each other. I worked a bit on some plugins for Visual Studio and Autodesk Maya that worked like this.
And there are some specific architectures that forces developers to plug in new functionalities at specifically designated points like "hexagonal" "architecture". But I haven't really worked with them, I just read about them a bit and then forgot about them, because they have too many pompous bullshit words in them like "architecture" in them which makes me run away from them.
Or inside an application, a generic skeleton of a specific kind of feature might be defined, which then can be further implemented and extended to create a concrete feature. Or several of these feature skeletons can be defined which then can be extended and filled in to create a new feature. For example, in some applications, for data access a generic base class is usually defined with some generic operations, that can be customized or extended with new functionalities. At my current project we have specific components that we can inject our content into which follow a specific pattern. One of these components is the layout functionality from Asp .Net MVC Core. Another one is a custom functionality that follows a pattern used in web called a "portlet".
Or a complete framework can provide the base skeleton for a kind of application which then can be extended and customized in a specific way to make for example a website using Asp .Net MVC if you are from the .Net world or Spring I think if you are from the Java world.
Usually, there is a combination of some of the things mentioned above that establish a specific way to develop an application.
And fifth, developers can have influence on one another. Some developers might be a bit of rivals. In this case, they will tend to scrutinize and criticize each others code and design more often. This can be a good thing because a lot of times it can help them come up with better ideas if they work together. But it can also be a bad thing, because they might take things too far and they will burn out, exhaust themselves and become frustrated. I can relate to this pretty well, as it happened a couple of times to me, and it didn't turn out good for me or the other developers.
Other developers can be really friendly and close to one another. This can be good or bad. For example with such a developer with whom I got along really well, we tended to agree to each other crappy and idiotic ideas, actually encouraging one another stupid ideas sometimes. This didn't turn out too well a lot of times. On the other hand, with some developers with whom I got along easily and well, we actually enjoyed helping each others, coming up with suggestions about how to improve each other's design, code and ideas.
Another case can be with a junior developer that thinks an older and more senior developer is cool. In this case, he has a higher chance that he will use the work of the more senior developer as reference. If the more senior developer makes a stupid mistake, then the junior developer might copy that stupid mistake. I think it is a good idea for a more senior developer to set up good explicit good examples for junior developers that admire him for one reason or another. And a lot of times, this more senior developer can be the actual team lead. Which is a very good thing. I think there are a lot of dynamics and factors that influence how a developer can admire and copy another developer. A developer might end up copying another developer, because he likes the same TV shows or films, they talk about those a lot, so it comes more naturally for them to be more interested in each other's work. I mean it's a lot easier to look at the work of someone you get along with, because even if you don't understand it, you have much more ease asking the other person with whom you get along with, to explain that code.
Sometimes, when two developers who don't get along or are shy with one another need to work together on various parts of a feature that need to interact and work together. Because of the reasons mentioned above, they will hesitate to communicate with each other. Instead they might assume that the other person thinks exactly the same as them, to give them an excuse not to interact with them. So they will make decisions based on those assumptions . But the can assume exactly the opposite things when designing their components. And those components need to work together to become a feature, it will be a glorious crap. Or it might not work at all. Either way, the feature will not work at all as designed, after each developer working 2 weeks on those components. I have seen this a couple of times and I laughed a lot at it, but it sure wasn't desired. That's why developers do activities together like ping pong, team building, chatting during breaks and so on, to become more comfortable with one another, to have the right level of cooperation and collaboration.
In the end, we should also focus and become aware of the tendencies we are establishing during the development process so we can curb bad tendencies. And surprisingly, a little bit of psychology plays a major impact on these tendencies. Now there are more mechanisms through which tendencies are established and work, I am still learning about them. But it is important at least to be aware of them, so that when you figure out a new one, you can learn to replicate it or curb it depending if it's good or bad.
Firstly I will start about features in general, in applications. Not all features are equal in an application, some of them are core part of the applications functionality. And usually these features are known by all the developers in the team, because the application can't work without them. Now imagine that a developer needs to do a new feature in the application similar a bit to a core functionality. Where will he look for ideas and inspiration about how to code the new feature? Of course in a similar core feature known by everyone.
So these core features are used as reference a lot of times. Now his can be a good thing or a bad thing depending on how those features are coded. If they have a bad design with plenty of antipatterns, then there is a very good chance that those bad practices will get copied into new features. But they can also have good design with good ideas. In this case, they will have a positive impact and encourage developers to use those practices and designs. And it's not just core features that can be used as reference but other clear, simple features which are easy to understand and figure out the code for them. Or when an application is developed from scratch, then the initial features of the application will be used as a reference.
Or when completely different and new feature is implemented in an application, then subsequent features similar to the new one, will have as a reference the new and completely different feature.
As a general rule, these reference features should be identified as early as possible in the application and then reviewed to see if they serve as good models and examples for the rest of the application.
Secondly, there is another case in which patterns and practices can be copied. When starting to use a new technology in an application, then the way of working with it and the patterns which are applied using that technology will also be copied later when new features will be developed using those technologies.
For example, at my previous project we started using a new ORM, Entity Framework Core. When we started using it, we also implemented a new pattern that works really well with that technology, the repository pattern. Then as we developed more features with Entity Framework Core, we looked at the initial feature that was developed with it and copied the same style, including the repository pattern. This in turn was a good thing because that pattern made writing unit tests easier.
Thirdly, when changing an existing piece of code, then that code and the code around it can be used a reference when making some changes. If a developer is adding new code to a feature, and that feature is coded like crap, then there is a very good chance that the new code will also be crap. Then things will get worse and worse from there. The code will become more and more confusing and harder to understand. Things can get ugly really fast. And eventually, things will be so convoluted ugly and complicated, that no one will know how that feature should have been actually coded, and a complete rewrite is required. I have seen this numerous times. It can get so complicated that it will be almost impossible to change without clearing up the code.
Sometimes, at some point in time a feature would have been well coded. But with many small changes that add crappy code or are themselves crap, the features loses it's structure and coherence, becoming a big bloated mess. I have seen this too happen. It's much more likely to happen with many small bad changes which are more likely to be overlooked at code reviews or during development. And if there are enough, they keep pilling up, changing the entire structure of the feature. Eventually there is tipping point, at which the coherence and structure is lost completely. After that, things go from bad to worse and eventually to an atrocious halt. So when changing existing features, adding new code to it, it important to keep the structure and coherence of that feature. That feature should have a sense of style to the code and structure. This is actually closely related to the broken window theory which actually has real implications in software development too.
Fourthly, an application might have a specific structure so that it allows news features to be developed in a specific way. Usually, it has some points of extensibility when parts of a functionality that meet a given criteria can be plugged in, in a controlled manner. These entire applications can be just a series of plugins that are loaded into a bare skeleton sometimes. The soul purpose of the core of the application is to link, load and allow plugins to communicate with each other. I worked a bit on some plugins for Visual Studio and Autodesk Maya that worked like this.
And there are some specific architectures that forces developers to plug in new functionalities at specifically designated points like "hexagonal" "architecture". But I haven't really worked with them, I just read about them a bit and then forgot about them, because they have too many pompous bullshit words in them like "architecture" in them which makes me run away from them.
Or inside an application, a generic skeleton of a specific kind of feature might be defined, which then can be further implemented and extended to create a concrete feature. Or several of these feature skeletons can be defined which then can be extended and filled in to create a new feature. For example, in some applications, for data access a generic base class is usually defined with some generic operations, that can be customized or extended with new functionalities. At my current project we have specific components that we can inject our content into which follow a specific pattern. One of these components is the layout functionality from Asp .Net MVC Core. Another one is a custom functionality that follows a pattern used in web called a "portlet".
Or a complete framework can provide the base skeleton for a kind of application which then can be extended and customized in a specific way to make for example a website using Asp .Net MVC if you are from the .Net world or Spring I think if you are from the Java world.
Usually, there is a combination of some of the things mentioned above that establish a specific way to develop an application.
And fifth, developers can have influence on one another. Some developers might be a bit of rivals. In this case, they will tend to scrutinize and criticize each others code and design more often. This can be a good thing because a lot of times it can help them come up with better ideas if they work together. But it can also be a bad thing, because they might take things too far and they will burn out, exhaust themselves and become frustrated. I can relate to this pretty well, as it happened a couple of times to me, and it didn't turn out good for me or the other developers.
Other developers can be really friendly and close to one another. This can be good or bad. For example with such a developer with whom I got along really well, we tended to agree to each other crappy and idiotic ideas, actually encouraging one another stupid ideas sometimes. This didn't turn out too well a lot of times. On the other hand, with some developers with whom I got along easily and well, we actually enjoyed helping each others, coming up with suggestions about how to improve each other's design, code and ideas.
Another case can be with a junior developer that thinks an older and more senior developer is cool. In this case, he has a higher chance that he will use the work of the more senior developer as reference. If the more senior developer makes a stupid mistake, then the junior developer might copy that stupid mistake. I think it is a good idea for a more senior developer to set up good explicit good examples for junior developers that admire him for one reason or another. And a lot of times, this more senior developer can be the actual team lead. Which is a very good thing. I think there are a lot of dynamics and factors that influence how a developer can admire and copy another developer. A developer might end up copying another developer, because he likes the same TV shows or films, they talk about those a lot, so it comes more naturally for them to be more interested in each other's work. I mean it's a lot easier to look at the work of someone you get along with, because even if you don't understand it, you have much more ease asking the other person with whom you get along with, to explain that code.
Sometimes, when two developers who don't get along or are shy with one another need to work together on various parts of a feature that need to interact and work together. Because of the reasons mentioned above, they will hesitate to communicate with each other. Instead they might assume that the other person thinks exactly the same as them, to give them an excuse not to interact with them. So they will make decisions based on those assumptions . But the can assume exactly the opposite things when designing their components. And those components need to work together to become a feature, it will be a glorious crap. Or it might not work at all. Either way, the feature will not work at all as designed, after each developer working 2 weeks on those components. I have seen this a couple of times and I laughed a lot at it, but it sure wasn't desired. That's why developers do activities together like ping pong, team building, chatting during breaks and so on, to become more comfortable with one another, to have the right level of cooperation and collaboration.
In the end, we should also focus and become aware of the tendencies we are establishing during the development process so we can curb bad tendencies. And surprisingly, a little bit of psychology plays a major impact on these tendencies. Now there are more mechanisms through which tendencies are established and work, I am still learning about them. But it is important at least to be aware of them, so that when you figure out a new one, you can learn to replicate it or curb it depending if it's good or bad.
Comments
Post a Comment