![[Hoare Property#^definition]] # Why? ## We Expect More - Multi-platform - UI programming - High DPI screen and corresponding assets - Pixel density scaling - Accessibility - Internationalization / Localization - Integration with other software - Social / OAuth login ## Security / Privacy #todo Old software was terribly insecure. Security as a discipline didn't exist back then and attack vectors weren't well-defined. Stakes were lower when the computers were single user and not networked (Concerns regarding security and privacy started when the multi-user timeshare systems got rolled in MIT); When physical access is the prerequisite for a vulnerability to be exploited, this greatly limited their impact. Sure, there were initial computer viruses that spread through floppy disks and zip files - Morris Worm, [CIH](https://en.wikipedia.org/wiki/CIH_(computer_virus)), ... but they also only caused vandalism. One cannot extract information or blackmail people via these viruses. > [!thought] > This is why IoT security ([internet of Shit](https://twitter.com/internetofshit?lang=en)) is such a big problem. We're not used to continuously operate and maintain our appliances; it needs to be as expensive as a car in order for it to be "worth it". However, the internet connected devices push that even further. > > From the manufacturers' perspective, there are no economical nor organizational incentives to maintain these products post sale. Washing machines and refrigerators can mechanically last decades, even longer with minor replacements. Very few internet connected devices can last that long, even if they are still mechanically sound. > > Android smartphones are the most scrutinized. It used to not matter because smartphones developed so fast (akin to PCs during the 90s) and hardwares got outdated. However, the development plateaued and we're at a point where a top of the line phone is computationally capable to last years. Security is evolving; the cat and mouse game between the bleeding edge offense and defense is quite intricate; it's difficult for anybody (including the practitioners of software development) to keep up to it. Examples: * Captchas * People loosing access to google accounts * Password Reuse ## Connectivity #todo We expect our applications to "just work" everywhere. * Multi-client - web (SaaS), mobile, desktop... * Offline functionality (which was the norm, but in the SaaS world, this would be an extra feature) * Cloud syncing This is one of the reason why [[SaaS]] became the norm. Technically, sophisticated multi-client syncing can be implemented. But it is theoretically and operationally challenging (either a mesh network or one's desktop performing the role of a server). Expecting a user to manage this is untenable (ex: misbehaving local network; no one wants to debug this). Syncing against a centralized server is much simpler. ## Operational Challenges All this mean that software needs to be maintained while it's being used (upgrades, maintenance of SaaS server). This pushes for the subscription as a mode of business. [[Self-hosting]] is effectively impossible; - [After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won](https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html) ## Layers See: [[Layers of Abstractions]] ## [[Package Manager]] ![[xkcd 2347.png|320]] As far as the modern software engineering is concerned, a package manager is a blessing and a curse. We are sitting on the shoulders of the giants, but the entire supply chain of dependency is untennable. - in the name of [[DRY and KISS]], we import libraries - in fact, there's a bit of *shame* against doing your own; ex: "don't roll out your own security". with that, there are merits - the nature of dependencies; they have different level of maturity - community - is this a single person? a company backing it? is it an "open-core" system that effectively cannot be used without a commercial deal? library vs framework? - general adoption - support; how good are they at keeping up? - there's *dependabot* - direction (or lack thereof) of a project. sometimes it's moving too fast; sometimes it's not moving at all. - inertia (a large project cannot be evolved in a way that you wish) - chains of dependencies; some libraries, even though their conceptual surface area is small, they hide a large dependency behind. - operations around dependencies - no good understanding about the dependencies - dependency upgrade are painful - "forking" dependency (in reality) is quite difficult, especially for compiled packages. - *vendoring*, the old "C" library style "include this dependency as a subfolder in your project" makes evolution much easier. - instead of *understanding* and *fixing* problems, we're encouraged to *hack around* the problems. instead of fixing issues, we search Stack Overflow for a workaround. conclusion - no software is ever lean, unless it's specifically designed for it. Leanness isn't emergence - [[X isn't an emergent property]] --- # Articles ## Software Disenchantment [link](https://tonsky.me/blog/disenchantment/) * Everything is unbearably slow * Everything is huge * Everything rots * Worse is better * Programming is the same mess ## Why Bloat Is Still Software’s Biggest Vulnerability - A 2024 plea for lean software [link](https://spectrum.ieee.org/lean-software-development) [HN](https://news.ycombinator.com/item?id=39315585) > [!quote] > Software is now (rightfully) considered so dangerous that we tell everyone not to run it themselves. ## Preventing the Collapse of Civilization [link](https://www.youtube.com/watch?v=pW-SOdj4Kkk) * Modern software is crappy * Examples: * Various screenshots * [[Programming Languages|Language Server]]s * Coding on top of Unity / Unreal without understanding them * This has very "Joel"-ism here. [[Joel on Software#26. Leaky Abstraction]], where he talks about *pointers* and whatnot. * using the Hacker Ethics mentality - we also forget the old computers had very little distinction between "programmers" and "users"; thus the users can (and are expected to) debug the program along the way. ## [[Enshittification]] ![[Enshittification#^749b55]] # Related - [[Inherent vs Incidental Complexity]]