Archive for the 'Software Development' Category

Mama, don’t let your babies grow up to be coders

Monday, June 1st, 2009

A few  months ago I wrote a column for Visual Studio Magazine titled “Where have all the developer’s gone” in which I pointed that interest in programming and computer science seems to be dropping – at least in the United States. And in fact, much of the interest in learning programming seems to be in countries like China, Pakistan, etc. I concluded with a somewhat cautionary note that if we want our kids to become the technologists of the future, it’s up to us to do something about it.

This brought forth a great deal of comment, one of the most interesting questioning why anyone would encourage their kids to go into the software business in the first place. Why would you go into an industry where it’s increasingly difficult to keep up, where jobs are increasingly being outsourced, and where there is rarely long term career viability? Doctors can continue treating patients into their 60’s and 70’s, Lawyers continue lawyering, bankers banking and politicians politicking until they drop dead (and sometimes longer in the case of politicians). But past 40 or so, software developers who aren’t fortunate enough to have solid management gig are likely as not to find themselves unemployed or in some other career.

I’ve been particularly fortunate in this regard. Through a combination of being self-employed, honestly passionate about technology, and a bit of talent, I’ve had the opportunity to continue coding. What’s more, I’ve had the freedom to diversify into all sorts of new technologies beyond my core expertise. But keeping up is an effort. I often compare the life of a software developer to that of Alice in “Through the Looking Glass” – where Alice is told by the Red Queen that she has to run as fast as she can just to stay in place, and to make progress she has to run even faster

Why would anyone wish this on their kids?

It seems that our interests as a nation are radically different from our interests as individuals. There is no doubt that we need a lot of skilled engineers and programmers going forward. Not only do we need to maintain our existing technological base, there’s going to be increasing demand for power engineers and some incredibly sophisticated software to handle the future smart grid (or EnergyNet” as Juval Lowy calls it). Where are those developers going to come from?

I suppose we can continue to import them. But will the United States continue to be a desirable place for migrant technologists? To some degree it is likely, but as their local economies develop, they may find better opportunities at home. And many engineers consider foreign workers to be part of the problem – competition that makes it even less desirable to enter the business. But let’s assume for the moment that for the foreseeable future foreign nationals will continue to provide needed support our technological society, and that it is in our national interest for them to do so – thus making home-grown talent less essential.

What do you encourage your kids to study if not technology?


Old Tech Rules

Thursday, February 26th, 2009

Yesterday I needed to do a simple Excel add-in.

No problem, right?

Being an experienced .NET developer, I figured this would be a good time to try the Visual Studio Office system – to create the add-in using VB .NET. I mean, how hard could it be?

Not hard at all as it turned out. The project template for the add-in worked well, and it took no time at all to find some simple examples online to build on. I had enough familiarity with the Excel object model to make short work of the task at hand, and the integration that allowed debugging of add-ins in Visual Studio worked brilliantly.

Then it came time to test deployment – as I needed to provide this add-in to a couple of clients.

What a fiasco.

The setup project that was created didn’t work. The instructions on MSDN and other sites for diagnosing problems were complex and unreliable. I found additional articles with suggestions for creating custom installation actions to handle the security issues that might have been the problem. There were clearly differences between versions of the Visual Studio office runtimes depending on framework version and versions of Excel to support, with no clear explanation of which to use and how to create a deployment that will work with both.

I spent as much time trying to figure out the deployment as I did creating the add-in when I decided I was wasting my time. The Visual Studio office support may be nice, but the deployment solution and documentation is abysmal. Microsoft should be ashamed to have released it. It is perhaps the most disappointing experience I’ve had with any Microsoft developer technology.

I ended up porting the code to VBA in an Excel workbook and creating a .xla Excel add-in. Though I missed the intellisence of Visual Studio, the building and debugging experience was fine. And deployment was trivial – save the workbook as an add-in. Deployment consisted of browsing to the add-in file and enabling it – and the add-in worked perfectly on Excel 2003 and 2007 the first time I tried it.

I’d come to think of .NET as current technology rather than the wave of the future. It’s clear to me that at least when it comes to Office, .NET is still future technology – costly, complex and unreliable. If I need to do any more Office add-ins, you can bet I’ll stick with VBA.

New article out: Show Me The Money

Friday, December 5th, 2008

My latest article, title “Show Me The Money” about what it means to be a software developer in recessionary times, has been posted on

With a loss of 538,000 jobs in November announced today, I really, really wish I hadn’t been quite so prescient when I submitted this a month or two ago….

Can you really rent-a-coder?

Friday, November 14th, 2008

