Bob On Development

The other day it came to me that sooner or later, I’m going to have to face it.

I’m doing all my development work on Windows XP SP3. It meets my needs just fine. But at some point in the next couple of years, I’m going to need new hardware, and by then, I’m going to be faced with Moving On.

I’ve had some pretty snide things to say about Vista in the past year and a half. It amounted, more or less, to saying that Vista is the work of the devil. My issues with Vista came partly from adopting it too early, when it was plagued with flaky drivers, and I’m now convinced that the new hardware I was using had a flaky memory controller that was contributing to the general chaos. Even so, I remain convinced that Vista is an obese, dysfunctional stain on the soul of humanity.

But I figured that by the time my hardware cycle pushes me forward, Windows 7 will be past its shakedown cruise, and surely the “version 1.1 effect” will kick in.

In the past few days, though, some reviewers have gotten an early look at Windows 7, and early word is not encouraging. In fact, InfoWorld’s Randall Kennedy was so bold as to label Windows 7 “Vista with a new coat of paint”. Still slow, still baroque, and still proud of it.

Kennedy even advocates giving some serious thought to cutting and running. He thinks the enterprise should be taking a good hard look at Linux and OS/X. Microsoft’s recent baffling ad campaign for Windows wasn’t exactly a confidence builder, either.

I have to confess that the main thing that keeps me in the Microsoft camp is the development ecosystem. Visual Studio, the Common Language Runtime, and everything in its orbit rocks. And I have lots of demand from paying clients to build solutions with that platform.

My guess is that Microsoft is sitting more or less where the British Empire was in 1895 or so. It’s an interesting parallel: the Brits controlled a quarter of the planet’s surface area and about the same percentage of its population. It seemed unassailable. Yet, it was coming apart at the seams just a few years later. It had become an international pariah for its bone-headed, arrogant, and tone-deaf handling of the Boer War. Within a couple of decades, World War One bankrupted the British Empire, effectively ending its reign as a world power.

Does a similar fate await Microsoft? I hope not, but some days I wonder. Personally I think they should clean house on the OS side, put the development tools in maintenance mode for a couple of years, and put Scott Guthrie and the rest of those geniuses behind Visual Studio to work on building a new OS from scratch.

The good news is I’ve had some client changes and I’m doing even more interesting and rewarding work than I was the past year or so, which is saying a heck of a lot.

The bad news is it’s all in VB.NET.

This isn’t really all that bad except for the configuration side of things. After all, once up on a time, I toiled for years in the salt mine that is VBScript.

But I still run afoul of Visual Studio’s VB.NET configuration defaults. It wants to turn things off by default so I can’t find them, hide “advanced” features behind innocuous buttons, and make really presumptuous defaults in order to save me from the horrors of having to declare things in code.

Case in point: today I created an empty class library project with VB.NET as the language. I wanted this to be in a namespace, call it MyCustomer, so — as I would have in C# — I wrapped the class definition accordingly:

Namespace MyCustomer
   Public Class MyClass
   End Class
End Namespace

I got that solution set up with a project reference and a couple of public members and got a clean compile.

Then I went to another solution and added the new class library project to it, added a project reference to my new class library, and so on. And proceeded to spend the next 30 minutes pulling my hair out trying to figure out why “Imports MyCustomer.MyClass” was not finding the namespace or at least not any public members within it.

Then I calmed myself down and stopped to think about what I had done in all this that is not an everyday thing that might have tripped me up last month or so. The older I get, the fuzzier memories prior to the past few days seem to get. Then it hit me: VS wants to assign a “default namespace” to a VB.NET project. That default namespace in my new project happened to be named MyClass. So to get to my class I actually had to “Imports MyClass.MyNamespace”, which was of course insane. So I changed the default namespace (in the project properties, Compile tab) to the empty string and all was sweetness and light again.

