We Are Building on Sand
As a software community, we suffer the fate of a million little cuts. We build systems built on top of other code, layers upon layers upon layers. And, unfortunately, each layer isn’t very solid.
This last week while teaching some students, I ran into a seemingly small issue with an Azure Function. Azure Functions are a really awesome way of hosting some code in the cloud. I had a simple endpoint and just needed to pass some data using a query string on a GET request. Something pretty basic.
My frustration started with an error I received while trying to retrieve something from a query string. The error wasn’t super descriptive but implied it couldn’t find the get_Item method on the query string. This was weird because it worked just seconds before. The only change I had made was referencing my business logic project from my Azure Function project.
System.Private.CoreLib: Exception while executing function: Function1. CompoundInterestBackend.Functions: Method not found:Â ‘Microsoft.Extensions.Primitives.StringValues Microsoft.AspNetCore.Http.IQueryCollection.get_Item(System.String)’.
So I tried updating to the latest version of Azure Functions, which changed the error message slightly, but still resulted in an error.
System.Private.CoreLib: Exception while executing function: Function1.AzureFunctionMortgageCalculator: Could not load file or assembly ‘Microsoft.Extensions.Primitives
I didn’t write this post to describe an Azure Functions error. What I encountered is a small example of a very real problem in the software development world. Frameworks and other foundational components simply are not robust enough for us to build software with. How can we rely upon frameworks when we get weird errors like this without reason? This sort of thing shouldn’t happen.
We need to get to where frameworks just work. As long as the foundations we rely upon have problems like this, we are guaranteed to have a tough time with many other issues, such as estimation.
Does this mean we shouldn’t use frameworks? Well again, like so many things in software, there are problems everywhere. What else are you going to choose?
Probably the best we can do right now is mitigate the inherent weaknesses of our frameworks and components. So how do we do that?
Before going too deep into a project, write some smoke tests. These will help ensure that all of your technical pieces will work together before you get too far down the road. Also, I recommend building upon known technologies. Sometimes we get so focused on the new shiny technology when there is existing technology that probably has fewer issues.
