Business Programmers and Core Developers

I've been thinking lately about the different types of programmers and different attitudes toward application design and development. An interesting concept occurred to me. In my industry, there seem to be two types of programmers: business programmers and core developers. Why do I make a distinction? I've been analyzing some code and reviewing articles (for example, Scott Mitchell's "More On Why I Don't Use DataSets in My ASP.NET Applications") and it occurred to me that I don't dive into the constructs as much as many people do. I typically take a given tool, a dataset for example, and implement it. If I have issues with performance, I will investigate alternatives and update my knowledge so next time I use a datareader instead (or whatever tool fits the situation).

How is this different from a core developer? I think a core developer will research all the options and dive deep into what fits initially. The good news is the application will run well and correct the first time. The downside is that investigation takes time. I would actually say it takes longer to investigate than it does to actually code. This causes the business to be slow in adoption and slow in momentum behind new projects (which in turn causes poor moral due to additional red tape...but that is another topic).

That being said, I believe that the correct balance lies in the middle. Businesses need to be agile and small applications need to be created quickly. That is the role of the business programmer. However, there is a point in the application design where the architect needs to decide on how much developer time to spend. If too little time is spent, the application becomes a maintenance nightmare with many points of failure. It may work when you roll it out, but will it hold up?

Okay, so I don't have any grand insight as to the answer as this was just a passing thought I wanted to jot down. I guess the real answer might just goes back to the saying, "Everything in moderation."

Visual Studio 2005 Beta 1 to Beta 2 Upgrade

I thought I would document my upgrade issues and post them for anyone they might help. Some noteworthy things. I did a complete reinstall on a system (fresh OS) then installed Office, Visual Studio 2003, and a few other tools. I then copied my VS beta 1 code to the new system and tried did the following:

1. Find and Replace on all files in solution CompileWith to CodeFile


2. Find and Replace on all files in solution - ClassName to Inherits


3. Recopy any .js files as some had "ClassName" text in them.


4. I had used the namespace System.Xml.Query which was removed. Specifically, I had made an XmlCommand to do a transformation. I had to rework it using the System.Xml.Xsl.XslTransformation class. I found the article "Transforming an XML string with an XSLT string" by Robert Levy helpful. I will post my completed method later.


5. System.Configuration.ConfigurationSettings.ConnectionStrings seems to have disappeared. Not only that, but I get a bunch of warnings that I should be using ConfigurationManager instead. Only downside? Where IS the ConfigurationManager (not in System.Configuration!)?


6. I had a case where one of my web services wouldn't compile with the error: Could not create type 'service name'. As it turns out, I had to move the code behind file into a new directory named App_Code. The errors showed one at a time, but I eventually had to move all code behind files to the App_Code directory (and update the asmx files to point to the App_Code directory).


7. I also had to change an attribute of the WebServiceBindings class from ConformanceClaims to ConformsTo and the attribute value to WsiProfiles.BasicProfile1_1.

That's it.

Digital ID World 2005 Part 2

This post is more a note of interest rather than debate. About four years ago I heard the term "Reference Architecture" from a company called NetReference (now a part of Burton Group). During the course of this conference, I have heard that same term used by several vendors but none more than oath. Interestingly enough, Burton Group's product is termed "Burton Group's Reference Architecture" and oath's initiative is called the "OATH's Reference Architecture" version 1. Evidently someone was watching/listening and liked the term.

Digital ID World 2005 Part 1

To preface, these posts will not be in chronological order as my notes are not completely gathered yet. However, I've been listening to several vendor presentations and I'm begining to think that VPNs will add and combine strong authentication mechanisms with mal-ware detection software to protect employee access to network systems. How would this work? Here is my take.

First off, a USB device would have a required token in order to access the device (so if plugged in, no access would occur until the device was unlocked. Once unlocked, the device would scan the system for any mal-ware or other intrusion methods to ensure nothing can be captured. The next step is to contain the VPN software required to access your private network. Once this software was located and the user is authenticated, the device is required to be removed from the system (to prevent users from leaving the device in a single system or random system.

Other additions would be related to work systems that already have the vpn software and scanning software which would speed up the authentication process. That way the typical login time would not be as intense as it would be given a random system that an employee attempts to use. After all, do you know what exists on your neighbors computer?

Digital ID World 2005 Opening

I'm currently waiting for the Digital ID World conference to begin in San Francisco. I've been lucky enough to sit and chat with Jamie Lewis, the CEO of Burton Group. The conference appears to be small enough to keep a close feel with the speakers. I'll continue to do more "Live Blogging" as the day continues and I have more opinions on what is said.