In this first post of the year, I want to reflect on a feature I have been observing in the projects I implement or lead for longer than I can remember, but that is perhaps not given enough attention when we are developing software.
If you have ever had the feeling that functionalities or features similar to one project have been implemented in another, then you may have the opportunity to extract them in a useful way for reuse. After all, it makes no sense to implement a new project entirely from scratch (without using any framework or third-party libraries), reinventing the wheel over and over again, unless you are experimenting or learning.
Although it may sound strange, the much-maligned and catastrophic 2020 was a very productive and creative year for me. Apart from everything related to these agitated times we are living through with a pandemic, lockdowns, economic collapse, etc., I can say that, fortunately, I launched several projects that I hope will improve over the next months. Some had been gestating since the previous year; others, like my books, which I also consider projects, arose as I accumulated topics to talk about and synthesize into that format, especially after launching Hub de Libros.
I have always encouraged everyone to be working on personal projects and not only dedicating themselves exclusively to those for which they are paid as employees in their companies or those for which they are contracted as freelancers. The richness obtained from dedicating time to them has always seemed to me even greater than that of taking courses, seminars, and reading books.
So much so that, over time, the boundary between what is a personal project and what is not begins to blur, since at this point I consider it part of my professional work and I take both equally seriously, regardless of my condition as a freelancer and independent consultant. In fact, projects that were initially personal and done almost to play around a bit ended up becoming commercial and corporate products, like Picly.io.
In my continuous self-learning mix, I always have one or two books I am reading (both technical and on many other subjects), podcasts I listen to regularly, and an occasional course. When I am not applying the principle that says you learn what you teach, that is why I regularly work on a new literary project, and this new year I already have several projects in mind. And yet, as I said before, what I perceive as most enriching is carrying out a real project, because, logically, you learn by reading, listening to podcasts, and taking courses, but what you have learned is only consolidated into knowledge when you have put it into practice. Obvious.
Reading is good and necessary, no doubt. But applying what you have learned is even better.
However, there is a characteristic of carrying out projects (both within companies and personal ones) that encourages me even more to do them and that requires working with a certain attitude because it affects the way you focus and design them.
In software, reuse is a fundamental concept: nothing worse than finding redundancies within the same solution. Eliminating them is important to keep it a little cleaner and better structured; so much so that in the methodology (one of many) that I propose for modernizing legacy projects in my last book, “Legacy Code”, I dedicate an entire chapter.
There are different levels of this reuse we are talking about: it can affect simple functions, helper classes or components, but also larger functional groups within the project.
A step beyond is to have a certain level of abstraction and see, concretize, and design other smaller projects within the same project on which it relies.
In Hub de Libros, for example, there is a powerful massive file manager that I gradually extracted as its own project and that I have published under the name files-repo on GitHub; similarly, the framework it is based on (Mantra) gradually generated a kind of ORM library that I also extracted as an independent project (it is RedEntities), and some others that I have not published yet.
In this way, the same project has generated several independent subprojects that I will certainly reuse often and that, who knows, may lead me somewhere.
The difficulty of extracting a subproject is not simply copying and pasting a set of classes or components, but implementing it so that it is not tied to the parent project from which it emerged, so that it provides a solution that can be integrated naturally and not forcibly into other projects.
Over time, maintaining this attitude of detecting what could become a new subproject has unexpected advantages, because in that way, when you face a new development and, like me, you have the responsibility to estimate effort and even determine the foundations of its design and architecture, you think and approach it not only as a set of components that will be orchestrated in some way, but also as a set of subprojects that will be developed independently and integrated at the right time.
In this way, I encourage working with this in mind and detecting which homogeneous parts of a solution can be extracted as independent projects.
Additionally, this can even be a commercial strategy to obtain more products from what was developed in one of them, something I have also done in recent years by trying to monetize libraries and developments created specifically for certain clients.
Conclusion: if we think about a new development by distinguishing some subprojects that integrate into it, we can monetize it better and the reuse of these will allow us to move faster in subsequent projects and even plan new independent products.