To Whom It May Concern,

Recently, because of various firewalls, proxies, scanners and content filters I find my Internet usage habits negatively changing.  Your objective of limiting my Internet usage has been achieved although it does not align with my objectives and I question whether or not it aligns with the long term strategic objectives of the organization.

As an aside to my understood delivery related job functions my position requires that I am plugged in to the Internet so that I can find answers to current, relevant questions as well as having a constant stream of data that helps me formulate my thoughts - about what needs to be understood, as well as fueling insight and creativity which - although your organization may not realize immediate benefits - I expect something useful will be reaped in due course.

At any point in time I have at least three development environments open, Word, Outlook, Media Player, some explorers and at least ten browser sessions open.  I flip through all of these constantly without breaking my stride... a pause while I let a technical problem that I am encountering sink in is a chance to switch to another window and do something else.  Google is my guide to the world and my profession and I constantly monitor about 50 rss feeds - admittedly one or two of those may not be considered work related, such as The Dilbert Blog or Boing Boing and others may be borderline relevant to my job, such as The Register or SlashDot.  The rest of them I consider highly relevant for the functions that your organization expects me to perform on a daily basis.

Of course I don't expect you to understand any of this as you sit there in your office counting beans while you wait for your emails to print out so that you can read them.  You are interested in the bottom-line cost of Internet availability and you are not able to picture how the Internet is constantly changing the world - unfortunately your 'visionary' board members have the same myopic view.

You may think that I am just some geek whose needs are irrelevant, but geeks are at the forefront of technology adoption for the next generation - who at some point you want to have as customers as you sit in retirement waiting for your dividend cheques.  About ten years ago I was considered a geek because I used an Apple Newton - now you probably have an I-Mate of your own and are trying to figure out how to use the technology to push more products and services to your customers. SMS (Text Messaging), which is considered a vital communication mechanism for any business, was not adopted because of some boardroom directive or even a Gartner analysis report - it was driven by millions of youngsters flirting with each other at noisy raves, where voice communication simply did not work.  Those youngsters are now your customers - which is why they demand that services are delivered by text message.  If you don't believe me, step out of your office, find someone young - and challenge them to a race to see who can type out a message fastest on their mobile - you will lose.

Other technology is being adopted by the next wave of youngsters where instant communication and access to vast sources and types of media is considered normal.  For them it is more normal too scan the Boing-Boing feed than to watch prime-time news.  They want things that interest them streamed directly into little white headphones that they are always plugged into.  They create blogs and wikis and use them as a source for their buying decisions.

They are becoming your customers and, your actions clearly indicate that you will only understand them too late.

I know you think that I should not be using the Internet for non 'business related reasons' and that Internet access decreases productivity.  I beg to differ and think that productivity is the responsibility of line managers and not some piece of software that sits between me and the rest of the world.  If I may not access the Internet at work for fear of being dragged in front of a disciplinary hearing, may I bill you for my work related Internet usage at home?  How much can I charge for listening to a relevant thirty minute podcast at home?  Will you refund me for downloading a 200MB software update at home because I would never be able to get it downloaded at work?

I am not requesting that you investigate my Internet usage in order to determine if I am worthy of more Internet access.  I consider such investigation an invasion of privacy and where I go on the Internet is not something for public consumption.  The recent exposure of the AOL search logs is a clear indication of how such data can be (mis)interpreted.

The irony is that this is being addressed to you via a blog, and you are so disconnected that you wont even find it.  If someone does forward you this post, bear in mind that I have left out the links on purpose so that you can use that precious bandwidth to go and figure it out for yourself.  You can start at Google - the only link you need to get started.

If you are considering a career as an IT Architect you need to pause for a moment and wonder if you want to label yourself as an 'Architect'.  While there is a general trend at the moment to clarify the term more carefully and formally, most of the people you run into will have there own preconception of what an architect is.  Lots of people run around IT giving themselves the architect title and, whether doing architecture or not, have given all aspiring architects a bad name.

So when positioning yourself as an architect, consider that the following types of architects have already set the perceptions of what an architect is.

The PowerPoint Architect

