“Why are people so excited to announce the death of software development paradigms?”

/ Robert Harris / Leave a comment

Thus begins John Mecke’s essay Agile is Dead (So is COBOL, XP, RAD, UML, SAFe, etc). It’s an enjoyable, step by step takedown of the {whatever} Is Dead new paradigm promotion treadmill.

The key takeaway … is that you should experiment to see what works in your environment.  Every company is in a unique place at any point in time.  Your market position, your level of resources, your ability to execute are all specific to your situation.  As Dave Thomas says no rules are universal.  What works for Google may not work for you.  

You should not abandon things that have worked in the past in favor of some shiny new toy just because they’re old.  Edgar Codd’s approach to database normalization works just as well in 2021 as it did in 1972.  UML state machine diagrams are still an efficient way of documenting complex designs.  Spring planning, daily standups, and retrospectives are still very effective ways to build software. You should synthesize what has worked in your environment with new ideas.

Legacy == Proven

DLL Hell – Same as it Ever Was

/ Robert Harris / Leave a comment

Everything old is new again.

How it started (1998):

And all it takes is a single DLL, VBX or OCX to be missing, or present in an older version (or even an incompatible newer version), for an application to fail. A poorly designed installation program, user error, registration error or change in the user’s PATH environment variable are a few of the ways in which this problem can occur.

https://www.desaware.com/tech/dllhell.aspx

.Net – our savior (2001)?

.NET’s versioning features promise to do the most to eliminate the DLL Hell syndrome

https://www.techrepublic.com/article/introducing-the-assembly-a-cure-for-dll-hell/

Yeah no (2021)

DLL Hell is an old term that got a new meaning in managed runtimes like .NET. The original DLL Hell issue was that many applications shared the same DLL file dependency. Then, if one of those applications updated that DLL, it broke the API for the other applications, and caused all sorts of trouble.

In .NET we don’t have that problem. In most cases, applications don’t share DLLs, which prevents issues in the first place. When apps do share libraries, they use the Global Assembly Cache (GAC). This is a place to share libraries on the machine, but it’s only for strong-named libraries. When an application uses a library from the GAC, it requests a specific version, and the strong name guarantees it will get that exact version.

But if you think this architecture solved all our problems, you will be disappointed. We still have problems, just different ones (emphasis mine RH).

https://michaelscodingspot.com/dotnet-dll-hell/

We still have problems, just different ones…sums up a lot of “progress” in software development.