[{"content":"Recently this video from Dave\u0026rsquo;s Garage on Youtube popped up in my feed. He makes a valid point about your current super awesome killer PC being slower than the 10year old one it just replaced. Not because new hardware sucks, on the contrary new hardware is leaps and bounds faster and in some cases even lighter on the watts, so that you can have some semblance of a hope your Windows laptop can compete with the battery life of the Hipster\u0026rsquo;s Mac on the other side of the coffee shop. Rather that the software that runs on it requires more and more from the hardware, and maybe even to the point where the software devs just become lazy and say, I\u0026rsquo;m not optimizing this routine, someone can just throw hardware at it if they don\u0026rsquo;t like how slow it is.\nOn the OS level: If you look at how much RAM your Android phone needs to be responsive, then: Galaxy 2 1GB, 2xCores, now: Galaxy 25 12/16GB, 8xCores. Even that feeling you get when you upgrade your 7year old laptop from Windows 10 to 11 and then realizing what a big mistake it was. And don\u0026rsquo;t get me started on how getting a new Laptop with an i3 and 8GB of RAM running Windows 11, feels like having to browse Youtube over dial-up internet.\nOn the Framework level: System frameworks are pretty much the same, they are like the Victorinox Swiss Champ XXL . They contain everything you might ever need to build any web project, from REST, MVC, MVP, middleware, security. database stuff, etc. None of which is bad, but if I just want to build a simple site with a submit button, I don\u0026rsquo;t need 98% of that, however now my app server needs 500Mb for the framework and takes 15s to start just to host this simple site.\nThe Plan I find Testing OSes to be boring and not easy to achieve and do correctly or objectively. On the other hand to test languages and recommended frameworks is a lot easier and potentially less boring. To test these frameworks \u0026ldquo;equally\u0026rdquo; I will require all of them to solve the same problem. Since most of my daily work happens in the Fintech space I decided to ask an LLM for a simplified approximation of a FICO score. So there are 6 inputs, that are fetched from a db, some calcs on these inputs happen and in the end a score pops out. Each of the tested implementations expose the same REST like API and returns the same JSON output.\ncurl http://localhost:8080/user/3452 {\u0026#34;Id\u0026#34;:3452,\u0026#34;Name\u0026#34;:\u0026#34;Emmaline Whittaker\u0026#34;,\u0026#34;Score\u0026#34;:623} The platforms that have been identified are, java, .net, golang, typescript and python. Why these? Well I asked two different LLMs the same thing:\nGive me 5 languages recommended to build REST APIs in, based on ease of implementation, production stability, community support and security. I also approach each language with the normal vibe coding AI crutch jnr devs will use. I asked the LLM to recommend the fastest and most standard way to build such an API in the language and recommended a framework. I also asked for the easiest and most standard high performant API server, an ORM that doesn\u0026rsquo;t suck and a connection pool for the ORM. I will also ask for the most optimized production ready way to run it. Each framework will be tested using k6 using 5 concurrent connections, and because connection pools are weird we will ask for 15 initial and 50 total, if we can.\nMy expectations are high, I\u0026rsquo;m C/C++ trained and have been forced by the industry to move to the lazy languages, because only boomers and neck beards code in C/C++ these days, apparently. So my really fragile, not production ready, I\u0026rsquo;m-super-rusty-in-C demo app, before forking, uses 8Mb RSS and startup is instant.\nC the baseline Since the c app doesn\u0026rsquo;t support multiple concurrent connection, it was changed to fork 5 children that process the requests. The parent uses 6Mb and each child uses 8Mb that is why the memory on the chart is 48Mb. The memory \u0026ldquo;spikes\u0026rdquo; with 600kb during warmup. During the main run we use 1 core and takes 20s. Java Ok so the the trendy results for Java selected the following:\nSpringboot - Framework that provides API and DB integration Hybernate - ORM gradle - Builder Welcome to the Jungle If you are new to java the code is structured in a military fashion and there is A LOT of things in different places. There is a file for startup, a file for the controller a file for the service, etc. There is also dependency injection where the framework constructs your classes as singletons and then injects them automagically.\nDoes it care? To run java applications you apparently need to type and entire novel to run it optimally.\njava -server -Xms64m -Xmx2g -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:+UseG1GC -XX:+UnlockDiagnosticVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -jar ./build/libs/java-orm-0.0.1-SNAPSHOT.jar Out of the gate the memory usage for this abomination is ~290MB and startup time is 3s. The memory spikes to ~380MB during the warmups and then again to ~410MB during the main run. It uses 3cores and took 38s to complete the task. Interestingly there is 0 CPU i/o wait.\nThis is a bit crazy, 410MB for a simple API. Let\u0026rsquo;s close the taps on the heap (-Xmx) to a \u0026ldquo;max\u0026rdquo; of 256MB and see what impact that has on performance.\njava -server -Xms64m -Xmx256m -Xss512k -XX:MaxMetaspaceSize=96m -XX:+AlwaysPreTouch -jar ./build/libs/java-orm-0.0.1-SNAPSHOT.jar Out of the gate it ignores the cap and the memory usage, performance remain mostly the same.\n.Net - c# Ok so the the trendy results for c# selected the following:\n.Net Core - Framework that provides API and DB integration Entity Framework - ORM msbuild - Builder Still a jungle If you are new to c# the code is structured in a logical fashion and there are a couple of things in different places. There is a file for startup, a file for the controller, etc. There is also dependency injection. Looks and feels very much like java.\nDoes it care? To run it optimally we just have run the following:\ndotnet run -c Release Out of the gate the memory used is 75MB and startup is 2s. We can see the memory spikes to 175MB during the warmups and then drops down to ~170MB during the main run. The CPU usage is 5cores. The processing time however is 1m03s.\nDeno - js Ok so the trendy results for deno suggested the following:\nBuilt-in Http Server - API No ORM was suggested deno - Build tool Where are all my files at Minimalistic, only 2 files. One for the endpoint, setup and data fetching. Feels very strange after the strict structure of c# and java.\nDoes it care? To run it optimally you can compile and run a binary.\ndeno compile --allow-env --allow-net --output server server.ts ./server Out of gate the memory usage is 380MB and startup is \u0026lt;1s. We can see that memory spikes to 410MB during the warmups and then spikes to 480MB during the main run. With the single-threaded event driven design of deno and node.js before it, it only uses 1core. The processing time however is 48s, which is pretty good for one little thread.\ngolang Ok so the trendy results for go suggested the following:\nBuilt-in Http Server - API gorm - ORM go - builder More than 2 files Minimalistic, not as little as deno, but still one main file and style recommendations of splitting things into their own go files, to make navigation easier.\nDoes it care? To run it optimally you need to compile a chunky binary and run it.\ngo build -o go-orm *.go ./go-orm Out of the gate we notice memory usage is less than 11MB and startup is instant. We also notice memory spike to 17MB during the warmups, and spikes again to 19MB during the full run. The CPU usage is 2cores. The processing time is 26s.\nPython OK so the trendy results for python suggested the following:\nfastapi + uvicorn - for the API No orm pipx - for dependencies and running One file wonder Minimalistic, just one file. Not sure why the LLM recommended this approach, surely we can split the server/main from the user model.\nDoes it care? To run it optimally when you are lazy and your os is pip locked use pipx.\npipx run server.py Out of the gate it uses 55MB of memory and startup is 2s. Memory usage doesn\u0026rsquo;t spike either during warmup or the main loop. The CPU usage is 1 core. Processing time is a dream shattering 4m51s.\nThe performance sucks so badly, let\u0026rsquo;s stop being lazy and make the required performance upgrades. That requires switching pipx out with granian and forking 5 workers like the C app.\nTo run it optimally\ngranian --interface asgi --workers 5 --runtime-threads 2 --no-access-log --port 8080 --backlog 2048 server2:app Out of the gate the memory usage is 324MB and startup is 3s. Memory usage spikes to 330MB during warmup and then down to 326Mb during the main run. CPU usage is 4cores. Processing time is better at 1m35s, but not wow. Final thoughts Let\u0026rsquo;s plot our findings. Below we plot the 3 things that we measured that are important, CPU usage (cores), Memory usage and processing time. Clearly the one that cares the most is the one that has the lowest CPU, lowest memory usage and fastest processing time, however things are not always as perfect as you want them to be and you have to make trade-offs. Looking at the rest Java and Deno used the most amount of Memory, and C# used the most CPU, however the performance gain from the 5cores, was worse than deno with 1core. If you looked at just CPU and Memory, python looks like a solid contender, but then you start caring about speed and you see it really sucked in the benchmark. This is a very narrow scoped \u0026ldquo;service\u0026rdquo;, so we can\u0026rsquo;t make generalized judgments about the languages and their frameworks. I don\u0026rsquo;t even want to list some take-aways from this article.\nDevelopment does not have one language that is the best for every problem, because of that we have thousands of programming languages each that does something different to the others. Sadly most companies brand themselves as a C#/Java shop and attempt to solve all the problems using them. It is always sad to see a big linux server in prod that only runs 1 jar, and nothing else, because the workload requires that jar to consume all 32GB of RAM. In my opinion you can probably scale that server down to only have 2GB of RAM if you were to convert the Java to C, however I would much rather maintain Java source than the mountains of C source. Having said that I would rather work with C pointers than with Java generics. But all this boils down to the squeezing the balloon metaphor. If you want an easy development experience writing minimal code, you squeeze the balloon, and what you don\u0026rsquo;t write is now part of the framework and you relinquish control over speed, performance, security, features and memory usage. And the opposite is also true, if you want to claw back either speed, performance or memory usage you either have to take control away from the framework, remove the framework entirely or rewrite it in a completely different language. Python also has balloon squeezing, however here you sacrifice speed for the enormous eco system and productivity gains, just look at those train-my-own-ai samples online 10 lines of python starts training your own Convolutional Neural Network.\nI started off by saying nobody cares anymore, and that is not entirely true, C never stopped caring we just became lazy, and golang the man in the middle attack on C and C++ also deeply cares. So the next time you start a new project just ask yourself, in this day and age of the great RAM shortage: Do I even care if we can even afford another 500Mb Java \u0026ldquo;micro\u0026rdquo; service? Or should you pivot to something more green like golang.\nTest setup K6 K6 was run using a simple script that selects a random user by id between 0 - 500,000, that is then sent to the current API under test. Each api gets 3 warm up runs of 5 concurrent users requesting 500 responses before the big test that has 5 concurrent users and 750,000 responses. K6 uses the custom bench/script.js file and was run as follows:\nk6 run --vus 5 --iterations 750000 script.js pidstat pidstat was used to record the stats for the pid of the server, after which the results were sent through an ai-slop plot.py script that generated the resource graphs. The two projects that forked children record the pids for all the children and then an aggregate file is made running plothelp.py before plotting the data with plot.py. All the scripts and recorded raw and aggregate stats are in the bench folder.\npidstat was run as follows:\npidstat -h -r -u -p 204909 1 \u0026gt; /tmp/stats System: Versions of toolchains: java openjdk-21-jdk-headless:amd64 javac 21.0.10 gradle 9.3.1 golang go version go1.25.5 linux/amd64 dotnet 10.0.107 js deno 2.6.9 (stable, release, x86_64-unknown-linux-gnu) v8 14.5.201.2-rusty typescript 5.9.2 k6 v1.7.1 (commit/9f82e6f1fc, go1.26.1, linux/amd64) OS Linux Mint 22.3 CPU AMD Ryzen 7 - 8 cores DB postgresql 16.11-0ubuntu0.24.04.1 DB The database creation and seeding is done by a go app in the db folder, and seeds a table called user.\ncreate table user( id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT NOT NULL, payment_history_percent_on_time REAL, credit_utilization_ratio REAL, credit_age_years INT, total_accounts INT, recent_inquiries INT, derogatory_marks INT ); Code All the code samples are hosted on github ","permalink":"https://dbreedt.co.za/posts/nobody_cares.html","summary":"\u003cp\u003eRecently this video from Dave\u0026rsquo;s Garage on Youtube popped up in my feed.\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n\t\t\t\u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/t992ul_IKtc?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n\t\t\u003c/div\u003e\n\u003c/p\u003e\n\u003cp\u003eHe makes a valid point about your current super awesome killer PC being slower than the 10year old one it just replaced. Not because new hardware sucks, on the contrary new hardware is leaps and bounds faster and in some cases even lighter on the watts, so that you can have some semblance of a hope your Windows laptop can compete with the battery life of the Hipster\u0026rsquo;s Mac on the other side of the coffee shop. Rather that the software that runs on it requires more and more from the hardware, and maybe even to the point where the software devs just become lazy and say, I\u0026rsquo;m not optimizing this routine, someone can just throw hardware at it if they don\u0026rsquo;t like how slow it is.\u003c/p\u003e","title":"Nobody cares anymore"},{"content":"In February 2025, I wrote that Quantum Computing was a \u0026ldquo;game-changer\u0026hellip; eventually.\u0026rdquo; A year of R\u0026amp;D has passed, and that eventually is looking a lot like soon. In 2026, we aren\u0026rsquo;t just talking about qubits; we\u0026rsquo;re talking about Lattice-based Cryptography appearing in our browser consoles and OpenSSL warnings.\nWhere is last year\u0026rsquo;s bleeding edge? Last year I talked about potential breakthroughs in room-temperature superconductors, mechanical qubits and Google\u0026rsquo;s Willow chip.\nRoom-temperature superconductors It turns out that quantum computers actually run better at ultra low temps. The low temps reduce the thermal noise, because the thermal energy is far larger than the minute energy gap between the qubit\u0026rsquo;s ground state and the excited state. The main gain from room temperature superconductors would be simplification of the fridge setup, move lab tech closer and improve the I/O bottleneck. If you are interested, here is a deepdive .\nMechanical Qubits Mechanical Qubits will also not replace normal qubits as we know them now, currently Quantum RAM applications look very promising, because mechanical qubits can keep state longer than normal superconductive qubits. Another application is using them as transducers , basically as a medium to pass information between different types of qubits.\nGoogle\u0026rsquo;s Willow Chip Willow has progressed from a purely internal research project to Google shifting its focus from purely demonstrating architectural viability to fostering broader scientific collaboration, actively opening the Willow architecture to external research proposals to stress-test the hardware against novel quantum algorithms and real-world scientific use cases.\nThe State of the Tech Microsoft\u0026rsquo;s Majorana 1 The most significant hardware advancement this last year is Microsoft\u0026rsquo;s Majorana 1 processor .\nWhat it is: Instead of traditional superconducting loops (IBM/Google), Microsoft is betting on exotic quasiparticles called Majorana fermions. Why it matters: These qubits are topologically protected, meaning they\u0026rsquo;re inherently more stable and less prone to the \u0026ldquo;noise\u0026rdquo; that plagued systems previously. The Verdict: While still in the early stages, this architecture could leapfrog the need for millions of physical qubits by providing high-quality logical qubits much sooner. The Hybrid Integration: NVIDIA CUDA-Q The Quantum Winter was avoided because we stopped waiting for a standalone quantum computer and started building hybrids. NVIDIA\u0026rsquo;s CUDA-Q platform has now integrated with quantum processors (QPUs) as standard accelerators in HPC environments. This means financial models can now offload specific complex calculations to quantum chips while the AI runs on GPUs.\nUpdated Risks to the Finance Sector The risks have evolved from \u0026ldquo;The sky will fall eventually\u0026rdquo; to \u0026ldquo;Your data is being harvested today.\u0026rdquo;\nThe \u0026lsquo;Harvest Now, Decrypt Later\u0026rsquo; (HNDL) Reality: Both Cloudflare and Google have signaled that 2029 is the de facto Quantum Deadline for full infrastructure migration. They\u0026rsquo;re actively shielding traffic today to prevent future decryption of current financial secrets. The RSA Warning Era: If you connect to a host using old RSA-2048 keys, OpenSSL and modern browsers now flag these as legacy. In finance, this is rapidly becoming a compliance failure, as NIST has set a hard 2030 deadline for deprecating RSA/ECC. Institutional Crypto Exposure: With firms like BlackRock holding millions of Bitcoin, the Quantum Threat to Crypto is now a systemic financial risk. The Fork Risk: Research suggests over 34% of Bitcoin uses vulnerable legacy formats (P2PK). Institutional giants may soon face a fiduciary duty to force a hard fork to a Post-Quantum (PQ) version of the chain to protect their billions. New Opportunities for the Finance Sector AI hasn\u0026rsquo;t just enhanced your workflow, code, images and grammar; it has now seemingly become besties with Quantum tech.\nQuantum-Enhanced AI (Q-AI): While 2024 and 2025 was about LLMs, 2026 is about Quantum Reinforcement Learning (QRL). Financial institutions are moving beyond basic price prediction to simulate entire Agent-Based ecosystems . By using quantum superposition, these models can simulate millions of individual market participants reacting to a crash in parallel a feat of multi-agent complexity that causes classical AI to choke. Deep Hedging: Teams at JPMorgan Chase are pioneering Deep Hedging models that use quantum-classical hybrids to find correlations in high-dimensional data that traditional Monte Carlo simulations miss. Lattice-Based Security as a Service: Banks are now offering Quantum-Safe Custody for digital assets, using NIST-standardized ML-KEM (Kyber) to guarantee long-term privacy for their high-net-worth clients. Are we doomed yet? The goalposts have moved. We\u0026rsquo;re no longer waiting for a single Q-Day. Instead, we are seeing a slow-motion explosion where old standards are being deprecated one warning at a time.\nThe Good News: The transition to PQC is happening faster than predicted due to giants like Google and Cloudflare leading the charge. The Bad News: The barrier to entry for \u0026ldquo;Quantum-Breaking\u0026rdquo; is dropping as AI helps researchers optimize how they use limited, \u0026ldquo;noisy\u0026rdquo; quantum hardware to run low-depth algorithms . Final Thoughts I, for one, am surprised at the speed of adoption of post quantum ciphers by the big players to limit the risk of the HNDL movement. If your stack handles private data for customers that you wouldn\u0026rsquo;t want to find in a data breach dump on the dark web, then start your post-quantum upgrades now. If you are interested in what the doomsday preppers are up to, you can follow them here:\nNIST\u0026rsquo;s PQC Project Cloudflare\u0026rsquo;s Learning Center Google\u0026rsquo;s Quantum Migration Timeline (2029) ","permalink":"https://dbreedt.co.za/posts/quantum-computing-finance2.html","summary":"\u003cp\u003eIn February 2025, I wrote that \u003ca href=\"/posts/quantum-computing-finance.html\"\n   \n   \u003e\n   Quantum Computing was a \u0026ldquo;game-changer\u0026hellip; eventually.\u0026rdquo;\n\u003c/a\u003e\n\u003c/p\u003e\n\u003cp\u003eA year of R\u0026amp;D has passed, and that eventually is looking a lot like soon. In 2026, we aren\u0026rsquo;t just talking about qubits; we\u0026rsquo;re talking about \u003cstrong\u003eLattice-based Cryptography\u003c/strong\u003e appearing in our browser consoles and OpenSSL warnings.\u003c/p\u003e\n\u003ch2 id=\"where-is-last-years-bleeding-edge\"\u003eWhere is last year\u0026rsquo;s bleeding edge?\u003c/h2\u003e\n\u003cp\u003eLast year I talked about potential breakthroughs in room-temperature superconductors, mechanical qubits and Google\u0026rsquo;s Willow chip.\u003c/p\u003e","title":"Your RSA Keys are Expiring (Metaphorically)"},{"content":"The rapid advancements in quantum computing research have positioned it as both a force for innovation and a looming threat to the financial sector. While some celebrate groundbreaking discoveries, others amplify concerns over the risks quantum computing may pose to financial institutions.\nThe United Nations has declared 2025 the International Year of Quantum Science and Technology , and experts speculate about the so-called ‘Q-Day’ —the moment when quantum computers will be capable of breaking the cryptographic systems that secure digital communications and transactions.\nFinancial institutions are already preparing for this shift. HSBC, in collaboration with IBM , anticipates that the financial services industry will be among the first to be transformed by quantum computing and Artificial Intelligence (AI)—a convergence now referred to as AQ. Echoing this view, AI and quantum computing were key discussion points at the Singapore FinTech Festival in November 2024.\nWhile quantum computing itself is not new, the excitement around its potential to go mainstream within the next few years is growing.\nOpportunities for the Financial Sector AQ offers exponentially faster data processing, which could transform risk mitigation, fraud detection, and financial modelling. By enhancing machine learning, it has the potential to reshape:\nRisk estimation and trading strategies: Uncovering hidden correlations in vast datasets to improve market predictions.\nCustomer analytics and personalisation: Enabling banks, insurers, and investment firms to provide smarter, AI-driven financial advice tailored to individual risk profiles.\nReal-time risk analysis and portfolio optimisation: Allowing for more precise decision-making.\nInsurance: Improving risk assessment, dynamic pricing, and fraud detection, leading to hyper-personalised policies with greater predictive accuracy.\nThis technological leap is expected to drive efficiency and innovation across the financial sector.\nRisks for the Financial Sector Quantum computing also introduces significant risks, particularly in cybersecurity. Algorithms such as Shor\u0026rsquo;s Algorithm and Grover\u0026rsquo;s Algorithm could undermine the cryptographic protections that currently safeguard digital communications and transactions:\nShor\u0026rsquo;s Algorithm enables polynomial-time factorisation of large integers, threatening RSA and Elliptic Curve Cryptography (ECC)—which underpin authentication, transaction verification, and secure communications.\nGrover’s Algorithm accelerates brute-force attacks on symmetric encryption, reducing the effective key length of encryption standards like AES.\nFor financial institutions, the potential impact extends beyond encryption:\nCompromised authentication mechanisms: Attackers could impersonate systems, manipulate transaction records, or gain unauthorised access to sensitive data.\nVulnerabilities in cryptocurrencies: Bitcoin wallets, which rely on ECC, could be at risk if a sufficiently powerful quantum computer derives private keys from public ones.\nAlthough quantum computers could theoretically break these encryption methods, doing so would require fault-tolerant quantum machines with millions of stable qubits . Currently, the most advanced quantum computers operate with only a few thousand noisy qubits, making these threats largely theoretical for now.\nThe Current State of Quantum Computing Despite significant progress , quantum computing remains far from mainstream adoption. Major challenges include:\nQubit stability and error correction: As quantum computers scale, maintaining coherence becomes increasingly difficult.\nExtreme operating conditions: Most systems require temperatures near absolute zero.\nThe need for millions of qubits: Breaking RSA-2048 encryption, for example, is estimated to require around 6,190 logical qubits, translating into millions of physical qubits when accounting for error correction.\nWhile research continues at a rapid pace, many experts believe it will take a decade before quantum computers can reliably break classical encryption.\nLooking Ahead Quantum computing is advancing, but mainstream adoption remains distant. Several breakthroughs—such as room-temperature superconductors , mechanical qubits , or Google’s new Willow chip —could help overcome existing limitations. For now, access to quantum computing remains expensive and largely limited to cloud-based services .\nMeanwhile, cryptographic experts are actively developing post-quantum cryptographic standards to mitigate potential threats. Industry commentary suggests that most financial institutions will likely be quantum-immune before quantum computers become a mainstream security risk.\nAs quantum computing matures, its impact is likely to be transformative, much like GPUs and AI have been—revolutionising some tasks while serving as an additional tool for others.\nFinal Thoughts Quantum computing holds immense promise for the financial sector, offering both opportunities and risks. While it is not yet ready to disrupt global financial systems, the race to prepare for its eventual rise has already begun. Institutions that invest in quantum-readiness today will be best positioned to navigate the future of finance.\n","permalink":"https://dbreedt.co.za/posts/quantum-computing-finance.html","summary":"\u003cp\u003eThe rapid advancements in quantum computing research have positioned it\nas both a force for innovation and a looming threat to the financial\nsector. While some celebrate groundbreaking discoveries, others amplify\nconcerns over the risks quantum computing may pose to financial\ninstitutions.\u003c/p\u003e\n\u003cp\u003eThe United Nations has declared 2025 the \u003ca href=\"https://quantum2025.org/\"\n   \n    \n      target=\"_blank\" rel=\"noopener\" \n   \u003e\n   \u003cem\u003eInternational Year of Quantum\nScience and Technology\u003c/em\u003e\n\u003c/a\u003e\n, and experts speculate about the\nso-called \u003ca href=\"https://www.cigionline.org/articles/q-day-is-coming-is-the-world-prepared/\"\n   \n    \n      target=\"_blank\" rel=\"noopener\" \n   \u003e\n   ‘Q-Day’\n\u003c/a\u003e\n—the\nmoment when quantum computers will be capable of breaking the cryptographic systems that secure digital\ncommunications and transactions.\u003c/p\u003e","title":"Quantum Computing in Finance: A Game-Changer... Eventually"},{"content":"An adage goes: “The more things change, the more they stay the same” — that kind of holds true for Software Development.\nBack in the day, we used to design our systems, write the code, compile it, run it, get it tested and then deploy it. We still do all of that today, regardless of what we are building, be it microservices, large scale monolith systems, mobile apps, websites or firmware for IOT things.\nSo nothing has changed, okay cheers, 10 minute read my ass. Not so fast; a lot indeed has changed, albeit under the hood of those old school development pillars.\nSome of the things that have changed are:\nHow we safeguard the code Where the code is executed How the code is built and moved How we plan How we manage to burnout developers faster How we care about the code we write How we safeguard the code Many, many different ways exist to version control your code; the following is a list of things that I have experienced and that I don’t recommend you try:\nA shared folder contains all source files Everyone has an offline copy Visual Source Safe on a shared folder StarTeam TFS over VSS TFS before they adopted git CVS Subversion in large teams Google Drive folder with change tracking Source control is, and probably will always be, an issue — until everyone wakes up and accepts that git is the only free version control you will probably ever need. I state this on the premise that you are tracking changes in standard human-readable programming language source files, not large ML data sets, and that you don’t store all your source code in a single repository. I’m looking at you, Google .\nI’m glad to report that I have not experienced any source code not stored in some flavour of git in the past ten years, so it appears that the world is waking up to decent free version control.\nAlong with the adoption of git came all the cloud-based git offerings — with GitHub being the biggest and most famous of them. With this git in the cloud business, developers can work from anywhere; they don’t need to be in the office or have VPN access. They can work from where and when they want and how they want. Finally, coding half-naked, eating Cheetos on your couch while watching Sam \u0026amp; Max can be a thing — if that is what you are into.\nWhere the code is executed Back in the day, we had to guess specifications for a physical server, and we had to care about the CPU, RAM, HDDs and even the Network cards. This server often sat at the customer’s premises running on their infrastructure with their BOFH’s controlling it. If you wrote okay code and your Systems Architect, the guy that specced the server, knew their stuff, the post-prod deployment was a nice place to be. 🤣🤣🤣 That seldom happened! Either the server was too small, the interwebs feeding the server was too small, the raid controller sucked, the code sucked etc. Anything that required more infrastructure (server, network, switches, internet bandwidth) had massive lead times. Getting a new server normally took 6+weeks. So the only way to fix the epic levels of suckitude was to run the following code in a loop for a couple of weeks:\nfor(customer.Cry()) { team.Optimize(); } Most of the code we write nowadays runs in the cloud. The cloud is just a Hardware Abstraction Layer; you know you want 1vCPU and 2GB of RAM, and you have stopped caring if it runs a Xeon, Epyc, ECC Memory, Optane SSD, SATA, SCSI or SAS. All the specifics are now gone. If it sucks, stop the instance, change the instance type, start it up again, rinse and repeat. Rinsing and repeating is not the answer to every prod problem; sometimes, the code is so wrong that throwing more hardware at it won’t make it better, and you still have to go back to the optimise loop described above.\nAn even more significant benefit to executing the code in the cloud is the capability of having distributed development teams. These teams can all have a development and staging environment running the latest code change you pushed five minutes ago, without every UI developer needing to pull the newest backend changes, compiling and running them locally. Having distributed development teams means that teams collaborate better and faster. When you find a bug in UI or backend, you can raise it immediately before the dev moves to the next ticket in the backlog. I’m aware this model doesn’t work for all types of development, but it has done wonders for web and mobile app development to speed up development.\nHow the code is built and moved A senior developer used to compile the code in Release mode with optimisations tuned to the production server’s CPU and architecture, zip the binaries, copy the archive to a network folder and finally ssh or RDP into the production environment and manually perform the release. Since this process is prone to hit-by-a-bus failure, a new buzzword-filled section in software development was born. It is called DevOps and basically, what this entails is that an automated process builds, tests, packages and even deploys it. There are so many different tools to cater for almost all your needs; you can build on an on-prem server and deploy on-prem or build in the cloud and deploy wherever you want; the options are only limited to your imagination. The main drive behind this is to remove the hit-by-a-bus risk and, more importantly, increase the speed at which you can get new/fixed code into an environment.\nThis field is not without its problems; if you build in the cloud and Azure DevOps, GitHub Actions, or AWS is experiencing an outage, you can become stuck with no option to deploy your code until the outage is restored.\nThe other, more critical, problem with DevOps, in general, is security. Yup, you take company IP and move it into a non-company controlled infrastructure optionally using sensitive data (config, keys, connection strings etc.) to perform the testing, building and deployments. Security is such a significant oversight that big consulting houses are called upon to perform DevSecOps audits.\nProbably the most impactful change DevOps has brought to the table, besides making some snowflake god-complex devs obsolete, is the exponential increase in unit/integration tests adopted by dev teams. To have confidence that the new code won’t break the perfectly working system, we write tests. These tests are executed as part of the DevOps pipeline. Only if these tests pass successfully are the built artefacts distributed. If the built artefacts are buggy as hell, developers WILL ENHANCE the test suite with more tests and the process repeats. We have come to a point where standard tests written by humans aren’t good enough for some people, and then they introduce chaos during testing, using fuzzers (see sharpfuzz and gofuzz ). Introducing chaos during testing should not be confused with chaos engineering, which is something way more fun.\nI have stopped counting the number of times tests have saved my new yet retarded code from destroying a perfectly working system. I don’t wonder if tests are worth it; I know they are, and I continue writing more. I have changed my attitude towards bug fixing from one of finding, fixing and manual testing to one of writing a test to verify the bug and then changing the code until the test passes.\nThis shift to automated testing has caused testing teams to be smaller and more efficient; however, it has caused some of them to lose their jobs. They will probably point and laugh at us when GitHub Copilot puts us out of a job.\nHow we plan In my experience, a Project Manager usually gets assigned the task of making developers build a poorly scoped system based on very bad thumb-sucked estimations and flawed assumptions. Waterfall, how I don’t miss thee.\nUnfortunately, the PM role still exists, but fortunately, the devs have revolted and demanded that we want more realistic thumb-sucks. Developers’ demands for better estimations resulted in the birth of Agile and Agile-like methodologies that conned the PM into believing that smaller usable deliverables every fortnight will deliver the final product faster.\nHowever, this has forced devs to be more conscious about the planning process. Don’t think that Agile has solved the devs-are-lazy-af problem for one minute. I have on numerous occasions seen senior devs lying, saying something will take them four hours to do when in fact, that same thing will take a greenhorn thirty minutes to do correctly. I feel the shift to Agile-like methodologies has made devs more pedantic about how they break down and scope large complex tasks. By reviewing the work at the end of the sprint to see what was scoped correctly or incorrectly and learning from that, it creates a positive feedback cycle that helps the dev become more reliable, accountable and even better at scoping.\nAgile is a double-edged sword that takes care of inaccurate estimations and causes costs to align with actual effort. All roleplayers now have a better understanding of what they are getting themselves into beforehand and throughout. By no means has Agile methodologies made the estimates 100% accurate; they are mostly still off by some margin, but it is better than what it was.\nHow we manage to burnout developers faster The same tools we conned the PMs into using are also the cause for a steady increase in dev burnout. With Agile methodologies came a relentless pressure to deliver. The biggest culprit in the Agile world for this burnout is Sprints, and the clue to this burnout is in the name. A project comprises of N Sprints of Q weeks each. A Sprint starts typically on a Monday and ends Q weeks later on the Friday with a technical demo, Sprint planning and maybe a retrospective. That is, if there are no production bugs or testing bugs or unforeseen outages. All this pressure continues week after week, with no downtime, unless you go on leave or the project ends, where the whole process starts over again.\nIn toxic/unforgiving environments where the PM demands that you deliver on promised tasks each sprint, devs work longer and longer hours. Developers are punished for either bad planning, scoping or bugs they made in previous sprints. When under pressure, developers introduce even more bugs because they are overworked and burning out. To me, this scenario sounds very similar to thermal runaway.\nIn the days of the Waterfall SDLC, once development was completed, the project entered a lengthy testing period. Planning and design for new components scheduled for the next release cycle happened in this testing period. Now and again, developers would be interrupted by bugs found during testing, but in general, this time was stress-free and allowed developers to recharge.\nHow we care about the code we write In the past, only people with a bone to pick ran static code analysis tools and told you that some part of the system you wrote had a Cyclomatic complexity greater than 25 or that the Coupling was too high. Great, those things are “important”, but you only knew about them when someone actively chose to perform those checks.\nMore than ever before, we now have to care more about the quality of the code that we write. Not a single week goes by without reading about a company that has been hacked or had a data leak. And 9.999 out of 10 times, the primary cause for this is shitty code written by a dev that swears his code was peer-reviewed, that the snippet on StackOverflow had 2000+ upvotes and posted by none other than Jon Skeet.\nThese days, we have many tools at our disposal to help us find and address these things while we develop the code (okay, not coupling and cohesion; experience and SOLID design principles are the only fixes for those). The many tools at our disposal are, to name but a few: linters, automatic code analysers (C#’s Roslyn Compiler), exceptional race detection in Go, GitHub’s security advisories, GitHub’s dependabot and tools like SonarQube. All these tools, that are primarily free, are helping devs write better and safer code. Because these tools constantly update, code that was fine yesterday can be flagged as vulnerable today due to some buffer overflow exploit in a 3rd party library that you are using. You can choose to act on it or ignore it, but the power is in your hands. I have been on the receiving end of a couple of scathing penetration testing reports in my days. Still, since the advent of most of the tools listed above in the projects I have been part of, I no longer dread penetration tests. I welcome them. These tools are not pointing out my shitty code; they highlight weaknesses in the system, like misconfigured gateways, etc.\nThe Open-source movement has also caused developers to care more about the quality of their code. Making one’s code publicly visible is a vulnerable thing to do. Other people look at it and at times ridicule 🤣🤣🤣 you thought I might say admire. Though it might be hard to do, posting code publically builds a community that care about similar things together to make even bigger and better things. And who benefits from this collaboration? Everyone! Previously most things were closed-sourced and required a license; developers added features slower than humanity has added landers on Mars, and bugs were only fixed if enough people complained.\nSo don’t be that guy that hides all his code in private repos on bitbucket, because of GPT-3. Take the leap and make your code public, share it with others. The worst thing that can happen is that someone will make a PR to correct your bad spelling. I don’t believe that it is my fault my alter ego is Typo Man!, the writer of wrongs.\n","permalink":"https://dbreedt.co.za/posts/changes_changes_2021.html","summary":"\u003cp\u003eAn adage goes: “\u003cem\u003eThe more things change, the more they stay the same\u003c/em\u003e” — that kind of holds true for Software Development.\u003c/p\u003e\n\u003cp\u003eBack in the day, we used to design our systems, write the code, compile it, run it, get it tested and then deploy it. We still do all of that today, regardless of what we are building, be it microservices, large scale monolith systems, mobile apps, websites or firmware for IOT things.\u003c/p\u003e","title":"Changes, Changes everywhere"}]