By far the most common type of architect is The PowerPoint Architect, these kinds of architects produce the best looking architectures on paper... I mean PowerPoint.  Great colours, no crossing lines and reasonably straightforward to implement... apparently.  The problem with PowerPoint architects is that they are so far removed from real implementation that architectures that they propose simply won't work.  The PowerPoint Architect is generally a consultant who, just before implementation is about to start, picks up their slides and moves to the next project - leaving everyone else to implement their pretty diagrams.  The PowerPoint Architect believes that software development is similar to doing animations in PowerPoint and infrastructure is about how to get your notebook connected to a data projector.

How to spot The PowerPoint Architect

The PowerPoint Architect gives him/herself away by scheduling presentations in meeting rooms and having so many slides that there is no time to go into the detail.  If the meeting has more business and project representatives than technical staff, it was probably organized by The PowerPoint Architect so that technical questions seem out of place and should be 'taken off-line'.  The PowerPoint Architect has also been known to use Visio.

The Matrix Architect

Named after 'The Architect' in the Matrix movie series, The Matrix Architect has been there so long that he/she doesn't know any other way.  Matrix Architects leaves no room for improvement, discussion or negotiation as the architecture was written by them eons ago and has worked fine, thank you very much.  Much like the scene in The Matrix Reloaded, The Matrix Architect has a personalised, well defended office and if you manage to get in, you simply have to leave by one of two doors - without getting a chance to explain yourself.

How to spot The Matrix Architect

The Matrix Architect normally has their own office and is well settled.  Technical books on CORBA, Betamax and other has-been technologies are proudly displayed on the shelves.  The Matrix Architect can also be spotted by their uncanny ability to work their way into meetings and throw curveball comments like "That's just like the SGML interface that we used on DECT and in my day..."

The Embedded Architect

The Embedded Architect creates architectures that are so huge and complex that removing them is similar to taking out your own liver.  Most of the time they do this for career stability or, if they come from an external organization are there to milk as much future profit out of projects as possible.

How to spot The Embedded Architect

The Embedded Architect is very difficult so spot during the embryonic stage when they are infecting the existing architecture and often once spotted it is too late.  The Embedded Architect often has a team of disciples that as a group understand the entire architecture, but individually know very little.  A requirement that new team members go on an induction course on the architecture is a sign that there may be an Embedded Architect somewhere within the organization.

The Hardware Vendor Architect

The Hardware Vendor Architect is actually a salesman with a reworked title.  The Hardware Architect's role is to point out the flaws in everyone else's architecture so that they can justify why the extra hardware expense is not their fault.  At Hardware Architect School, The Hardware Architect is trained in creating proprietary hardware platforms that create vendor lock-in.

How to spot The Hardware Vendor Architect

The Hardware Vendor Architect normally has a car full of pens, mouse mats and notepads emblazoned with some well-known brand which they use to assimilate the weak.  They also have huge expense accounts where they can take the entire data centre to lunch occasionally.  They are often heard saying things like 'You need a 24x7 99.999999% disaster recovery site'

The Auditor Architect

We are not sure of the origins of The Auditor Architect, because they are supposed to be auditing things, not creating architectures.  The Auditor Architect will always propose an architecture that uses spreadsheets for every possible system interface that requires each user to be a CA so that they can review the transactions before they are submitted (not to be confused with The Auditor Project Manager who uses spreadsheets for all documentation).  Since most organizations don't have that many CA's, The Auditor Architect represents a firm that can provide as many CA's as may be necessary.

How to spot The Auditor Architect

The Auditor Architect always wears a black suit, white shirt and an expensive tie in the latest fashionable colour and style.  The Auditor Architect will often go to great lengths to express that they are unbiased and just want to make sure that things are done correctly.  Most emails received from The Auditor Architect have spreadsheet attachments.

The Gartner Architect

The Gartner Architect has knows all the buzzwords and has all the supporting documentation.  They never actually put together a workable architecture but run ongoing workshops on the likelihood of the architecture looking a particular way at some point in the next six months to five years.  As soon as an architecture is established, The Gartner Architect uncovers some 'new research' that requires a suspension of the project while the architecture is re-evaluated.  Incidentally, sometimes The Gartner Architect is known as The Meta Architect.

How to spot The Gartner Architect

The Gartner Architect always does presentations with references to some research noted on every slide and the true test of The Gartner Architect is asking for the document that is being referred to - it won't materialize.  The Gartner Architect is often accompanied by a harem of PowerPoint Architects eager to get their hands on the material.  The Gartner Architect is often entertained by The Hardware Architect, provided that they represent products that are in 'The Magic Quadrant'.