This “helpful” default effectively destroys some of the one-to-one correspondence between VB.NET and C# code. It’s writing code via configuration, effectively. I can understand why it was done — to get novice VB.NET people who come from the VB6 world up and running quickly, writing code without the annoyance of declaring namespaces. But for a person who has lived in the C# world since 2002 this is just idiotic. A C# project template would have the namespace laid in already for you, what’s wrong with that? Then you can see that it’s there, and change it or take it out of you want. No phantom code in sight.

So now I could spend another 20 minutes hunting around for configuration settings that would make VB.NET project behavior more C#-like. But I’ve already lost 30 minutes of my life I’ll never get back, and besides, I’m trying to use defaults that most VB.NET people would so that I can talk intelligently about working in the VB.NET world.

Thus endeth the rant.

Some time back I opined that a good command of the English language helps you be a better developer. Tonight Steve Yegge did a great, if someone lengthy, companion piece suggesting that typing skills are also related to being an effective developer.

I think Steve’s autobiographical narrative of his high school typing class is deliriously funny but here’s the short, bullet point version for the time-challenged:

• Developers type all day long, even when they’re designing.
• Poor typing skills subtract from design and coding time.
• Poor typing skills inhibit your online interactions in crippling ways.
• A poor typist’s code tends to be under-commented and poorly formatted.
• Refactoring tools are no substitute for good typing skills.

Steve actually makes an excellent secondary point: the industry’s other dirty secret is that an astounding number of developers can’t even read. But that’s a rant for another day.

Typing is not rocket science. If you haven’t become proficient at it (which I personally define as being able to type the limited and specialized vocabulary of a programming language at 60 wpm or better, and general content at a bare minimum of 40 accurate words per minute) then there is really only one reason.

You’re lazy.

There, I said it.

Get one of those fun typing tutors and dedicate a 20 minutes a day for a few weeks and see if it doesn’t make a huge contribution to your development chops.

I encounter this code very often when the intent is to remove multiple spaces from strings and reduce them to single spaces:
someString = someString.Replace("  "," ");
No, no, no. This will find all instances of two spaces and replace them with one, provided that the instances aren’t consecutive. In other words consider the following string, where spaces are replaced with periods for clarity:

FOO..BAR..FOO

The above code will reduce this to FOO.BAR.FOO as expected. But suppose we have this:

FOO…BAR…FOO

Now we get FOO..BAR..FOO. Uh-oh.

The only foolproof way is:
while (someString.IndexOf("  ",StringComparison.Ordinal) > -1) {
  someString = someString.Replace("  "," ");
}

The included StringComparison enum is optional and not relevant to this discussion but I throw it in there to remind you that if you’re not dealing with culturally sensitive strings, using Ordinal or OrdinalIgnoreCase comparisons is faster. And since you’re dealing with spaces, the very fastest possible Ordinal comparison makes sense in this case, even if the rest of the string may be culturally sensitive.

For some reason, I haven’t had to do this in a long time, so had to look it up.

There are three options for doing case-insensitive regular expressions in .NET.

The first is to use the RegexOptions enumeration to specify case-insensitive behavior:

Regex.IsMatch("Fubar","^fubar",RegexOptions.IgnoreCase)

The equivalent option is to put (?i) at the start of the expression. This is useful if you want to feed data-driven patterns to the matching engine and control from the expression whether it’s case insensitive or not:

Regex.IsMatch("Fubar","(?i)^fubar")

Lastly, you can put part of an expression in a group and specify that only that part is to be case insensitive. In this example, Fubar is matched case sensitive but FOO is not:

Regex.IsMatch("Fubar Foo","^Fubar (?i:FOO)")

My old friend Whil Hentzen, who is still somehow making a living in the FoxPro world with a side of Linux, posted a hilarious and enlightening explanation of Twitter, how it’s used in the real world, and why it might be necessary to indulge in even if you were born before dirt was invented.

I’m almost persuaded.

