<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>software-engineering on Youssef El Jirari</title><link>https://eljirari.me/tags/software-engineering/</link><description>Recent content in software-engineering on Youssef El Jirari</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://eljirari.me/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Shipping Fast vs Quality Code Is the Wrong Trade-off</title><link>https://eljirari.me/posts/shipping-fast-vs-quality/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://eljirari.me/posts/shipping-fast-vs-quality/</guid><description>Engineering discussions often frame delivery as a choice:
Do we ship fast, or do we do it properly?
I do not think that is the useful question.
Teams obviously need to ship. A perfect system that arrives six months too late has little value. But moving quickly by removing every quality control usually does not create sustained speed either. It creates deferred work that eventually appears as incidents, fragile deployments and engineers afraid to change the system.</description></item><item><title>It Compiled, But Will It Run? PE Files and .NET Dependency Resolution on Windows</title><link>https://eljirari.me/posts/dotnet-pe-dependencies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://eljirari.me/posts/dotnet-pe-dependencies/</guid><description>A successful build proves that the compiler found what it needed at build time.
It does not prove that the application will find everything it needs when it runs on another Windows machine.
I learned this while working on binary dependency exploration for .NET applications. The objective sounded simple: take every binary we compile and verify that its dependencies can actually be resolved.
Then native DLLs, NuGet packages, .NET Framework, modern .</description></item></channel></rss>