The ERP Vendor Architect

True Architects for ERP systems do exist - but they hang out somewhere else, like in Germany, and not on your particular project.  There is no need for an architect on a system that if changed, self destructs within thirty seconds.  The ERP Vendor Architect is actually an implementation project assistant that is billed at a high rate.

How to spot The ERP Vendor Architect

The ERP Vendor Architect almost always has a branded leather folder of some really fun training conference that they went to in some exotic location with thousands of other ERP Vendor Architects.  A dead giveaway is if The ERP Vendor Architect and The Hardware Architect are exchanging corporate gift goodies - a sure sign that they are colluding do blame legacy systems for the poor performance.

The UML Architect

The UML Architect is not interested in any architecture that cannot be depicted using UML diagrams and spend a considerable amount of effort making sure that this happens.  The UML Architect lives in an object bubble and has no consideration that their intended audience never learned SmallTalk.

How to spot The UML Architect

The UML Architect is easy to spot from the documents that they produce.  All documents have a lot of stick-men, hang-men and and cartoon characters pointing at bubbles.  The UML Architect will always be able to describe the architecture by <<stereotyping>> it as something that you will understand.

The Beta Architect

The Beta Architect insists that the current version of whatever software you are using is going to be ridiculously out of date by the time the system goes live.  For that reason it is important that the development be done with the beta framework, operating system or development environment and not to worry, the product will be probably released before the system needs to go into production.

How to spot The Beta Architect

The Beta Architect normally wears a golf short with a large software vendors logo embroidered on the front and walks around with a conference bag suitably branded.  The Beta Architect normally comes from an external organization that has a partnership with a large vendor indicated by some metal, but always gold or platinum - bronze and silver partners are not worthy.

Simon Munro

A comment by a colleague on my last post on 'relations' - chuckling at the question "What on earth is a 'parent-child relation'?" prompted a post on one of my other naming pet hates - namely the mis-used concept of Parent-Child to denote hierarchy.

Over ten years ago I wrote a tree handling routine that needed to delete sub-nodes of a particular node and the method started off being called Node.DestroyChildNodes() which, at the time, I thought would be pretty cool to rename to Node.KillChildren() to reflect the concept of eliminating the children.  Over the years I became more pedantic about naming, primarily inspired by my mentor who was and is extremely particular about naming.  This person had an interesting academic background and his degrees in Theology, Psychology and Electrical Engineering made him interesting to deal with.  He was working as an architect on a project and I overheard a discussion he was having with a developer that went something like this...

Architect - "Did this account fall pregnant?"