Insanely hilarious stuff — if you don’t “get” twitter you should definitely read it.

I’m fortunate to be paid well for doing something I love. But I know quite a few developers for whom software development is not a joy, but a job. Nothing inherently wrong with that, and in fact, I think it’s inevitable as the craft matures. Even so, I’m seeing a little too much of certain things lately, for example:

Try blocks with empty catch blocks. The legitimate uses of this little trick are so super-rare that we might as well say it’s Evil. Even when you do it temporarily it’s Evil because you inevitably forget to take it back out. Just cut it out, okay? I’ve seen code, for instance, that loads records into a database, where maybe 20% of the records vanish silently into thin air because some minor, easily fixable exception is masked. Don’t make me come over there.

Failing to do simple things to make code more robust. I’m getting a little tired of noobish code that concatenates date strings together and then parses them in the blissful assumption that the code will never be run under any locale other than en-us. It is no harder to just use the DateTime constructor, but people don’t do it because … why?? I really don’t know.

Have a little pride in your work. If you really don’t care … find something you care about and do that instead.

Thanks. Carry on.

In my last post I mentioned that powerful forces are working to bend software development to the needs of mass production. It’s only partially successful, compared to, say, the mass production of automobiles, but it’s successful enough to have a big impact already on software developers. Consider the following things we already do pretty much without thinking about it:

• Use a set-oriented query language that specifies what to find, not how to find it (SQL)
• Use designers to create user interfaces (e.g., WinForms, WebControls)
• Use code generators to produce the skelton of things like components, services, and data access layers.

Quite awhile ago in one of my most popular posts, I made gentle fun of the goals Charles Simonyi’s company, Intentional Software. I was very skeptical that Intentional would succeed in capturing business rules and requirements in a way that would allow useful, maintainable, performant, quality software to be generated from such a captured spec.

On the other hand, it is possible that Intentional’s initial blue-skying has been tempered enough by reality to reconsider. It certainly has Microsoft’s attention, because Oslo, their road map for the next release of Visual Studio (2010?) appears to contain very similar technology.

Indeed, some of Microsoft’s other trial balloons, such as Volta, seem to be heading towards similarly higher levels of abstraction.

It is incredibly ambitious to invent a world where you and I will be writing XML documents describing what an application does rather than how it does it. But Microsoft has the billions (and the brain trust) to pull it off, if anyone can.

That said (ahem) I’m still a skeptic. Is it just me, or is this description by Charles Petzold of a new XAML-like version of C# that’s apparently gestating over at Intentional just making matters worse? Petzold describes three simple lines of C# as a “notorious syntactical absurdity” and then replaces it with something he says “can almost induce the modern programmer to weep for joy”: 45 lines of XML! Lord have mercy.

I’m sticking with my mantra that I’ll look into these things when I can see that they make business sense. It’s not ready for prime time yet!

I read a post this morning about the “lack of craftsmanship” in software development. The basic argument in a nutshell is that the “lack of commitment to quality” is pushing the whole industry towards the “commoditization” of software development. In fact, the author feels that “the days of in-house software development as we know it are in danger of extinction.”

Despite the fact that I agree with the author that “commitment to quality” is generally weak and contributes to the problem, I believe that larger forces are the primary driver behind this trend. It wasn’t lack of craftsmanship, after all, that resulted in the success of Henry Ford’s mass production methods. It was the demand for quantity at the expense of fit and finish. And let us not forget that the mass-produced Model T was not better or even easier to use than many of the hand-crafted cars that preceded it. That didn’t stop it from being a success.

Closer to home, the success of DOS comes to mind. It was an adequate product at the right time and price point. I’m not pretending that this fact is appealing to me as a craftsman, but I have to acknowledge that is was a success nonetheless.

History is full of examples of new products, produced originally by craftsmen, and eventually bent to the will of mass production. It’s a basic, natural business and technology cycle issue any time you’re dealing with something that there is a quantity demand for.

