Rambling on Software

Mostly about software, but I can ramble about anything...

Those of us who have been developing software for more years than we might care to admit, are sometimes inclined to fret about the skills that junion programmers lack -- particularly those fresh out of university or college. And as is typical with software developers, if you have N of them in the room, you'll have at least N+1 opinions about just what skills are most important and the least well prepared for by our educational institutions. Naturally I have my own opinions and I'd like to argue about why they're important not just for a computer science education, but any type of education. This dovetails with the current trend to assert that computation thinking should become part of our core cuuriculums in both K-12 and post-secondary education.

In terms of skills that I find lacking in most developer straight out of school, the ones that strike me as the most important are abstraction, and its friends encapsulation, cohesion, and coupling. I often find that junio developers have very good skills in the tactical aspects of software development, such as 'what CSS style should I use to achieve a modal type dialogue?' or 'how do I set the isolation level for a transaction?" What they often lack is the skill to consider these types of questions in the overall context of the software that they are working on. Questions such as 'Is it appropriate to set the isolation level for the transaction at this point in the code?' or 'How do I make modal style dialogues easily usable by other members of my team?'

It occurred to me today that these issues aren't really confined to software development at all. The notion of abstraction, that is the ability to construct a mental model of something, and the capability to explore the ramifications of that model, is really what thinking is all about. Or perhaps to be slightly less grandiose, its what strategic thinking is all about. As in software development, people are often quite good at tactical thinking, that is reasoning about some specific instance of a problem, but often cannot draw out of set of problems the common elements that would allow them to forge a general solution to a class of problems, or perhaps worse form false generalizations from anecdotal evidence.

I think that there is an argument to be made that the tools, techniques, and terminology that we software developers have created to help us reason about abstraction and encapsulation, could in fact be the basis for a way to teach people how to think strategically, not just about software, but about anything. As I noted above, there is some effort underway to convince the education establishment that the world has changed, and computational thinking is something that eveyone needs. But perhaps the situation is really that we need to convince the educational establishment that we have way to teach people how to think, not just about information systems, but about anything.

I just spent a couple of hours working with another developer on a weird request latency problem in certain ASP.NET requests. We've got an aspx page with a number of images that are themselves fetched via an aspx page (because they are being pulled out of the DB). When looking at the timeline for these requests in Chrome, most of them would complete quite quickly (less than 200 ms) but typically there were 2 that took much longer; one usually around 1 sec, and then other usually around 500 ms. We already had logging in place that was measuring the time from BeginRequest() to EndRequest(), and the logs showed a consistent processing time for all of the image requests, even the two that were taking much longer to get back the browser.

So, we added a bunch more logging so that we could timestamp each step in the ASP.NET pipeline. This allowed us to pinpoint that the extra time was being taken between PostMapRequestHandler() and AcquireRequestState(). A little searching on the net led us to this article which suggested that the problem was blocking due to the need to obtain a lock on session state. We use session state in a couple of places, so it is enabled throughout the application. However, in most places, including the code for fetching images from the DB, it is not used. So we changed the @Page directive on the image grabbing page so that EnableSessionState was set to ReadOnly.

Voila! All the image fetching requests now took roughly the same time.

To be fair, Microsoft's documentation on session state actually warns you of this issue. And in general, I'm not a big fan of using session state anyways. Nonetheless, I was a little surprised that pages that don't actually use session state can end up having their performance degraded just because sessions state is being used at all.