Reuse
Ever since the term "software industry" started being used a lot of thinking in building digital products have revolved around reuse. As reuse from a physical perspective is easily understood and often viewed as a very good and sustainable thing to do it's easily to jump to the conclusion that this is equally good when it comes to digital product design. There are lot's of aspects to this, let's dive in...
Dependencies
Reusing components in your product creates dependencies that must be managed and monitored. When reusing a component, does it share your ideals in your product? Is it as high security as you need? Is it as lean as you want it? Does it do exactly what you want or lots of other things that might cause you problems? Does it have the right license to fit your need? Even just looking into all these aspects of the component you intend to reuse might be costly, so the benefits must be substantial.
Knowledge
Reusing something generally requires less knowledge than building the same thing yourself. As any team should strive for optimizing to gain the largest possible amount of knowledge if your trade off is between spending time on learning how to reuse a solution to a problem versus spending time on solving the same problem yourself, from a knowledge perspective you will frequently benefit more from trying yourself.
Modularity
For reuse to be successful you need a basic level of modularity in your product. From a design perspective modularity is a great way to improve flexibility, which is a good thing on its own, however it takes investment in design and implementation to create modularity and since few products are very homogenous you need modularity at the right place to make it fit with the component you want to reuse.
Focus
The biggest benefit of reuse is the ability to spend your time and effort on something else, something more valuable. No team can spend equal attention to every detail and being able to reuse a component and move on to something that can really make a difference to your product makes sense. If the task at hand provides ample opportunities for innovation and great freedom of design, it might be a very good thing to reuse a few industry standard components to get it done faster. If the trade off turns out to hinder you later you can use some of the time saved to invest in your own custom design.
Design trade off
In many cases reuse means that a trade off in the uniqueness of the design has to be made. This mindset tends to become a design trade off in the end, if you stop looking at design as a virtue in itself and rather view it as something to get over with that might reflect on other components where your design efforts are really needed. Should a car have 5 identical wheels, or does it make sense to have different front and rear wheels, perhaps the spare wheel could be very different? Even if a sub component might seem unimportant when you reuse you also reduce your ability to differentiate.
Familiarity
Some parts of product doesn't need to be different or feel unique, in some aspects it might be of great value that your design is familiar and helps the customer intuitively understand how to interact with it. Even if you have a design that is great it might be costly to help the customer get accustomed to it unless you have a very loyal customer base or a your product is used extremely frequently. Even if you don't reuse entire components it can be good to reuse familiar patterns in order to not create a product that is to weird.
Granularity
As there are numerous trade off involved in reusing the benefits must be be big. That means that the component reused must be substantial and non-trivial or a simple copy without reuse makes more sense. Avoid looking at reuse of components at code function and class level, your choices and evaluations of reuse is best spent on choosing the right programming language, runtime, cloud infrastructure or cloud services to reuse instead.
Dependencies
Reusing components in your product creates dependencies that must be managed and monitored. When reusing a component, does it share your ideals in your product? Is it as high security as you need? Is it as lean as you want it? Does it do exactly what you want or lots of other things that might cause you problems? Does it have the right license to fit your need? Even just looking into all these aspects of the component you intend to reuse might be costly, so the benefits must be substantial.
Knowledge
Reusing something generally requires less knowledge than building the same thing yourself. As any team should strive for optimizing to gain the largest possible amount of knowledge if your trade off is between spending time on learning how to reuse a solution to a problem versus spending time on solving the same problem yourself, from a knowledge perspective you will frequently benefit more from trying yourself.
Modularity
For reuse to be successful you need a basic level of modularity in your product. From a design perspective modularity is a great way to improve flexibility, which is a good thing on its own, however it takes investment in design and implementation to create modularity and since few products are very homogenous you need modularity at the right place to make it fit with the component you want to reuse.
Focus
The biggest benefit of reuse is the ability to spend your time and effort on something else, something more valuable. No team can spend equal attention to every detail and being able to reuse a component and move on to something that can really make a difference to your product makes sense. If the task at hand provides ample opportunities for innovation and great freedom of design, it might be a very good thing to reuse a few industry standard components to get it done faster. If the trade off turns out to hinder you later you can use some of the time saved to invest in your own custom design.
Design trade off
In many cases reuse means that a trade off in the uniqueness of the design has to be made. This mindset tends to become a design trade off in the end, if you stop looking at design as a virtue in itself and rather view it as something to get over with that might reflect on other components where your design efforts are really needed. Should a car have 5 identical wheels, or does it make sense to have different front and rear wheels, perhaps the spare wheel could be very different? Even if a sub component might seem unimportant when you reuse you also reduce your ability to differentiate.
Familiarity
Some parts of product doesn't need to be different or feel unique, in some aspects it might be of great value that your design is familiar and helps the customer intuitively understand how to interact with it. Even if you have a design that is great it might be costly to help the customer get accustomed to it unless you have a very loyal customer base or a your product is used extremely frequently. Even if you don't reuse entire components it can be good to reuse familiar patterns in order to not create a product that is to weird.
Granularity
As there are numerous trade off involved in reusing the benefits must be be big. That means that the component reused must be substantial and non-trivial or a simple copy without reuse makes more sense. Avoid looking at reuse of components at code function and class level, your choices and evaluations of reuse is best spent on choosing the right programming language, runtime, cloud infrastructure or cloud services to reuse instead.
Comments
Post a Comment