Future-Proof Technology Future-proof technology is [1]technology that is very likely to stay functional for a very long time with minimal to no [2]maintenance, even considering significant changes in state of technology in society. In a world of relatively complex technology, such as that of [3]computers, this feature is generally pretty hard to achieve; today's [4]consumerist society makes the situation even much worse by focusing on immediate profit without long-term planning and by implementing things such as [5]bloat, intentional introduction of complexity, [6]obscurity, [7]dependencies and [8]planned obsolescence. But with good approach, such as that of [9]LRS, it is very possible to achieve. A [10]truly good technology is trying to be future-proof because this saves us the great cost of maintenance and reinventing wheels and it gives its users comfort and safety; users of future-proof technology know they can build upon it without fearing it will suddenly break. Despite the extremely bad situation not all hope is lost. At least in the world of [11]software future-proofing can be achieved by: * [12]Free (as in freedom) software -- making your source code available, legally modifyable and shareable is a basic step towards making it easy to repair, backup and adopt to new technology (e.g. compile for new CPU architectures etc.). * Building on top of already well established, time-tested and relatively [13]simple technology such as the [14]C language or [15]comun. Choosing to use the older standards with fewer features helps greatly as the less-feature-rich versions of languages are always more supported (for example there is many more C89 compilers than C17 compilers) and can even be relatively simply reimplemented if needed. Another example is e.g. [16]OpenGL -- you should use the oldest (simplest) version you can to make a program better future proof. * Minimizing [17]dependencies to absolute bare minimum and offering alternatives and [18]fallbacks in cases where you can't avoid introducing a dependency (e.g. you should always offer an option for [19]software rendering in any program that by default uses [20]GPU for 3D graphics). Dependencies are likely the single greatest cause of software death because if one of your dependencies dies, you whole project dies, and this goes [21]recursively for all of the dependencies of the dependencies etc. This usually means software [22]libraries but also goes for other software such as [23]build systems and also [24]hardware dependencies such as requiring GPU, floating point, special instructions etc. * Practicing [25]minimalism and reducing complexity which minimizes the maintenance cost and therefore raises the probability of someone being able to fix any issues that arise over time. Minimalism is necessary and EXTREMELY important, [26]bloat will make your program very prone to dying as it will depend on a big community of programmers that maintain it and such community will itself always be very prone to disappearing (internals disagreements, stopped funding, lose of interest, ...). * Making your program [27]portable -- this ensures your program can be adapted to new platforms and also that you use abstractions that untie you from things such as hardware dependencies. * Generally just avoiding the hyped "modern" "feature-rich" ([28]bloated) technology arising from the consumerist market. * ... Just think. To see how likely your program is to die in short time just ponder for a while: what parts is it composed of and how likely is each of them to continue functioning and be fixed if it breaks? It's really like with a house or car. Notice that probability of breaking increases with complexity and probability of fixing decreases with complexity (because a fix has a higher cost -- it needs more time, energy, skill and so on). Is your program written in a simple language for which there already exist 10 compilers and which can be implemented again in a month if needed? Then the program is not likely to die by compiler or anything that may kill a compiler, such as a different operating or a new CPU architecture. Is it written in a 5 year old language that's still changing under your hands, has a single compiler and which itself relies on 100 highly complex libraries? Chances of death are great, it is certain your program will break with the next update of the language, or the one after that, you'll have to be around to fix it, and then a month later and then another month and so on until you die, for every program you have written in this language. Does your program only need two libraries, both of which can easily be replaced by something else by only rewriting 10 lines of code? Then your program likely won't die because of these libraries! Does your program use 10 very convenient but complex libraries, each of which additionally uses 10 other libraries itself? In a simplified way you can see your program depending on 100 other libraries now, if a chance of one such library breaking during one year is 1%, the chance of your program breaking in one year is 1 - 0.99^100 ~= 63%; if it doesn't break this year, then the next or the one after that -- yeah, someone will likely fix a library that breaks, but maybe not, projects get abandoned out of burnout, boredom, in favor of new ones etc., and a fix of your dependency may also come with the need for you to be around and update your own program because of API change. Does your program depend on piece of consumerism hardware that in 2 years will stop being supported? Or some specific operating system or Internet service posing similar dangers? This is additional thing on your list to watch, else your program dies. If your program is broken without you being around, how likely will it be fixed by someone? How many people in the world will be capable and willing to fix it? If the program is simple, likely any average programmer will be able to fix it and if the fix takes 10 minutes of time, someone will most likely do it just out of boredom. If your program is 100 thousands lines of code long, requires knowledge of 10 specific framework APIs and its inner architecture just to modify anything of importance, average programmer won't be able to fix it, he won't even attempt it -- if there is someone able to do the job, he won't fix it unless someone pays him a lot of money. Your program is basically dead. Please take a look at the table below, maybe you'll be able to extract some patterns repeating in software development [29]history: technology description born dead [30]Lisp programming langauage 1960 not before you [31]Forth programming langauage 1970 not before you [32]C programming langauage 1972 not before you Objective-C C++ but owned by a corporation, 1984 2014 (officially) everyone start using this! RPG maker Easily make RPG games just by 1992 basically a zombie clicking your mouse! Make platfotm-independent games and Java Applets web "apps", a comfortable platform 1995 2017 (officially) to unify them all! Comfortable IDE for rapid Delphi development of GUI "apps", a 1995 on deathbed platform to unify them all! Make mobile games with this J2ME multiplatform framework to unify 1999 2015 (de facto) them all! Make impressive interactive games Adobe Flash and web "apps", a comfortable 2007 2020 (officially) pltform to unify them all! Easily make web "apps", a Facebook Apps comfortable pltform to unify them 2007 2020 (de-facto) all! Blender Game Easily make 3D games without even Engine knowing any programming, comfortable 2000 2019 (officially) platform to unify them all! Unity 3D Easily make multiplatform 3D games! 2005 currently dying JavaScript + Easily make impressive web "apps"! 2013 surely won't die, React right? Godot Engine Easily make multiplatform 3D games! 2014 surely won't die, right? See Also * [33]finished * [34]sustainability * [35]portability * [36]software death * https://unixsheikh.com/articles/how-to-write-software-that-will-keep-working-for-decades.html Links: 1. technology.md 2. maintenance.md 3. computer.md 4. consumerism.md 5. bloat.md 6. obscurity.md 7. dependency.md 8. planned_obsolescence.md 9. lrs.md 10. lrs.md 11. software.md 12. free_software.md 13. kiss.md 14. c.md 15. comun.md 16. opengl.md 17. dependency.md 18. fallback.md 19. software_rendering.md 20. gpu.md 21. recursion.md 22. library.md 23. build_system.md 24. hardware.md 25. minimalism.md 26. bloat.md 27. portability.md 28. bloat.md 29. history.md 30. lisp.md 31. forth.md 32. c.md 33. finished.md 34. sustainability.md 35. portability.md 36. sw_death.md