Having spent the second half of my software engineering career doing ‘agile’ development, I think I’ve spent more time trying to convince people what agile is not than explaining to the uninitiated what it is. Since the so-called manifesto was published in 2001, the whole thing’s been so abused, monetized and co-opted that, for all intents and purposes, it seems to have lost any tangible meaning. By 2014, I had basically decided I would simply use the word ‘lean’, since the culture around agile was so polluted with nonsense…
What made this thing so popular in the first place? I remember reading about it and feeling like it was a bit revolutionary… I was excited by it. Excited because, in many ways, it was a repudiation of decades of stodgy and bureaucratic software practices that I always despised. My blog is called ‘On the Contrary’, after all, so I naturally found this upending of the table appealing.
If I peel back the layers and get at the hot molten core of agile, though, what is it really? What was its intent?
My central idea was to use SSDT to build a dacpac file that would define the schema of our testing database and wrap that DACPAC artifact in a nuget package that testing projects could reference.
It’s not uncommon during early attempts to bootstrap CI and automated testing for an engineering team to start with ‘unit’ tests that read and write to a common development database. Truly, these should be considered more integration tests than unit tests, since they touch more than a single layer of the architecture, but that’s not the main drive of this particular post. My primary goal in adopting testing culture is increasing the amount of reliable and automated testing. Moving towards more pure unit tests will be a drive towards making our automated tests faster (and probably improved architecture)…but that is a problem for a future day.
Serious problems require a serious tool… Meetings should center on concisely written reports on paper, not fragmented bulleted talking points projected up on the wall.
If every software meeting that you attend is being driven by a PowerPoint deck, don’t kid yourself: you’ve got yourself a serious problem. This is a sign of an acute infection of bureaucracy.
Let’s face it, most software decisions… whether it be design, prioritization, process, budget… are conversations that need to be had at a detailed level. PowerPoint presentations, almost by design, forces your meeting participants to gloss right over those details. It implies tacit agreement with high level, and mostly generic points and statements that often bear little to no significance to the problems being discussed.
Let me illustrate by identifying some glaring symptoms of the PowerPoint infection:
Ever heard of the SQL_VARIANT_PROPERTY function? I didn’t think so.
SQL Server developers very often make the mistake of making their NUMERIC fields too large. When faced with a choice of how to size the column, they’ll often think “make it way larger than I need to be safe”.
This works OK as long as you simply store and read these values, but if you ever have to perform math with these columns, particularly some form of division or multiplication, you may find your results mysteriously losing precision.
This is because SQL Server can only store a maximum of 38 digits per number… if the results of your mathematic expression may yield a number larger than that, SQL Server will be forced to downsize it and remove digits from the mantissa as a result.