We’re in a similar situation in the software industry. Business and government need software of all kinds more than ever, but we can’t produce and maintain / extend “good enough” software in the quantities and within the time frames that the world needs (or thinks it needs, which in practice amounts to the same thing).

The only thing that has saved custom software development at all is that software does not, and never will, lend itself to commoditization efforts to the extent that mass produced physical goods will. However, it lends itself to more commoditization than most developers give it credit for.

Consider humble VisiCalc, the first spreadsheet program. It was a metaphor that took the world by storm, simply by allowing a small subset of bean counting and statistical tasks to be performed by non-programmers. I submit to you that Excel 2007 has just taken spreadsheets to the next level, by the simple expedient of removing Excel’s old 65,535 row limit. Several versions back, Excel acquired some basic database functionality, resulting in much mirth amongst database developers as accountants and casual developers tried to make Excel serve as a crude “database”. The exponential growth of typical table sizes so that a table of over 64K rows is no longer considered huge or even hefty, has pretty much knocked Excel out of the competition for awhile. But suddenly, it’s back in the running again, with bigger capacity, better DB features, and with user-friendly features like pivot tables in place of SQL GROUP BY queries. And with multiple sheets, users are no longer limited to single tables, so we’re not just talking about a simple list manager substitute here. Add in the ability to read and write to real databases with greater and greater ease, and you have modern Excel “spreadsheets” doing more useful work than the custom applications of twenty (or in some cases, even ten) years ago.

Now of course the scope and reach of modern database applications has also grown, and it’s still way beyond what even the newly beefed-up Excel can cope with. But the point is, at the low end — where it doesn’t need to scale and where standard capabilities are “good enough” — there will always be a place where casual and non-programmers can get by without us. And what constitutes “low end” is constantly growing. Eventually, “low end” will probably encompass all the elementary things that a small to medium-sized business needs for it survival, and the projects that require actual skilled developers will probably be more and more esoteric.

I see no point in bemoaning this. It’s just the usual march of progress. It’s not up to reality to conform to us. We have to conform to reality.

The only question is in how we chose to place our bets. What will we educate ourselves about? What kinds of projects will be seek out? And with how much urgency?

One thing’s for sure. The world is moving too fast to imagine that the craft of development will look anything like it does today, some twenty or even ten years hence. It was possible for a developer to learn COBOL in 1965 and stick with it until retirement, provided you didn’t care about the bleeding edge or the top dollars throughout your career. But I very much doubt that C# or VB.NET or even the darling of the moment, Ruby, will be employing anyone at all come 2040.

That’s going to burn a lot of people in this business, because for all our embracing of computer technology ahead of the rest of society, we developers have a strong conservative streak in us. We become emotionally attached to certain platforms and even languages, and fight to the death to keep them alive. A lot of us find something that appeals to us aesthetically and want to stick with it because it becomes our identity. That’s not going to work any more.

I am currently responsible for a fairly large members-only web site that was originally authored in classic ASP years ago and has been partly migrated to .NET. One’s impulse is, of course, to move it to VS 2008 and then go about purging the last of the classic ASP stuff. However, this might be bass-ackwards.

A factor I hadn’t considered is that VS 2003 has built-in support for debugging classic ASP pages, and that this support was removed in VS 2005. So VS 2003 is arguably the place to be if you have a mixed classic / .NET site. You might want to finish porting the legacy pages and then upgrade to the current platform.

It is still possible, however, to debug classic ASP from VS 2005 (and I presume 2008) if you’re willing to manually attach the debugger, but it sounds too much like work to me. You can even cruft up a VS 2005 template so that classic ASP pages show up as a project type and/or file menu item. But you might want to give serious thought to porting the classic ASP pages to ASP.NET before migrating to the current version of Visual Studio. The only downside I can see of doing the port in VS 2003 is if you really, really need to use goodness from CLR 2.0 or later.