Framework vs. Application
Software developers are passionate and creative people, which impacts their thinking when writing software code. Depending on the kind of software, developers should use different approaches in order to make final product of a good quality.
I identify 2 main kinds of software - framework and application.
Framework is a software that is supposed to be distributed as a component for other development teams, so that it helps them implement better applications.
Application is a software that is supposed to be distributed as a product to limited kind of audience, so that it helps them execute their business-related tasks.
Ironically, I referred to "application" when defining "framework". This might be understood as a fact that the framework would not have any purpose if not applications that are going to use it.
Working on Framework
When working on a framework, we should think about different kinds of software developers that we are targeting. Obviously, we are solving only particular tasks, but we are providing numerous different ways to do the same thing. This could be achieved by providing extensibility (expecting abstractions to be injected) or by providing many kinds of overrides for different methods.
So, in short, we need to use our creativity at a maximum. If not, our framework will not be attractive or useful enough.
Working on Application
When working on an application, we are focusing on particular problem domain. Our time is paid by a company that does not need to have a large contingency of never-ending things. We are concentrated on delivering product and functionalities needed by the company or a customer.
Consequences of Confusion
When I used word "over-creative", I mean that we write large number of code lines that we think might be useful in the future (but not now). If we do so, we will introduce following problems:
- Developers need to learn more (and thus spend more time) about the code we create, since they need to ensure they know what kind of capabilities exist in the application's code. Otherwise, we will end up having duplicate functionalities since everybody thinks he/she is the first one inventing a bicycle. Whichever the case, I would prefer living without it unless we have a good reason (which means this topic does not apply at all).
- We write code that might never be relevant (regardless of our current feelings), and thus we produce a garbage, or a lot of refactoring material. Indeed, if we have code that is not going to be used, that is a garbage. And if it turns out that we need it but in a little bit different way, that is refactoring. In either way, we did no good at all.
- The more boilerplate code we write, the more public interfaces appear from our packages, which decreases the probability of a stable code. This is obvious since more number of public interfaces will potentially result in more number of dependencies from outside of our package. And more dependencies mean less stability, since the risk of affecting dependencies with each change inside our package is higher.
- We produce maintenance headache because more code requires more unit-tests, which need more efforts to keep in working (green) state.
- We don't let ourselves enjoy an opportunity to make a postponed decision (I covered Postponed Decision topic in the earlier topic). At a later point, we might be at much better position to make better decisions on what's really needed.
To sum up: when developing an application, limit yourself to the domain you are working on - solve domain-specific problems. Allow framework developers solve everybody else's problems.
Think big, do little. (I can't figure out who is the author, but I like this quote)