Redundancy vs. dependencies: which is worse? (2008)
1–10 of 31 posts
Re: Redundancy vs. dependencies: which is worse? (2008)
#2My personal view is that redundancy on stupid things is okay. That is, things that are very simple, you should be okay with doing over and over in multiple modules if you need it.
The experience that lead me to this was a particular team I was on where a previous developer had said "aha! All of these pieces of code relate to the same domain model, so we should build a common package of domain model objects and have all the modules share those objects! That way, we don't have to write them all over and over again!"
These weren't just model objects for data passing, but actual business logic inside these models. Usually very simple stuff, but occasionally a particular module would need some special logic on those objects, so in it went.
The problem was that over time, there modules started drifting. Their domains became different ever so slightly and the owners of those modules became different teams. Now if you wanted to modify the domain object, you had to check it wouldn't break code the other teams were developing.
It became a real mess. And all to avoid writing the same simple pojo classes more than once.
Re: Redundancy vs. dependencies: which is worse? (2008)
#3I am often of the impression that it is ok to start with many dependencies to get an application into an experimental state quickly, but ultimately this is extremely immature. As the application becomes polished over time and as there are refinements to increase performance, reduce complexity, and trim some fat many of the dependencies will go away. The reason why many dependencies peel off a maturing application is that as the programmers become more involved and aware of their knowledge domain they have to ask themselves if they can simply "do it better and faster on their own", which is likely.
Unfortunately many applications, or their programmers, never reach maturity. Also there is greater security and dependability in managing certain critical functionality more directly instead of relying upon support from a third party that may not exist with the same level of compatibility in the future.
Re: Redundancy vs. dependencies: which is worse? (2008)
#4In the long run, dependencies are more expensive to work with, though
programmers usually don't see it nor admit it, as language package managers
hide the initial portion of the cost (the smaller one, but much better visible).
Re: Redundancy vs. dependencies: which is worse? (2008)
#5My personal view is that redundancy on stupid things is okay. That is, things that are very simple, you should be okay with doing over and over in multiple modules if you need it. The experience that lead me to this was a particular team I was on where a previous developer had said "aha! All of these pieces of code relate to the same domain model, so we should build a common package of domain model objects and have a…
One way to theorize about that experience is to note that the important argument for reuse is that changes only have to be made once to take effect everywhere. The classic change being the bugfix.
But the buried assumption there is that you actually want the change to happen everywhere. A hard thing to decide without hindsight.
Re: Redundancy vs. dependencies: which is worse? (2008)
#6I am often of the impression that it is ok to start with many dependencies to get an application into an experimental state quickly, but ultimately this is extremely immature. As the application becomes polished over time and as there are refinements to increase performance, reduce complexity, and trim some fat many of the dependencies will go away. The reason why many dependencies peel off a maturing application is…
As the application becomes polished over time and as there are refinements to increase performance, reduce complexity, and trim some fat many of the dependencies will go away.
Do you find that many teams have the discipline to do this? The cynic in me says that software far more often gets slower, more complicated, fat and dependency ridden over time.
More constructively I could ask: what is it that gives a team or project the discipline to do this work of improvement. How could I encourage such a virtue in my own environment?
Re: Redundancy vs. dependencies: which is worse? (2008)
#7On my last project since I was a one-man team, I erred way over on the side of dependencies. Thought I was being clever and organized for the first time, by encapsulating related things in related places and being a stickler about it. But in the quest to do that, I ended up with a large group of tightly-coupled trash cans!
Re: Redundancy vs. dependencies: which is worse? (2008)
#8My personal view is that redundancy on stupid things is okay. That is, things that are very simple, you should be okay with doing over and over in multiple modules if you need it. The experience that lead me to this was a particular team I was on where a previous developer had said "aha! All of these pieces of code relate to the same domain model, so we should build a common package of domain model objects and have a…
Default behaviors with custom overrides are the way I've always dealt with such "redundancy". In the end, tracing down the default behavior with it's own default behaviors often causes me to pull them out as simple pojos. I think there is no silver bullet, but that redundancy has a usability X factor that often goes unaccounted for, in the abstract.
Re: Redundancy vs. dependencies: which is worse? (2008)
#9You depend on code that is more abstract than yours. You replicate code that is at the same abstraction level of yours. You shouldn't even be touching any code that is less abstract than yours.
There is something to be said about libraries quality and trivial pieces of code. But I feel that this is just a rant about some environment that lacks a good command line parsing library.
Re: Redundancy vs. dependencies: which is worse? (2008)
#10I am often of the impression that it is ok to start with many dependencies to get an application into an experimental state quickly, but ultimately this is extremely immature. As the application becomes polished over time and as there are refinements to increase performance, reduce complexity, and trim some fat many of the dependencies will go away. The reason why many dependencies peel off a maturing application is…
As the application becomes polished over time and as there are refinements to increase performance, reduce complexity, and trim some fat many of the dependencies will go away. Do you find that many teams have the discipline to do this? The cynic in me says that software far more often gets slower, more complicated, fat and dependency ridden over time. More constructively I could ask: what is it that gives a team or p…
> Do you find that many teams have the discipline to do this?
It depends on the motivation. Ultimately it comes down to discipline.
As applications get popular over time their code base starts to age and get filled with chaotic cobwebs as new features are added or requirements shift. If you don't really care you will do the minimum required to complete your assigned task and await the next assigned task. This is what it is like when the people who do the actual work have no skin in the game. There is no sense of failure so long as you ship unbroken code, and so everything is very mediocre. If you completely suck as a developer then mediocre is your personal resounded success, and so what is just another layer of abstraction if it makes your job easier.
In startups, personal projects, or ambitious open source initiatives failure and pressure are constant reminders of reality. Everything is highly visible and it is always your fault until you ship something amazingly awesome. You need to ship quality code and make changes in the shortest time possible without dicking up the application. You don't want to get caught with your pants down updating a very simple bug only to discover a larger series of bugs in code you don't own that prevents you from shipping your little tiny code fix.
Also keep in mind that nobody (well... very rarely) is going to look into your code to see if you have a million dependencies, but they know when applications are slow heavy pieces of crap. If an application constantly breaks because the dependencies don't play well together and your developers lack the confidence to solve elementary problems your brittle house of cards pisses people off. I am a web guy and many major companies ignore these problems by doubling down on their branding, instead of training their people to write better code, which really pisses me off.
> what is it that gives a team or project the discipline to do this work of improvement.
Ownership of success/failure. When your job or equity are directly impacted (the more directly the better) the emotional connection to quality drastically changes. I apply this level of thinking to my big open source project even though I lose money on it, because I know people depend upon me and I own it. I can be more successful than I am now if I continue to improve what I own or I can be a disappointing failure.
This is harder than it sounds because metrics of product quality the confidence to attain such a level of quality differ by experience. Not everybody has years and years of experience. In that case you need somebody who can supply some technical leadership and not be afraid to hurt people's feelings when things get tough.