Over the past year or two I’ve kept an eye on the various online consulting sites – Elance,, RentACoder, oDesk. I’ve actually used RentACoder once (as a buyer on a very small project) and was satisfied with the results – though I suspect I spent more time writing the spec and managing the programmers than I would if I had done the work myself.

I do think we are likely moving into a recession the likes of which our parents and grandparents talked about (shhhh… let’s not use the D word). But I also think it is a very different world – and whatever ends up happening will not be like the 1930’s. One of the big differences is, of course, the Internet.

These online consultant sites (and more that I expect will appear) are part of the difference. I expect more people (not just software developers) will find themselves taking on project based jobs as compared to employment as things get worse.

Yesterday I wrote a column introducing these four online consulting sites – if you are not familiar with them you might want to check it out.

For those who are familiar with the concept, and perhaps with one or two of them, you might be interested in my follow-up column that compares key features of all four sites.

I’d be interested in hearing of experiences you may have had (good or bad) with any of them.

The Dilbert Principle and Emotional Context

Wednesday, April 16th, 2008

Ted Neward posted a great article today “Do you fall prey to technical folk etymology?” in which he suggests (correctly) that we based our technical decisions on emotional context.

Ted is a fine writer, and his points intelligently argued. I am perhaps a bit more direct (crass?) and less politically correct, so I thought I might elaborate a bit on his thoughts. It is not just that our technical decisions are influenced by emotional context. In fact, the Dilbert Principle applies – we are all sometimes idiots.

As technologists we delude ourselves into thinking that we make clear-headed decisions based on logic. Nothing can be further from the truth. Not only are we influenced by emotional factors, they are often the dominant factor in our technical choices.

I remember noticing even as a kid how fads would come and go in our neighborhood. One week it would be spinning tops, another paper airplanes, another endless games of Monopoly (today’s equivalent would be video games and web sites – and I date myself intentionally for reasons that will soon become apparent). Technology fads operate in much the same way, though the time span is measured in months and a few years instead of weeks and months.

The C# vs. VB .NET debate has been raging for years, with the VB .NET folks claiming (correctly) that it’s a fine language and raging that Microsoft insiders refuse to give it the support and respect it deserves. Meanwhile the C# folks feign obliviousness (oh, we didn’t provide VB .NET support or samples for that new SDK? Oh… well… uh… we didn’t have the resources?).

This misses the point entirely. The C# vs. VB .NET dilemma is purely emotional. The VB .NET folk (of which I am one) will continue to use the language because, gosh, it really is a bit more productive than C#. Besides, any good VB .NET programmer can read C# examples or even code C# if necessary because we know it’s all about the framework, and any half competent VB .NET programmer can do C# in a matter of hours, if not days.

Meanwhile the C# developers within (and outside of) Microsoft will ignore, denigrate or avoid VB .NET because, let’s face it, it gives them something to feel superior about. When a C# developer says “VB .NET is the language of idiots”, by implication that developer is not an idiot. That’s a strong emotional statement – especially given that the rapid pace of technology change means that each and every one of us spends more and more time feeling like an idiot (which we are, in the sense that the percentage of available knowledge that we know continues to decrease because what there is to learn increases faster than anyone can possibly learn it – I’m just one of the relatively few people willing to admit it openly).

If a C# programmer, can gain some emotional comfort to offset this by labeling VB .NET developers idiots, who can blame him or her?

I’ve reached a point in my career where many working software developers are younger than I am (many of my contemporaries have become managers or architects, and while I do some of that, I still write lots of production code – mostly because coding is what I enjoy most). I’d always bought into the idea that software development was a “young person’s game” and wondered how long I’d be doing it – but I’m beginning to wonder if that too was an emotional belief unfounded in truth. I’ll write more on that later.

What I do know, that many younger programmers don’t, is that the amazing “new” technology that they are excited about that is sure to change software development forever is, more likely than not, just another fad. Moreover, I also know that most of the new technologies coming from major vendors (including Microsoft), though always labeled as “new technology that is going to change the way people develop software or use technology” is, more likely than not, just marketing hype that is trying to create another fad.
Ok, that’s phrased a bit cynically – because it makes it sound like they are being manipulative. They aren’t (mostly) – it’s just that they, like everyone else, are viewing the technology through an emotional lens. My emotional lens is scarred and cloudy, not because I’m a pillar of reason (I’m not), but because after you’ve lived through enough fads you get better at spotting them. Or put another way, once you’ve been burned often enough you start thinking twice about what part of the technology furnace you shove your hand into.

I don’t know that I’ve gotten better at making reasoned technological choices – but I’ve gotten a lot better at avoiding emotional and unreasonable technological choices – and in figuring out when it is ok to make a technology choice based on emotion.

