You own your data – forever. You don’t need to keep paying monthly fees if you decide to switch to a different system just to access your historical data and conversations.
I’ve been advocating that development discussions should happen in Git* issues/PRs/projects whenever possible, so the conversations have context. One requirement for this to work long term is that you need access to these conversations for the duration of a product, and perhaps beyond.
There is a hosting cost, but it is minimal ($5/mo on a Linode server). There is also some ops cost to keep things running and up to date, but in my experience, Gitea is cake to self-host compared to things like WordPress or Email. The benefit-to-effort ratio is huge.
Git driven CD (Continuous Deployment) typically means whenever you merge to main , or tag a repo, something automatically gets deployed. It can be something as simple as a static website being updated.
One of the biggest advantages to this is that you know for sure the code was checked in and tagged. And you know exactly what code was deployed. There is no manual process involved to mess it up.
This may not seem like a big deal, but it is. As humans, we get lazy and forget to do the simple things like manually tagging a repo – especially on small teams where process is not emphasized. However, CD is a way to have a process without having a process. You do it in the name of saving time, but it also gives you enough process that things are now also consistent.
Michael Feathers defines legacy code as code without tests. He further elaborates in his book:
“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or how well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
Without automated tests, any modification to the codebase is risky, as there is no reliable way to know if a change introduces defects. This lack of feedback forces us to rely on manual testing or institutional knowledge – often lost over time – which makes maintenance difficult and error-prone. It is not about the age of the code or who wrote it, but about whether the code can be changed safely. If you cannot verify behavior through tests, the code is “legacy” regardless of its age or origin.
“past performance is not indicative of future results”
The above phrase is a disclaimer we often see associated with investments.
However, this applies to more than investments …
A technology that was cutting edge in the past may not be the best option for the future (example building web applications in PHP vs Go).
People who did good work in the past usually continue to do go work, but not always. (people can lose interest, suffer burnout, have personal problems, etc.)
Workflows used in the past do not always in the future (example, requiring patches on mail-lists will probably alienate a significant portion of the developer population who were raised on pull-requests).
As the level of integration in integrated circuits continues, the IC we used in the past may not be the best solution compared to more integrated solutions available in the future.
How we proceed in the future needs to be a combination of what we learned in the past (experience) and the technology available in the future (vision). Again, dysfunction arises when we mix these two modes up.
“past performance is not indicative of future results”
The above phrase is a disclaimer we often see associated with investments.
However, this applies to more than investments …
A technology that was cutting edge in the past may not be the best option for the future (example building web applications in PHP vs Go).
People who did good work in the past usually continue to do go work, but not always. (people can lose interest, suffer burnout, have personal problems, etc.)
Workflows used in the past do not always in the future (example, requiring patches on mail-lists will probably alienate a significant portion of the developer population who were raised on pull-requests).
As the level of integration in integrated circuits continues, the IC we used in the past may not be the best solution compared to more integrated solutions available in the future.
How we proceed in the future needs to be a combination of what we learned in the past (wisdom) and the technology available in the future (vision). Again, dysfunction arises when we mix these two modes up.
In the realm of product development, there are two powerful forces – experience and vision.
Experience (the past) is a guide – a help to avoid serious blunders and mistakes. Experience can help us avoid dead-end tangents. Experience gives us a gut feel that is critical at times. Experience helps us be more efficient if we can make fewer mistakes.
Vision (the future) is where we are going. It is seeing things that have not been done before. It is exploring new combinations of technology to build compelling products. It is adopting new technology, including tools, software, components, and workflows. It is about understanding the needs of your customers.
Without experience, we are on the path to collapse.
It is very true, we need great people in our organizations. And I have the utmost respect for those who can motivate and lead people. I also have the utmost respect for the capabilities of humans – that divine spark of creativity and the ability of the human brain to solve problems and make new connections.
However, to do much in this age requires people to work together and build on the work of the past. What one person does, another person needs to continue. The lone accomplishments of any one individual may be impressive, but without continuity and scale, there is likely to be very little lasting impact. Without systems in place (YOUR Platform), the brilliant work of your people will not be utilized to their full potential.
In debates about technology, people bring up points, such as an Arch Linux update occasionally breaking and not booting; thus, Arch Linux is bad.
While the above point is true, it is also irrelevant because it is not the entire story. What about:
The hours upon hours I’ve saved updating and installing stuff because pacman is so fast.
The 100’s of packaged tools and applications that save me from installing them manually.
The AUR, which has everything that is not already packaged, making it easy to install even the most obscure piece of software.
The benefits of using the latest and best versions of everything. After all, if something is getting better, may as well benefit from it now vs later.
The simplicity of PKGBUILD, which allows me to create and modify my own packages easily.
I could go on, but you get the point. After running Arch for over 10 years, let’s conservatively say I’ve saved an hour a week by using Arch – that is 520 hours. I’ve spent maybe 5 hours working through broken stuff in Arch in 10 years. That is a benefit-cost ratio (BCR) of 104. So yes, the 5 hours are real, but they are irrelevant.
Innovation is fueled by vision. Without vision, things can be directionless, drifting toward obscurity. So, how to encourage vision? Perhaps the first thing is not to discourage it. Ironically, the more successful an organization is, the more likely this is to happen. This happens when people mistakenly confuse experience with vision. In the realm of technology, how things were done yesterday, while a useful guide and foundation, will not get us to where we need to go tomorrow.
Another reason to self-host Gitea
Technical debt
Git driven CD – you know what got deployed
Legacy code
Past performance …
Experience and Vision
It’s all about the people
The entire story
Two approaches to life