I was wrong. According to the National Weather Service, Chicago did in fact have an official day entirely above freezing yesterday. The temperature only only got down to 1°C, which turns out to be the warmest night we've had in Chicago since December 4th (4°C).
Spring is right around the corner, and could get here by mid-June even.
Via a colleague comes Mike Monteiro's famous presentation to Creative Mornings SF from two years ago. It's applicable to just about any creative endeavor, including software development:
The last 24-hour period of above-freezing temperatures in Chicago was back on December 28th. Usually we have multiple stretches above freezing every so often throughout winter. This year, not so much. In fact, since the start of meteorological winter on December 1st, we've only had three, for a total of five days.
Over the last two days we came this close. Sadly, though, the temperature briefly hit 0°C at 9pm yesterday evening, and the forecast calls for not just sub-zero (Celsius) temperatures tonight, but a sustained, week-long period where the temperature stays below freezing.
Really tired of this now.
Researcher Capers Jones has examined well-known "laws" of programming against the data. The one that jumped out at me:
Cunningham's Law of Technical Debt
Shortcuts and carelessness during development to save money or time lead to downstream expenses called "technical debt" that may exceed the upstream savings.
Empirical data supports the basic concept that early shortcuts lead to expensive downstream repairs. Ward Cunningham's technical debt concept is a great metaphor, but not such a great metric. Technical debt omits projects canceled due to poor quality. Since about 35% of large systems are never finished, this is a serious omission. These failing projects have huge costs, but zero technical debt because they are never delivered. Technical debt also omits the costs of litigation and damage payments for poor quality. I worked as an expert witness in a lawsuit for poor quality control where the damage award to the plaintiff was more than 1,000 times larger than the technical debt to fix the bug itself.
In other words, quality issues cause more damage than programmers think. There's no substitute for early quality.
After getting another 100 mm of snow last night, today it's warmer than it's been since January 13. The 2pm O'Hare temperature was 6.7°C. If it hits 7.8°C, it will be warmer than any day since December 28th—which was also the last day the temperature did not fall below freezing.
Already the 340 mm of snow on the ground has started to melt. And the storm drains are covered in snow and ice. So we'll all be trading in our snow boots for flippers this time tomorrow.
Update: The 4pm temperature was, in fact, 7.8°C.
In the last hour, we've gotten another 25 mm of snow, with more on the way:
The initial stages of snowfall will come in bands this morning (check weather radar pic above) – moving from southwest to northeast. A few locations are observing a mix of snow and sleet and this will continue on and off for the next couple hours, but the precipitation will change over to all snow and increase in intensity late morning and afternoon. Homewood in Cook County reported an inch of snow in an hour with a mix of sleet. Below is the 9AM CST visibility map depicting the variability of snowfall across the Chicago area.
A band of light to moderate snow is moving though the area this morning and could drop a quick inch of snow in many locations. This band will end and there will be a break before the main area of heavy snow arrives later this morning. Winter storm warnings are in effect and snowfall totals of 100-200 mm are expected before the system moves out this evening.
The original prediction called for just 25-50 mm; apparently the snow got excited.
Meteorological winter ends in just 11 days. Actual winter may last longer.
I spent 4½ hours today upgrading three low-traffic websites in order to shut down an Azure database that cost me $10 per month.
The problem is this: I continually improve the Inner Drive Extensible Architecture as I learn better techniques for doing my craft. The IDEA began in 2002, and the industry changes rapidly, so every so often it changes significantly enough that things using earlier versions break when they're upgraded. About a year ago, version 2 ended and version 3 came out, breaking everything that used version 2.
Except, I still had some things out there using version 2, including its clunky data architecture. Therefore, I had to keep its clunky data architecture running on its own Azure database, at a cost of about $10 a month.
The three sites involved date from 2004, 2006, and 2007. All three moved to Microsoft Windows Azure by mid-2012, but unfortunately that means all three used the Azure SDK 1.7, which Microsoft killed somewhere around November 2012.
Upgrading from a dead version to a live version requires some effort. So for 4½ hours today, I dealt with version conflicts, expired publishing certificates, niggling little configuration errors, and a virtual machine that needed a critical upgrade. Along the way I gained 10 Stack Overflow reputation points because other people have felt my pain, but didn't know how to get past it.
This is a good example of yak shaving, and also the fundamental principle of software development: enlightened laziness.* Had a client needed me to do this work, each upgrade would have cost the client around $300 (which, being a salaried consultant, I would not have actually received). So it wasn't horribly expensive, but remember: I did this to save $10 per month.
So, from a commercial perspective, today's activities made no sense. Yet I feel completely satisfied that I solved a problem today that had bothered me for months.
* Why spend 10 minutes on a task when you can spend 4 hours automating it? By these words ye shall know software professionals.
I remember, back in .NET prehistory (2001), that one of .NET's biggest benefits was to be the end of DLL hell. Yet I spent half an hour this afternoon trying to get a common package (Entity Framework 6) to install in a project that never had that package in the first place—because of a version conflict with .NET itself.
When I tried to install EF6, the NuGet package installer failed the installation with the message "This operation would create an incorrectly structured document". A quick check of StackOverflow suggested a couple of possible causes:
- The Entity Framework installer creates an invalid web.config file because it gets confused about the older project's XML namespaces.
- The EF installer chokes on .NET 4.5 and .NET 4.5.1 because it's broken.
Anyone who's spent time with Microsoft products should immediately suspect that hypothesis #2 is unlikely. No, seriously: Microsoft releases things that have bad usability, rude behavior, and incomplete features all the time, but they have some incredible QA people. This fits that pattern: the installer script works fine. It just has pretty dismal error reporting.
So after removing every trace of EF from the relevant files, and downgrading the app to .NET 4.0 from .NET 4.5.1, EF still wouldn't install. Only at this point did I start thinking about the problem.
Let's review: I had an error message about an incorrectly-structured document. The document in question was almost certainly web.config, which I could tell because the EF6 installation kept changing it. The web.config file is an XML document. XML allows you to specify a namespace. This particular XML document had a namespace defined. A Stack Overflow commenter had mentioned namespaces. Um...
At this point I changed the web.config header element from this:
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
to this
<configuration>
That fixed it.
The moral of this story: read error messages carefully, form hypotheses based on the data you have available, and even before that, stop and think. And even if you're not a Microsoft developer working on NuGet package installer scripts, always give as much detail as possible in error messages, so that developers who read them can spend less time trying to understand why the operation they thought was simple took so long to accomplish.
Regular readers of this blog know how irritated I get when error messages don't actually explain the error. I'm on developers for this all the time. It's rude; it's lazy; it costs people irrecoverable time. This is one of those times.
The Great Lakes have more ice cover than at any point in the last 20 years. Here's the view on the flight in last Monday morning:
If you don't mind a 150 MB download, NASA took a photo of the Great Lakes (and, incidentially, me) at almost that exact moment. The ice today (also 150 MB) looks about the same.
I got gas today, which isn't that interesting in itself, except that it's only the third time I've gotten gas in the past four months. Like the last time, I decided to fill up in case it got cold (a full tank is better for your car in winter), so really I've only gotten about 2½ tanks of gas since the beginning of November.
It's perfectly valid to wonder why I even own a car. I didn't for most of the time I lived in New York. Still, today I had about a half-dozen errands to run, and having a car made a huge difference, especially to Parker. If I only used Zipcar, for example, I wouldn't be able to bring him around either.
Still, this is why I like living in a big city.