“Both views of the world resonate with me and I can clearly see how they are both right. I have spent sometime recently thinking about this in more depth, and I think I know how to rationalize their views, but I’d like to get your take… Is software development a discipline of engineering or a discipline of arts?” - from Brad Abrams' blog on Tuesday
Software development should be construction work. Technical design should be more like architecture, which contains both art and engineering. The fuzziness is due to the fact that I.T. roles too often overlap, and most people in the industry have done design and construction at once (or still do) under the illusion that a) the roles belong as one, and b) skill at one implies skill at the other. To understand where all this is headed, we can learn from the way builders build buildings, starting with the architect.
Architectural firms provide a few roles that map to I.T. The firm acts as Business Analyst with the client to figure out what to build and for how much, Architect and Technical Designer during the design phase, and then Project Manager to keep the general contractor on track. The physical construction is handled by another company -- the general contractor. The trend in the software industry is towards this separation of roles, but we're in a different state today.
Software construction today is a little like building a medieval cathedral. At least that's the way the smart companies do it, given the mix in the talent pool. I'll explain. Once upon a time you had the unskilled labourers (“grunts”), plus a large number of highly skilled and specialized artisans. The grunts were hired to flatten the ground, put up some basic structure and do the heavy lifting, but knowledgeable, skilled craftsmen -- artists really -- did the bulk of the work (or at least that's how I remember the PBS special).
And each was specialized. One knew how to make perfectly domed or vaulted ceilings, another spent a few years carving wood trim, another would be known for stained glass or gargoyles or whatever. It was these artisans who spent from months to years making the cathedral function in a soaring, spiritual, "holy crap that's beautiful" kinda way. They were the ones who applied both creativity and centuries of accumulated knowledge to their appointed task.
The I.T. talent pool is sharing and accumulating knowledge at a pace on WebTime. Roles are being stratified into ever more concise specialties. Artisans are prevalent, and in demand. Maybe my perception is skewed, but I don't know of anyone who practised design patterns or refactoring ten years ago. Development in those days was like building a clock with a hammer and some nails. Today we've got this awesome pool of educated talent. There might still be a vast force of grunts out there slapping together sandboxes and tie racks, but those aren't the folks I meet at user group meetings, and I bet they don't read Brad's blog either. I really believe we're living in the days of cathedrals. And there's a giant one just over there. . .
The .NET Framework is an abstract, modular, old-school cathedral. And it's a cathedral that acts as a tool to build other cathedrals. All the pieces are there, and even most grunts can shape or colour them for most any application or function. Put the tool in the hands of a competent architectural firm, and you can use those pieces to build your own Library of Congress or Taj Ma Hall of Pancakes (whatever strikes your fancy), faster than you can say “Amish barn-raising.”
Back to Brad's question. Yes, therefore software development is art. Today.
But our newfangled abstract power tools will dilute the value of the software artisan, and not everyone can be the master builder or architectural engineer. Remember when the word “webmaster” carried connotations of arcane knowledge? The same will happen to “software developer.” Let's have some fun with it while it lasts. Be an artisan. That's enough mixed thoughts and metaphors for one blog, until the next shipment.
For anyone considering custom exception handling, there is an important distinction to make: Custom exceptions are one thing, and handling exceptions in a customised way is something else.
The phrase “custom exception” usually refers to an exception class which inherits System.Exception or System.ApplicationException, as demonstrated by the Exception Management Application Block (EMAB). It means writing your own Exception framework, from raising the exception with your own constructor (because any additional information you store must be gathered at the time the Exception occurs), through doing something with it (logging, etc.). The bit in italics will become important later on. Most of the time, these custom classes don't handle casting from the conventional types, meaning for example that you lose the ability to do anything with GetLastError() inside the Application_OnError event for example.
“Handling exceptions in a customised way” normally describes what you can do with the standard Exception classes. ASP.NET has some prety nice features, including standard events, the ability to set default error pages in web.config (like a branded 404 page), or a way to generate a customErrors page (also declared in web.config).
My last MSDN article was entitled “Rich Custom Error Handling with ASP.NET” and it was really about handling errors in a customized way. Specifically, it shows how to overcome the limitations of the customErrors feature by going beyond the On/Off/RemoteOnly settings (for those who don't develop your apps at the server console), so developers see detail while end-users see a simple “sorry,” on a page you can customize any way you like. Who sees what is configured by declaring the IP address block where your developers live, in case you were wondering.
While writing that article, I assumed that the custom exception methods like the EMAB still used the conventional events (e.g. Application_OnError), but they don't. Since classes which subclass the built-in Exception classes gather additional information at the time of the exception, they need to be created on purpose (here come the italics again) with your own constructor. And now for the important part (in bold so you don't miss it): Custom Exceptions need to be created inside a try...catch...fail. This is why the EMAB has a Publish() function. You can think of Publish() as a constructor that simply inits the custom exception object. 
Throw New System.ApplicationException (“This code breaks.”)
Catch (ex as System.ApplicationException)
Publish(“Code broke, aren't you glad you put it in a try...catch?”, ex)
' or perhaps this instead:
ThrowMyCustomException(“Something bad, right here!”, ex)
Where does this leave code that breaks in places you didn't have the foresight to contain in a try...catch...fail? Right back where you started. In those cases, your fancy custom exception methods are for naught. And in the above I'm also assuming the custom object can do someting meaningful with the ex exception passed it, that isn't the case in most code you'll find lying around the web.
The moral? Whatever you do (logging or notification) with custom exceptions, don't forget to do the same for conventional Exceptions. Is this why people wrap entire methods in try...catch...fail blocks, or why the Framework was designed so it isn't a significant hit to do so? 
The code is calling, until next time.
 EMAB's Publish() actually does more (you can build custom subscribers for the Publish event, wherein the EMAB's full power to confuse unwary developers lies), but let's leave it at “Publish() is like a constructor for a custom exception.”
 Rhetorical question.