Ted asks at the end of his post:

“In short, I actively seek to defeat technical folk etymology, if only in the small area I personally can affect.

Do you?”

You can’t defeat it – emotions will almost always trump reason. But sometimes you can co-opt it. Fads aren’t defeated by reason – they burn themselves out naturally only to be replaced by the next fad. Just remember that when you’re trying to prevent someone from making a terrible choice based on emotions, it’s not enough to use sound reasoning – you need to come up with an emotional argument as well if you hope to succeed.

Coding Time

Friday, November 2nd, 2007

They say life is a balancing act. Certainly one I share with most of you is figuring out how to balance time between learning new technology and actually getting work done. This is particularly challenging for those of us who spend all or part of our time writing or teaching others – especially at times when another version of Visual Studio and the .NET framework is heading towards us with the inevitability of freight train with no brakes.

Lately things have been a bit quiet here. I haven’t posted much on my blog. I don’t speak at too many conferences (though I will be at devconnections next week and probably in Spring – it’s actually a very cool conference, so I do encourage you to consider it if you’re looking for one to attend). I’m not writing much.


Well, I know this may sound odd coming from someone who obviously (if you look around this site) has very diverse interests. But the truth is that despite the time spent writing, speaking, developing other sites (like, I’ve always been and continue to be primarily a coder.

(more…) – A Google custom search for .NET developers

Tuesday, October 24th, 2006

So this morning I noticed Google launched a new custom search tool – where you can basically customize the Google search engine to search across a set of sites and perform other customizations. Basically a domain specific search.

Is I mentioned in my last post, I consider discoverability one of the greatest challenges facing developers today (it’s certainly the single greatest challenge I face in my daily work). Somewhere out there are answers to almost every technical problem – but how to find it?

Using Google custom search to create a .NET domain specific search engine was a no-brainer. A quick visit to GoDaddy and who would have believed it: was available!

So here it is – a Google powered .NET domain specific search. I’m still early in the process of adding sites. Some of the choices are obvious (MSDN, duh!). Other sites are those that I’ve had the most luck with finding answers to problems I found challenging.

I’m particularly interested in finding more “experts” sites – those that help answer really tough problems, or those that have advanced content – but that are often lost in the noise. These will get the “by_experts” tag that allow them to really stand out.

So, if you have favorite sites that you think just HAVE to be included in the list, please let me know (by Email or comments). I’m not trying to just build a list of all .NET sites – quite the opposite. There are plenty of aggregators (not to mention general Google search) that are great at searching everything. What I need (and am trying to implement) is a tool I can use for an initial search that has a higher probability of finding a good solution to problems – especially on more advanced topics. Then, if it fails, I’ll go to the broader web search.

Plus, I’ll be adding content to the site on the topic of discoverability in general. Keeping up with rapidly changing technology is no easy thing, and hopefully I can make a contribution to that effort as well.

The MSDN Wiki Project

Saturday, September 9th, 2006

I noticed earlier today that Rob Caron at Microsoft was glad I posted my first entry to the MSDN Wiki. While I really don’t consider my posting to be any sort of a milestone, it did remind me that the Wiki project is no longer under NDA so I can actually comment on it.

So here goes.

As someone who has been doing Windows software development since version 1.0, I long considered MSDN the single most important product Microsoft ever shipped – you had to have suffered through the painful lack of documentation earlier on to really appreciate what a revolution it was. The complexity of Windows programming is ever increasing, and MSDN remains the foundation that every developer relies on. While it’s true that for most of us the front-end for searching MSDN is now Google, the content remains the gold standard.

But as good as MSDN is, it’s not good enough. There are far too many holes (and probably always will be – I doubt any doc team could keep up). Even now, it’s extremely common for me to have to search the web for solutions to problems – answers that should be in MSDN but are not.

None of the search engines are good enough for what is needed – a cross linking of information (samples, best practices, caveats and bug reports) that is relevant to each MSDN entry. This problem – discoverability of knowledge that already exists – is the biggest problem faced by any software developer today.

I’ve known about the MSDN Wiki project for a while, but have been too busy with other things to pay close attention. That said, I believe that the MSDN Wiki project is the single most important project going on at Microsoft in terms of software development.

My plan is to add content to it any time I run into something that I get stuck on and have to research – something that should have been in the docs in the first place. I invite and encourage everyone to join in.

I also challenge Microsoft to encourage every one of their software developers to contribute to those areas where they were involved in the development.

The MSDN Wiki project has enormous potential, and I am very excited to see it becoming a reality.

Check it out:

Real Geeks Use Tools

Friday, July 21st, 2006

So today I saw a funny series of Blog posts starting with Robert Scoble’s defense of his “Geekhood” after a post by someone named Cody who hates fake computer geeks.

What’s interesting about these posts are the examples that both use to define geekiness. Cody complains that Scoble doesn’t host his own Blog software. Scoble defends his geek credentials by mentioning past experience installing NT 3.5. Either way, those definitions don’t reflect the reality of the information age.

To put this in context, let’s think back 15 years or so to the Visual Basic story. Here was a tool that provided a high level of abstraction over Windows. Who were the geeks? The C++ programmers who blew off VB as a “toy language” or “glue language”, or the millions who adopted VB either as their first language or migrating from another language?

The answer is obvious – both were. The only difference was that the VB geeks were much more productive (for a wide class of applications).

The world has changed of course, and neither VB .NET nor C# provide the kind of abstraction levels that are needed going forward. We don’t have a tool that corresponds to the .NET framework the way VB related to the Windows API. Or put another way – VB was incredibly productive because it provided a level of abstraction to the underlying API for which C/C++ was the “first class” language. Today, VB .NET and C# are the “first class” languages for .NET – but we don’t yet have that new paradigm, that new level of abstraction, that will bring us to the next level (of geekiness, as it were).

Or do we?

At least in one area, I’m beginning to think that we do.

When I look at ASP .NET, I see lots of great components and features for building great web applications. At the same time, the prospect of building a site using it is – well, it’s about as exciting as Hello World was in C back in the 90’s. I’m working on a project now (not ready to talk about yet), that is web based, and building it from scratch wasn’t even a consideration.

For web applications, tools like WordPress and CMS systems like Plone, Drupel and DotNetNuke are compelling platforms on which to base new applications. Their open source nature and flexible architectures assures extensibility in much the way that VB’s support for custom controls allowed the language to do things that it’s developers never imagined.

This, by the way, should be something Microsoft pays close attention to – the vast majority of CMS systems today are LAMP systems – and this is what might cost them the web platform war (not the quality of the platform itself).

Anyway, I digress. Cody, Robert – you’re both geeks in my book.

And for the record, this particular Blog is on WordPress, that is in fact hosted on my own server – not because there is any geek value in doing so, but because my incremental cost to do so is zero (which is, coincidently, the cost of Robert’s hosting as well).

The “Revolt” of the VB MVP’s – An alternate recommendation

Tuesday, March 8th, 2005

A group of VB MVPs recently signed a petition regarding the future of VB6 . I thought I’d take a minute and address some of their issues. I myself am a VB MVP, and have chosen not to sign at this time because I disagree with the recommendations listed in the petition, but not the objectives.

First, consider the objectives of the petition:

  1. Preservation of assets
  2. Continued support for the Visual Basic language
  3. Ease of migration of unmanaged VB/VBA code to VB.NET

If you have a business that has invested years of development effort in VB6 and VBA code, should you port that code to .NET? We�re talking existing working code here – not new projects. By any sane economic rational, the answer is no. In most cases porting is stupid and a complete waste of money.

The rational way to migrate to .NET is incrementally – using it for new development and porting selected components that can truly benefit from the .NET framework, relying on interop to allow existing code to work with .NET code.

The problem, if not tragedy, is that many developers are porting code to .NET purely out of fear – fear that they will no longer be able to receive support for VB6, fear that existing VB6 projects may not run on future operating systems, fear that they will not be able to obtain VB6 licenses.

Microsoft, perhaps in its desire to promote .NET, has not done enough to assuage these fears. Either they value .NET migration more than the best interests of their customers (which would be shameful), or they are just not able to get the message across. Porting is stupid (for proof  – ask what percentage of the MS Office code base has been ported to .NET).

The classicVB petition recommends integrating some future VB6 into the Visual Studio IDE. I think this approach would be mistaken and a waste of resources.

I would like to offer the following recommendations as an alternative:

  1. A longer term commitment to providing support for VB6 and VBA
  2. Guaranteed support for VB6/VBA under future OS’s for an extended period (definitely including LongHorn and at least one more beyond).
  3. A commitment that once a decision is made to stop support on VB6/VBA, that the entire VB6/VBA code base will be placed into the public domain as an open source project, or perhaps a foundation similar to Mozilla, to assure that interested parties can continue to support and perhaps fork the project in the future.

I believe these alternatives would provide sufficient peace of mind for most VB6 developers to base their migration plans on sound economic factors relating to their individual situation – and not on fear, uncertainty and doubt.

Scobleizer (who blogged the petition under the “revolt” moniker, even though it isn’t)