Developer - "Er... no" (I don't understand the question look on his face)

Architect - "Did this account go into labour?"

Developer - "Er... " <long pause> "No"

Architect - "Was this account inseminated by another account"

Developer - "I don't think so" (some language barrier here)

Architect - "Did this account go to hospital and, after a long labour, give birth to this (other) account?"

Developer - "No.  What on earth are you talking about?"

Architect - "If this account didn't physically give birth, or contribute is sperm to that account, WHY THE <expletive removed> DO YOU CALL IT THE 'PARENT' ACCOUNT?"

Since then, the developer made sure that he only used parent and child when referring to real people, as parents, and their children.

So if it is not correct to use parent-child except in cases where there are actual people involved who have a legal and physical association, what should be used to denote hierarchies?  The simplest and most generic would be to use subordinate which the dictionary defines as 'One who stands in order or rank below another'.  The shorthand of subordinate is sub and is something we use often in English as in subtitle, sub-paragraph and so on.  If sub is the 'child', what is the 'parent'?  From a rank perspective, a choice could be 'principal' but more generically I prefer to use 'superordinate', which the dictionary defines as 'Of higher rank, status, or value'. Although superordinate may be a little bit obscure it is used in English (superscript) and has a convenient shorthand - namely sup (which if misinterpreted to be 'superior' is not to bad.

Using this naming, a table that stores a hierarchical structure may have the fields 'Id', 'Name' and 'SupId' (instead of ParentId).  My tree routines would also read better - instead of DestroyChildNodes() I would have DestroySubNodes(), which reads well; I would also have a property called SupNode, that would return the superordinate node.

Using sub and sup is the easy, generic solution, but if you think about it more there are other names that can be used in different circumstances such as...

Can you think of any more to add to this list?

It is important in both design and implementation that we name things well and that they make sense.  All too often business hands something over to IT and by the time it comes back it has been abstracted, generalized renamed and confused. 

Imagine the scenario when dealing with a user talking about a medical aid system where a person has dependants...

Developer : "When you click here the child nodes are removed"

User:  "Why not the spouse node as well?"

Developer: "There is no 'spouse' node"

User: "There is, two children and one spouse"

Simon Munro 

In interviews I need to know how well the candidate knows databases and start off by going back to basics.  After establishing that the candidate knows that the 'R' in RDBMS stands for 'Relational', I follow it up by asking for a definition of 'Relation'.  I will accept answers along the lines of "... a set of tuples" or at a push, "... a table" (A table is a lay term for a relation, particularly when used in the context of SQL databases).  However, most times I receive an answer that starts something like "A relation is when you have another table with a foreign key...", at which point I ask "Are you talking about a relation or a relationship?", which is followed by stunned looks or muttered agreement.  I have interviewed hundreds of people over the years and only one or two haven't used a 'foreign key' based answer.

For some reason the concept of foreign keys in SQL databases have been confused with the relation.  I think it comes from the colloquial use of statements such as "Relate employee and employer on EmpNo" - the 'relate' really refers to a relationship but since the speaker may remember a single semester course in relational theory (apparently making him an expert) recalls that it sounds a lot like the 'relational' in relational database and thus the confusion starts.  Maybe it was the result of Bill Clinton's infamous statements where, I can imagine, during a brief period when mathematics was more practical than abstract, a group of exhausted mathematicians decreed "After much experimentation we can saefly say that 'sexual relations' are not part of the realtional model and probably refer more to the physical relationship between two somewhat consenting adults"

I'm no mathematician sitting in some old ivy covered building at an academic institution - I deliver systems based on SQL databases and (ADO) DataSets every day and am a big fan of the technologies that I use.  However, having had a background in more formal methodologies and working with great, intelligent people over the years - I have tried to understand the theoretical basis for what I use and a smattering of relational theory fits into that understanding - I think that some knowledge of relational theory is important to build systems on top of SQL Server.

With that as a background, hopefully you will understand why, when using ADO DataSets and Visual Studio, I cringe every time that I have to refer to the ADO version of 'relation'.  Even typing that last sentence makes my hair stand up. 

DataSets don't seem to officially claim to have anything to do with relational theory and with that as a disclaimer they don't do anything wrong.  Just as SQL Server or Oracle don't make any claims about fully supporting the relational model for fear of upset computer scientists and mathematicians spray-painting integrals all over the Microsoft campus.  However, since DataSets talk to SQL Databases which in turn are (sort of) based on the relational model - the distance between DataSets and relational theory is not that far - the inference that the DataSet relation has something to do with the relational model's relation does exist.   The only 'official' association that I have found is in MSDN (Datasets in Visual Studio Overview) which states "The structure of a DataSet is similar to that of a relational database; it exposes a hierarchical object model of tables, rows, columns, constraints, and relationships." - Which should be enough to upset a few theorists.

The ADO Relation is simply incorrectly named and propagates the confusion that people have about thinking about relations and relationship interchangeably.  The relation is a fundamental construct in relational theory and has formal relational algebra, relational calculus and other mathematics behind it.  The ADO relation is simply a badly named foreign key.  It is a fundamental error and is like calling the steering wheel of a car a chassis.

Not only does Microsoft abuse the term, they also use it inconsistently.  Visual Studio developers that have used the DataSet designer are used to the term 'Relation' as it is in the IDE (right click | Add | Relation) and I have myself said to developers things like "Create a relation (cringe) between those two DataTables".  However, the actual class that is being created is a DataRelation class.  Thankfully, the class is not called a relation and DataRelation is sufficiently devoid of significant meaning (like calling the aforementioned steering wheel a DirectionChassis) that one can get away with it.  But why then does Visual Studio call it a relation, and why couldn't they just have used 'relationship' in Visual Studio? 

Unfortunately it doesn't stop at Visual Studio.  The DataSet class has a property DataSet.Relations which returns, not a collection of DataTables as someone with some understanding of the relational model would expect, but rather a collection of DataRelations (er... foreign keys?).  DataSet.Relations.Add() does not add a new table, it adds a new DataRelation(ship).

To add to the confusion, the msdata schema definition (xmlns:msdata) uses the term 'Relationship' (msdata:Relationship annotation) or the xs:keyref annotation for foreign keys.  Generating DataSet Relations from XML Schema in MSDN recommends this after creating more confusion by stating "In a DataSet, you form an association between two or more columns by creating a parent-child relation." (aaargh! cringe! What on earth is a 'parent-child relation'?)

I think that Microsoft's abuse of the term 'relation' is shocking and breaks thirty-odd years of sound theory as well as breaking a few object orientation rules along the way by not naming things clearly and consistently.  I don't think that it is going to be an easy problem to fix, but the easiest change would be to rename 'Relation' to 'Relationship' in Visual Studio - most developers wouldn't even notice.  The DataRelation class is more core to the framework but is thankfully so badly named that it has no meaning anyway so it could almost be left alone.  I don't know how easy it will be to change the Relations property on the DataSet which is horribly orphaned and should have at least be named DataRelations from the beginning.

The number of people reading this post can never be as much as the number of developers going - Right click | Add | Relation - perpetuating the confusion.  I don't propose a Relational Vigilante Group that spray paints notations of set operators across the Microsoft campus and I imagine (sadly) that the generation that developed and believed in relational theory - the basis for nearly all our business systems - are literally a dying breed.  The father of relational theory EF Codd died in 2003 at the age of 79 and CJ Date, a driver of the relational model, is probably feeling a bit old and won't be able to compete with millions of young, energetic Visual Studio developers churning out thousands of blog pages every day.

Caveat Lector is is a Latin phrase meaning "Let the reader beware".  All that I ask is that as a .NET developer that you be aware of the terms 'Relation', 'Relationship' and their respective meanings in relational theory, ADO, visual studio and I suppose, the social sciences.

Simon Munro

What is IT Architecture and what do Architects do?

Seems like an obvious question which should have an obvious answer, yet it has sparked debate in recent months amongst some very clever people.  The recent certifications by Microsoft and the Open Group have fanned the flames of questioning and discussion.

I would like to think the need to understand architecture and the related role has to do with overall maturity of IT – where business is demanding more credible and qualified senior staff on their projects and the technologists are trying to be more specific, explicit and disciplined about their trade.  While I believe that there is an element of this, I suspect that the main driver of the current wave of interest is personal career aspirations.  Allow me to explain.

Depending on what date you believe the dot-bomb bubble burst, we are about five years on from the end of the dot-com era.  In that time, most of the developers who climbed on the bandwagon have either thankfully gone to another industry or have managed to hang on and become more experienced and senior technical staff.  Corporate IT is also more stable and has trashed many of the outsourcing projects - leaving a technically strong pool of resources within their own organization.

Someone who has been in development for five years or more begins to pay attention to the next rung of the corporate ladder and when looking at the people who are in a higher salary bracket – their eyes quickly fall on ‘The Architect’.  Not many developers want to become IT managers, dealing with budgets and other painful stuff – nor do they want to become Business Analysts producing lots of documentation that is never read. In their eyes ‘The Architects’ seem to have a cool job – good money and the freedom to play around with technology as much (or little) as they feel like.

I can almost picture the discussion:

<fade in to glass-windowed office with motivational posters on the wall of rowing teams>

[Developer]: I want to discuss my career path here at <deleted>

[Manager]: Great idea, we have lots of opportunities and value your contribution to the organization.  We have good career paths as a project manager or a business analyst.

[Developer]: I want to be ‘An Architect’

<pause>

[Manager]: umm… Great idea!  But you don’t fit the profile.

[Developer]: Why not?

[Manager]:  You need more than five years of experience

[Developer]: I've been *here* for longer than that.

[Manager]: Oh...

<pause>

[Manager]: and you need leadership skills!

[Developer]: I’ve been team leader on my team for three years!

[Manager]: Yes, but you need other stuff

[Developer]: Like what?

[Manager]: Stuff like…. stuff like…. umm..  politics.  Yes! You need to be able to do politics! And I’m sure there are lots of framework thingies too! And you need to know what ‘The Big Picture’ is!

[Developer]: You’re blowing smoke up my butt aren’t you?

[Manager]: Not at all!  I’ll get the details from HR

<begins typing>

Dear HR,

Please forward me the latest job spec for ‘Architect’...

While I don’t believe that the role of architect has been entirely defined by someone in HR I think that the bottom up demand for clarity of architecture by development resources has been a major driver in the current need to clarify the architecture domain.  Some existing architects have assigned the title to themselves and are now being pressed to be more precise about what it is that they do – primarily by the developers on their own teams.

I think it is great that architects are being put under pressure and those that have the skills and experience will flourish while the rest will fade away.  It means that not only will we have better architects and hopefully better architectures in the medium term, but also will have the opportunity to lay the paving stones for the next batch of architects moving up in the ranks.

I ask only one thing – please debate this amongst your peers to come up with your definitions; don’t leave it up to HR.

Simon Munro

Some links to other people describing what an architect does

Bobby Woolf (IBM)

Miha (Microsoft Certified Architect)

Ruth Malan (Bredemeyer Consulting)

Marianne Kolbasuk McGee (Dr Dobbs)

Allan Hoffman (Monster Tech Jobs Expert)

Over the last few months I have occasionally wandered over to Microsoft Learning to have a look at the 'new' certifications.  How can certification that has been available for months on a development platform (.NET 2) that has also been out months be considered new?  Apart from the lack of study kits and other logistical issues, it seems that most developers and employers don’t really care about the Microsoft certification.

It seems that there is a negative attitude towards certification that has been propagated by the concept of a 'Paper MCSE' where a ranter will say something like "An MSCE used to be worth something, now training institutions are churning out paper MSCE's" – implying that there are a whole lot of people out there with certification that cannot code.  I have interviewed hundreds of people over the years and always find myself needing good resources on any project that I am on – requiring constant interviewing and screening.  Funny thing is that I have never come across a 'paper <insert certification here>', but I have come across many useless developers.  It may not be statistically meaningful that of the last hundred development candidates that I have mentioned that there was not one that had certification and couldn't develop – but it would raise a statistician’s eyebrow.

Microsoft is apparently trying to revamp the certification by breaking it up into little bits and making it 'easier' to obtain certification aligned with job functions – something like an n-tier approach to certification (you shouldn't need certification to get that analogy).  Maybe they have a long way to go to convince the market that certification is required, but I think they have made a step in the right direction.

I will be the first to acknowledge that (correct) experience is the ultimate prerequisite for a developer and when interviewing, it is something that I will drill in to.  However, even 'experienced' developers can have huge gaps in their knowledge – depending on the projects that they have been on, a developer with a claimed two years' experience may in fact have one month of experience repeated twenty four times.

<rant>Don't get me started on bodyshops - that pound you with CV's of unqualified, uncertified contractors that they expect you to filter out.  Why, for the premium that they charge, don't they get their contractors certified - apparently they are so good that it would be a breeze.</rant>

If you think that certification is a waste of time, take this little challenge.  Have a look at the preparation guides for two exams for a Microsoft Certified Technology Specialist (Web Applications) (the lowest level of certification), namely the Application Development Foundation exam and the Web-Based Client Development exam.  Scroll down and see how much you know on each topic.

Done? Good.

Now if you are a team leader, architect, project manager or other senior role ask yourself the following questions:

• Would it be better for my project if *all* the developers on my team even vaguely knew all of those topics?
• How many of the developers on my team could answer questions on those topics accurately?

If you are a developer as yourself a more simple question. 

• If I was being interviewed would I squirm like a worm on a hook if the interviewer asked detailed questions on all that stuff?

If you had positive 'no worries mate' answers to the above questions, then you are on a unique team and will be the envy of many.  If you had negative answers, then maybe you should review your position on certification and think about using it as a standard – either to find developers or to pitch yourself as a developer.

Personally, I can't think of any developer that I have interviewed, including 'senior' developers, who would not be taken out by most of the topics on those preparation guides.  Are the preparation guides biased by Microsoft and not representative of what a developer truly does?  I think that a 'senior' developer should at least know about every single one of the topics in the 'Technology Specialist' series – what with it being the lowest level.  Unfortunately few ‘senior’ developers do.

One of the ideas of certification is not just to provide the individual with knowledge, but to provide a standard so that everyone is on the same page.  In a recent quality review, when challenged on simple things like naming, error handling and so on – a developer commented something like "It (quality review of private methods) is not necessary because we are all good developers and write good code".  "By whose standards?" I asked "Are you certified?" (shake of head) and pointing to the developer next to him "Are you?" – another shake of the head; and so on around the room.  I have my own personal opinions on how those developers would handle me grilling them on those preparation guides and the expectations are not very high.  Not that they are bad or even mediocre developers, but I do need to spend a lot of time introducing them to the basics – to overcome the "one-month-of-experience-for-twelve-months" problem that I have.

If you are an uncertified developer, why are you not certified?  Is it because you are waiting for your employer to send you on training and give you permission to go to the toilet?  Are you scared that you won't pass?  Well then study and make sure you pass!  Are you a better developer than everyone else and above certification?  Well then step into the ring and prove it to us!  Are you worried that you will be lost amongst all the 'Paper MSCE's'?  Get your head out of the sand, there aren't any!

Regardless of the technical value of certification, it is only meaningful if people who are qualified to be certified, are certified.  There is no point in putting out a job advert that requires certification if nobody is certified – no applicants will come through.  The converse is true – why get certified if no employers even look at it?  As many people need to be certified as possible and in the .NET space I think that the Microsoft certification is good to get. 

If, after reading this, you think that such certification is worthwhile then go out and get it (as a developer) and start demanding it (as a leader/manager) – only by changing the dynamics of supply and demand will anything of value evolve.

Simon Munro

www.delphi.co.za

When writing complex sproc’s in T-SQL you can sometimes run into the problem that IDEs and other tools, while trying to parse the query, are unable to realise that the query actually works.  This is because they try and interpret the query to get the metadata (the format of the result, rather than the result itself), rather than execute it – not such a bad thing since you don’t want an IDE to execute a sproc willy-nilly, which could result in all sorts of side effects.

The main place where developers will encounter this is when trying to configure a TableAdapter (or something) that uses temp tables.

Consider the following sproc:

CREATE PROCEDURE [dbo].[DoSomething]

AS

CREATE TABLE #MyTable (Id int, Name nvarchar(50))

INSERT INTO #MyTable

VALUES(1,'Name1')

SELECT * FROM #MyTable

Executing this procedure via SQL renders the expected result as follows:

(1 row(s) affected)

Id          Name

----------- --------------------------------------------------

1           Name1

(1 row(s) affected)

However if you try and create a TableAdapter in Visual Studio using the same sproc, you get an error that looks something like this:

The short solution is not to use temp tables, but rather table variables – which for lots of other reasons is arguably better.  The altered sproc would then look like this:

ALTER PROCEDURE [dbo].[DoSomething]

AS

DECLARE @MyTable table (Id int, Name nvarchar(50))

INSERT INTO @MyTable

VALUES(1,'Name1')

SELECT * FROM @MyTable

That is fine, but occasionally you may need to use temp tables and developers land up creating ‘permanent’ temp tables or some other approach.  The question remains, how can we force Visual Studio to ignore the metadata and actually execute the sproc?  In some cases temp tables may be unavoidable – particularly if you are using someone else’s sproc.  The quick solution is to use the SET FMTONLY statement which when turned off would seem to return data as well as metadata to the client.  The SQL Books say the SET FMTONLY ‘Returns only metadata to the client.’  I am making the assumption therefore that setting it to ‘OFF’ returns something else as well – I suspect it is the data.

So, to use a sproc that uses temp tables in Visual Studio, the sproc could be changed to:

ALTER PROCEDURE [dbo].[DoSomething]

AS

SET FMTONLY OFF

CREATE TABLE #MyTable (Id int, Name nvarchar(50))

INSERT INTO #MyTable

VALUES(1,'Name1')

SELECT * FROM #MyTable

… making Visual studio happy.

Interestingly, SSIS (SQL Server Integration Services) has an additional quirk.  Firstly, if you use a temp table without turning FMTONLY to OFF, and write a source query of ‘EXEC DoSomething’ you receive an error message ‘This SQL statement is not a query’ – SSIS doesn’t even parse your carefully constructed SQL.  You know that

1. It works in the query analyser
2. It is a query
3. You are more intelligent than your PC, so if you know it is a query then it must be a query.

The best way to convince SSIS that the query is actually a query is to insert the SET FMTONLY OFF line into the sproc (without changing the source query that SSIS uses – see it was a query!).  You may think that the solution is the same as with Visual Studio (use table variables), but SSIS was written by some other development team and has a different attitude and personality.

If you execute a sproc with table variables or temp tables with FMTONLY OFF you get something like the following:

If you look carefully, the ‘Executing’ successful (is a valid query) but the ‘Pre-Execute’ fails.  I tried to turn off the pre-execute as an option in the designer with no success.  The quick answer is to add SET NOCOUNT ON to the sproc, which for some reason lets the pre-execute run successfully.  I am not sure why, the SQL Books say that NOCOUNT ‘Stops the message that shows the number of rows affected by a Transact-SQL statement from being returned as part of the results’, which doesn’t seem relevant to pre-execute – but it does work.  The query would then be changed to:

ALTER PROCEDURE [dbo].[DoSomething]

AS

SET FMTONLY OFF

SET NOCOUNT ON

CREATE TABLE #MyTable (Id int, Name nvarchar(50))

INSERT INTO #MyTable

VALUES(1,'Name1')

SELECT * FROM #MyTable

Or, if using table variables:

CREATE PROCEDURE [dbo].[DoSomething1]

AS

SET NOCOUNT ON

DECLARE @MyTable table (Id int, Name nvarchar(50))

INSERT INTO @MyTable

VALUES(1,'Name1')

SELECT * FROM @MyTable

In summary:

1. Rather use table variables than temp tables
2. When using temp tables use SET FMTONLY OFF
3. When using SSIS, use SET NOCOUNT ON
4. If SSIS says your query is not a query it may be trying to fool you.

Simon Munro

I have been interviewing for developer positions this year and although I have been accommodating of the ramp-up from .NET 1.1 to .NET 2.0 I feel that now, six months after the release of .NET 2.0 and Visual Studio 2005, that it is time for developers that are presenting themselves to the market to have .NET 2.0 skills.

On our project we were lucky to start development this year and are using full-bore .NET 2.0 and in this green fields project, the use of the new technologies makes a major difference.  It seems that just about every class we use has the ‘Note: This class is new in the .NET Framework version 2.0’ message at the top of the window when looking for help on MSDN.  I think that our project, with it’s recent start date, uses .NET 2.0 more than your average project or development shop that is migrating to the newer framework.  This means that when interviewing I am looking for *some* .NET 2.0 and VS2005 skills so that the learning curve for new developers on the team is not three to four weeks – before even touching the project.

By .NET 2.0 skills, I don’t mean that they have to be experts – with six months of real project experience on .NET 2.0 – but at least need to have ‘played around’ with the new stuff and have an opinion on what the main changes are and how it affects development.  For us, the changes are significant and the mindset of the developer needs to be in tune with those subtle, but far reaching changes.  We use, for example, well-structured strongly typed datasets and although in theory it is pretty straight forward, it makes a big difference to how we code and interface with the database.

Different projects and organizations have their own pace with which they move to the latest version on anything and there are many good, and practical, reasons for not tearing the shrink-wrap off a product and implementing it with wild abandon.  My concern is not with the well-established projects with an architecture which has a sound base in .NET 1.1.  My problem is that individuals are marketing themselves as .NET developers and don’t have a clue as to how things would work differently in .NET 2.0.  Even worse are the body-shops and development shops who are taking these developers from .NET 1.1 projects and pushing them into new projects without the tiniest smidgen of training in the newer technologies – something they should at least attempt for the rates that they bill their resources out at.

So, any developers out there who haven’t gotten around to learning .NET 2.0;  firstly, you are missing out on something that is cool and interesting. Secondly, if you are stuck on a .NET 1.1 project, please try and keep your skills up on .NET 2.0 for when you find yourself looking for another project or employer – at least your skills will be aligned to the market demands.  It is fairly simple to get up to speed – there is free training available from Microsoft for which you don’t even need VS2005 and there are also the express versions of Visual Studio available for free.  You should be able to learn enough in a few days/weekends/late nights.

To put it bluntly, if you are trying to get a job or contract and you don’t have some .NET 2.0 and VS2005 skills it indicates that you are either lazy or have a tenuous grasp of .NET anyway.

Most people reading this post will have some up-to-date skills or else they wouldn’t have found the post but unfortunately Huisgenoot and You magazine (which must be all you are reading if you haven’t heard about .NET 2.0) don’t really cater for technical blogs.

Simon Munro

PS: If you are a .NET developer looking for a contract on a .NET 2.0 project, let me know – I have an opening for you.