Phwew!  I just moved yesterday (actually all weekend and yesterday and still more unpacking to go now!).  Man, all that moving is starting to wear, but we're very happy in the new place.  A lot more space to make room for number four! :)

On to the point.  Josh Smith has extended his Podder skinning competition.  For those who don't know, Podder is this nifty WPF-based podcasting client/player.  He designed it so that you can completely change the look and feel using skins.  I suggested a better term would be skeletoning, since you can change the structure in addition to the styling, but so far that hasn't caught on.  Be sure to tell him you think that's a better term!

I'm not sure why this didn't occur to me before...  I read recently another brief article about the negative impact of email on productivity the other day, so I was thinking about a way to deal with it that didn't involve, e.g., closing Outlook and maybe even setting an "I'm not available by email until 3p today" out of office type message--seems a bit extreme, and it would also preclude my getting meeting reminders. 

It occurred to me that what usually happens is I get the nifty little toaster popup notification while doing something, almost always click on it for more detail, and then get drawn into a distraction over it.  Similarly, I was using one of those Gmail Vista gadgets that would highlight when I had Gmail waiting, or I'd leave it open and minimized and see the Inbox count in the taskbar.  The problem was not (for me) so much getting too much email as having the regular interruptions that were occasioned by these terribly useful notification mechanisms. 

Having isolated the problem, i.e., having framed the question correctly (which usually the most important part of solving a problem), I asked "How can I make these notifications go away?"  And the answer was immediately apparent: turn them off. :)

To that end, I went into Outlook advanced email options (Tools -> Options -> Email Options -> Advanced Email Options--who knew notifications were advanced?!) and deselect all the notification options:

I then removed the Gmail notifier gadget, and I close my Gmail when done with it.  The magic is that I still get my task and meeting reminders, but I don't get the regular interruptive notifications.  This had an immediate noticeable effect--I could work through to a good stopping point on the thing I was working on, i.e., a point I'd normally take a break, and then I'd check my email.  Wow!  Who knew something so simple could make such a difference?  I figure if it is critical, somebody will call or come knocking on my door. :)

As a complimentary technique to that, I have taken my Inbox strategy to the next level, following a bit of advice given by Mark Hurst (who wrote a book on Bit Literacy [that I haven't read]).  One of his suggestions to avoid information overload is to keep your Inbox empty.  I previously already worked to do that because I used my Inbox like a to-do list (and don't like having a long to-do list), but Mark's advice is precisely not to do that--use it as an Inbox and get stuff out of it immediately. 

Having not read the book (in which I'm sure are tons of helpful little tidbits), I take that to mean act on it immediately if possible, file it if need be, or set up a task to do something with it later.  I was already doing the first two, but I've found this additional third technique to be a nice add.  There is a distinct satisfaction (for me anyway) to having an empty inbox--maybe it's my personality type. :)

I hope this maybe helps others out there in the same boat.

I haven't done any research, so maybe it is out there.  But I had a thought the other day as I accepted yet another invite to connect from yet another social networking site from someone I have connected with numerous times. 

Wouldn't it be great if I could have one, unified set of social contacts, my social network, that I could then just share out to various social networking sites?  I mean, sure, folks would have to opt into it, someone would have to think about the privacy issues, but good grief, it seems like we need something like that...

Just reading the first article in the latest edition of Microsoft's The Architecture Journal.  It's called "We Don't Need No Architects" by Joseph Hofstader.  I thought, oh good, someone voicing a dissident opinion, but the article is rather a rebuttal to that claim.  I figure maybe a response to the response is in order. :)

Mr. Hofstader suggests that architects think in terms of bubbles and devs think in terms of code and, by extension, only see part of the picture.  He describes various "architectural" activities such as analyzing the problem domain, choosing and applying appropriate technologies to solve problems, and the use of patterns.

Is it just me, or is this a sort of dumbing down of the developer role in order to support a, potentially unnecessary, distinction between it and "the architect"?  I mean, a smart developer needs to do all of these things, too.  They're not just code monkeys.

In fact, in introducing such a division in responsibilities, we would actually seemingly perpetuate a long-standing problem in software development--a disjuncture between the problem and solution space because we keep trying to insert these business translators (call them technical business analysts, software architects, whatever you want) into our methodology. 

What's wrong with this?  First, it puts the burden for understanding the business onto one (or a few) persons, but more importantly, it limits that mind share to those individuals.  That is never a good thing, but it is especially bad for software.  In so doing, it also puts a burden on those individuals to correctly interpret and translate (a considerable challenge) and finally to sufficiently communicate a design to developers--enter large specification documents, heavier process, and more overhead.

On the other hand, domain-driven design, for instance, is all about instilling domain knowledge into the solution and coming to a common alignment between the business and the solution creators.  It's axiomatic in business that you need a shared vision to be successful, and this approach to software creation is all about that.  Shared vision, mutual cooperation, and a shared language. 

It eliminates the need for a translator because both learn to speak the same domain language.  It eliminates the knowledge bottlenecks (or at least really reduces them), and it increases shared knowledge.  And DDD is not burdened with the distinction between an architect and a developer.  Agile methodologies in general are geared towards reducing barriers and overhead in the creation of software (and that's why they're generally more successful, and they can scale).

I hope that all the brilliant and more-well-known/respected folks will forgive me; this is not intended as a slight, but I have to ask--are we creating the "architecture" profession unconsciously just to create a more defined career path (i.e., a way for us techies to move up the ranks)?  Are we just going with the flow from an old but broken analogy?  Are we introducing roles that really would be better served through other, non-architecty roles?

To this last point, I see some folks suggesting "infrastructure" and "business" and "software" and "whatehaveyou" architects.  Why are we so keen on the term "architect"?  I'll grant, it does sound really fancy, but it is so, so painfully clear that it is ambiguous and overloaded (and inaccurate, if you ask me) .  Maybe these other roles do need to exist in some organizations, but it seems like we're just bent on calling them "architect" for no apparent good reason other than we've latched onto it as a respectable (and well-paid) moniker. 

In choosing to proliferate the "architect" terminology, we're perpetuating and extending the confusion around it.  We're purporting to solve the problem of it being ill-defined, but in reality we're doing the opposite.  And everyone (IASA, Open Group, Microsoft, to name some just in the latest issue of the Journal) is trying to do it all at once with little coordination. 

It seems borderline insane. 

Or maybe I'm the crazy one?

there is no spoon

A few buddies of mine, Phil Winstanley and Dave Sussman, have asked me to pass along that they're doing an upcoming DeveloperDeveloperDeveloper event in Galway, Ireland on 3 May.  So on the off chance I have some readers in that area, I figured I'd pass it along.

Enjoy!

I'm becoming more and more averse to the term architecture and architect in terms of creating software, partially because it is such an overloaded term that seems to cause so much continual opining about its meaning but, more importantly, because I don't think it is like what we do, at least not to the extent that seems to be commonly thought.

We are not building houses (or bridges, or skyscrapers, or cities).  Houses, and other physical constructions, rely on pretty much immutable laws of nature, of physics, chemistry, etc.  These sciences are sciences in the established sense--you can perform experiments repeatedly and get the same results, and others who perform those experiments will get the same results.  Physical building, architecture, and engineering is fundamentally a scientific endeavor because it is essentially serving scientific laws.¹

Software Serves Human Social Needs
Software, on the other hand, is fundamentally a human and social endeavor.  Above the basic electrical and magnetic level, i.e., hardware, it is purely human constructs built on layers of human-created abstractions built to serve human social needs--for, ultimately, business or pleasure.  As such, we (as a human industry) are pretty much free to create the abstractions as we see fit. 

Beyond the basic hardware translation layer, we are not bound by elemental laws, only by our imagination.  The problem is, it seems to me, that early software development was very closely tied to the electrical engineering disciplines that gave birth to computing machinery, so the early abstractions were engineering-oriented and assumed an unnecessary scientific and engineering bent.  Subsequent developments, for the most part, have built on this engineering basis, and our educational system has perpetuated it.  Even though relatively few software creators these days need to understand the inner workings of the hardware (and even one layer of abstraction up), such low-level engineering is at the core of many computer science curricula.

As the power of computing machinery has grown, we've expanded the uses of software to take advantage of the new power, but we have remained an essentially engineering-based culture and have accrued other engineering-related words such as architecture and architect.  We have engineers and developers, systems analysts, and architects.  We have projects and project managers, and many try to manage software projects as if they were building projects.  We have builds, and we say we're building or developing or engineering software.

We have, built into our very language, an implicit association with physical building, and we have the association repeatedly reinforced by those who want to draw direct analogies between our trades.  Certainly, there are similarities, but I tend to think much of those similarities have been manufactured--they're not inherent to the nature of software.  We've painted ourselves into a corner by such analogies and borrowing of techniques and language.

Perceived Crisis of Complexity and Terminology
Now we're having this crisis, as some seem to paint it, where we need to elaborate further and push the idea that our systems are like cities and that we need varying levels and kinds of architects to help plan, build, maintain, and expand these software cities.  We have folks struggling to define what an architect is, what architecture is, and creating various stratifications within it to expand on this analogy.  We purportedly need enterprise architects, solutions architects, infrastructure architects, data architects, and more.

There is I think a well-intentioned effort to fix it because we do see this corner we've painted ourselves into, but we're reaching for the paint brush and bucket to solve it--reaching for those same ill-fashioned analogies, techniques, mindset, and culture.  We see all this accrued complexity, and our solution is to make things even more complex, both terminologically and systematically, because we're engineers and scientists, and scientific problems are solved with scientific methods and precision, no?.

It seems the underlying problem is that we're approaching the problem all wrong.  The problems we're solving are fundamentally human problems, particularly social problems.  And by social, I don't mean social networking software that is now en vogue; I mean social in the basic sense of dealing with interactions between humans, be that economic, entertainment, education, social connection, or whatever.  It follows, then, that the best solution will be fundamentally human in nature, not scientific, not engineering.

Realigning with Our Core Problem Domain
Maybe we should avoid likening ourselves to engineering and scientific disciplines, and especially, we should shun terminology that ties us to them and binds our thinking into those molds.  As a man thinks, so is he, as the saying goes.  Surely, we can and should learn what we can from other disciplines, but we need to be more reticent to insinuate them into our own as we have done with building.

I do think various solutions have been tried to better align software with its problem domain.  Object-oriented design is at a generic level an attempt to urge this sort of alignment, as is its more developed kin, domain-driven design.  Agile and its like work toward human-oriented processes for creating software.  Natural language systems, workflow systems, small-scale (solution-level) rule engines, and even some higher-level languages have attempted this.  And in fact, as a rule, I think they succeed better than those more closely tied to the computing and building conceptual models, except that even these more human-oriented abstractions are chained by the lower level abstractions we've created.

What we need to do is continue to develop those human-oriented models of creating software.  It seems that we may be at a breaking point, however, for our continued use of the building paradigm.  Our repeated struggles with the terminology certainly seem to speak to that.  Our terribly confused and complicated enterprise systems landscape seems to speak to that.  Our control-driven, formal, gated processes have been most well shown to be broken and inappropriate to the task of software creation.

New Terminology
To make the next step, perhaps we should reexamine at a fundamental level how we think about software, both the artifacts and how we create them.  I think we need to make a clean break with the engineering and building analogy.  Start fresh.  Unshackle our minds.  Maybe we need to drill down the abstraction layers and figure out where we can most effectively make the transition from hardware control to our human, social domain.  I imagine it would be lower than we have it now.  Or maybe it is just a matter of creating a better language, an intentional language (or languages) and a move away from our control-oriented languages. 

At a higher level, we certainly need to rethink how we think about what we do.  Some folks talk about the "architect" being the "bridge" (or translator) between the business and the technical folks.  If that is a technical role, which I tend to doubt, it seems like a more appropriate title would be Technical Bridge or Technical Translator or Technical Business Facilitator or even just Software Facilitator.  Call it what it is--don't draw unnecessarily from another dubiously-related profession.

But maybe thinking this role is best served with a technical person is not ideal.  Maybe we technical folks are again trying to solve the problem with the wrong tools--us.   Well-intentioned though many are, if we are technical in tendency, skills, talent, and experience, we are not as well equipped to understand the squishy, human needs that software serves or best identify how to solve such squishy human problems.

Since software is essentially a human-oriented endeavor, perhaps we need a role more like that which has been emerging on the UX side of things, such as [user] experience designer or interaction designer.  They are better-equipped to really grok the essentially human needs being addressed by the software, and they can provide precise enough specification and translation to technical folks to create the experiences they're designing, even with the tools we have today.

Then again, some say that architects are the ones concerned with high-level, "important" views of a solution, interactions among individual pieces, that they are those who model these high-level concerns and even provide concrete tools and frameworks to help effectively piece them together.  I say that we could call this role solution coordinator, solution designer, or solution modeler.  But then, according to folks like Eric Evans, these folks should be hands-on to be effective,² which I also believe to be true.  In that case, what they become, really, is a kind of manager or, simply, team leader, someone who's been there and done that and can help guide others in the best way to do it.  At this point, the skills needed are essentially technical and usually just a matured version of those actually crafting the solution. 

Instead of software developers and architects, how about we just have technical craftsmen?  The term is appropriate--we are shaping (crafting) technology for human use; it also scales well--you can add the usual qualifiers like "lead," "manager," "senior," whatever fits your needs.  There's no unnecessary distinction between activities--whether the craftsman is working on a higher-level design or a lower-level, it is all essentially the activity of shaping technology for human use.  Depending on the scale of the team/endeavor, one craftsman may handle all levels of the craft or only part, and in the latter case, the division can easily be made based on experience and leadership.  And finally, it does not introduce cognitive dissonance through extremely-overextended and inaccurate analogy (like developer and architect).

Even if you don't like the term craftsman--we could collaborate to choose another that doesn't chain us to wrong thinking--the point remains that we should recognize that we've introduced unnecessary and unhelpful distinction in our discipline by using the dev and architect terminology.  We could begin to solve the conundrum by abandoning these titles.

Resisting the Urge to Rationalize and Control
Also, by looking at each solution as a craft--an individual solution tailored to address a particular human problem, it becomes clearer that we need not be so ready to try to rationalize all of these solutions into some greater system.  As soon as we do that, we fall back into the engineering and computing mode of thinking that will begin to impose unnatural constraints on the solutions and inhibit their ability to precisely and accurately solve the particular human need.³ 

As I suggested before, we should rather treat these solutions more like a biological ecosystem--letting selection and genetic mutation mechanisms prevail in a purely pragmatic way that such systems have so well embedded in their nature.  I believe it is a misplaced good intention to try to govern these systems in a rationalistic, control-driven way.  We deceive ourselves into thinking that we are managing complexity and increasing efficiency when in reality we are increasing complexity that then, recursively, also has to be managed in such a philosophy (creating an infinite complexity management loop).  We also reduce efficiency and effectiveness (well-fittedness) of solutions by interfering with solutions with controls and imposing artificial, external constraints on them to serve our governance schemes.⁴

Wrapping It All Up
Once we stop trying to align ourselves with a fundamentally different endeavor--physical building--we free ourselves to essentially orient what we're doing towards the right domain--human social problems.  In doing so, we can re-examine our abstraction layers to ensure they most effectively fit that domain at the lowest possible level, and then we can start building new layers as needed to further enable effective (well-fitted) solutions for that domain.  By changing our language, we solve cognitive dissonance and illuminate where distinctions are truly needed, or not needed, and may even recognize where skills that are not inherently technical would better serve our solutions (such as UX pros).  And lastly, by treating the solutions as fundamentally human, we recognize that the most efficient, effective, time-tested⁵ and proven technique for managing them is more biological and less rational.  We see that they can best manage themselves, adapting as needed, to fit their environment in the most appropriate way possible.

If we're going to have a go at fixing the perceived current problem of complexity in software and, by extension, further understand how to solve it through our profession, I suggest that a somewhat radical departure from our current mode of thinking is needed, that we need to break away from the physical building analogy, and it seems to me that something like what I propose above has the most long-term promise for such a solution.  What do you think?

Notes
1. I should note that I recognize the artistic and ultimately social aspects physical constructions; however, they are still fundamentally physical in nature--bridges are physically needed to facilitate crossing of water or expanse, buildings are needed physically for shelter.  The social aspects are adornments not inherent to the basic problems that these constructions solve.  The same cannot be said of software; it exists solely to serve human social advancement in one form or another.
2. See Eric Evan's "Hands-On Modeler" in Domain-Driven Design: Tackling Complexity in the Heart of Software.
2. As an aside, I truly do wonder why we should have to try to convince businesses of the need for the "architect" role.  If you ask me, the need, and our value/solution, should be obvious.  If it takes a lot of talking and hand waving, maybe we should question if the solution we're proposing is actually the right one.  ?
3. I have to nuance this.  Obviously, if there are governmental regulations you have to follow, some such controls are required; however, if you think about it, this is still adapting the solution to best fit the human problem because the human problem likely involves some need of societal protection.  Certainly not all systems need such controls, and even only some within an organization need them.  Keep the controls scoped to the solutions that require them due to the human social conditions.  On the whole, I'd say that there are vastly far more systems that don't need them, though the ones that do loom large in our minds.
4. By this I mean to say that, according to evolutionary theory, biological processes have developed over many millions of years and have proven themselves as an effective means for highly emergent, living systems to self-govern.  Businesses and human social structures in general, especially these days, are highly emergent, dynamic, and living and need software that reflects that mode of being.

In his article, "Who Needs an Architect?", Martin Fowler says:

At a fascinating talk at the XP 2002 conference¹, Enrico Zaninotto, an economist, analyzed the underlying thinking behind agile ideas in manufacturing and software development. One aspect I found particularly interesting was his comment that irreversibility was one of the prime drivers of complexity. He saw agile methods, in manufacturing and software development, as a shift that seeks to contain complexity by reducing irreversibility—as opposed to tackling other complexity drivers. I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.

How interestingly this melds with my recent thoughts on managing complexity.² You see, adding processes, management systems, and "governance" in general makes things more ossified, more difficult to change, i.e., less reversible.  According to Zaninotto, this would mean that the more governance we put in place to, theoretically, manage the complexity of our software systems, the more complex they are bound to become, which I think logically means that we are increasing our complexity woes rather than helping them through such efforts.

I came across this in a recent thread on our (now-retired-)architect MVP email list, where the age-old discussion of "what is an architect?" has come up again.  I have to admit, when I first seriously confronted this question, I was drawn in and fascinated.  I even wrote an article about it on ASPAlliance.³  Since writing that, I've been keeping an eye on the developments at IASA and elsewhere in this space, and developing my own thoughts.

I've delved even more into agile approaches, particularly Scrum and domain-driven design (DDD), and into this thing we call "user experience,"⁴ which at first glance seems counter to our architectural/engineering approaches to building software.  I've gained more experience building software as an architect and manager and observing software being built at the commercial level.  I've been more involved in the business and marketing side of things, and I've been blessed with the opportunity to learn from some of the leading minds in our profession. 

At this point, I'm of the get 'er done school, which I suppose might map loosely to Fowler's Architectus Oryzus, Eric Evans' Hands On Modeler, and others along those lines.  I'm bought into User-Centered Design (or human-centered design, for those who prefer that), though I think we need to figure out a good way to merge DDD with UCD and a smattering of service orientation (as needed!) to make software the best it can be.

Software is complex enough without our making it more so with artificial taxonomic and gubernatorial schemes.  Software should be teleological by nature.  It exists to serve an end, a purpose, and if it isn't serving that purpose, the answer is not to create counterproductive metastructures around it but rather to make the software itself better.

One of the chief complaints about IT is that we seem resistant to change or at least that we can't change at the speed of business.  Putting more processes, formalization, standardization, etc. in place exacerbates that problem.  The other biggie is that software doesn't meet the need it was designed to meet.  Both of these, at their core, have the same problem--ineffective and inefficient processes that are put in place to manage or govern the project.

I tend to think that projects need managing less than people need managing or, rather, coaching.  You get the right people, you give them the equipment, the training, and the opportunity to do the right thing, and you get out the way and help them do it.  You don't manage to dates (or specs!); you manage to results.  If you don't have a solution that meets or exceeds the need at the end of the day, you failed.  In fact, I might go as far to say that if what you built matches the original specs, you did something wrong.

Any managerial involvement should have a concrete and direct end in mind.  For instance, coordination with marketing and other groups requires some management, but such management should be communication-oriented, not control-oriented.  Start small and evolve your management over time.  Management, like other things that are designed, is best evolved over time⁵ to meet these concrete, real needs--and you should keep an eye out for vestigial management that can be extracted. 

Similarly, I don't think we need to tackle the software (IT) profession by trying to define and stratify everything we do.  In fact, I feel it would be a rather monumental waste of our collective valuable time.  One thing is certain, our profession will change.  New technologies and new ideas will combine with the rapidly changing business needs, and new roles will emerge while old roles will become irrelevant (or at least subsumed into new roles).  Monolithic efforts at cataloguing and defining (and by extension attempting to control) will, in the best of all possible worlds, be useful only for a short time.

It's clear that there are many approaches to doing software.  It's axiomatic that there are many distinct, even unique business needs (inasmuch as there are many unique individuals in the businesses).  What we should be doing, as a profession, (indeed what I imagine and hope most of us are doing) is focusing on how to make great, successful software, not wiling away our lives and energy talking about ourselves. 

If you ask me what I do (e.g., on a demographic form), I tend to put software maker, or just software.  Obviously, that's not specific enough for hiring purposes.  But really, in hiring, we're really looking for knowledge, experience, skills, talents, and attributes, not a role or title.  A title is just a hook, a handy way to get someone interested.  If the market shows that using "architect" in a title catches the attention you want, use it (whether you're a worker or looking for workers).  The job description and interview process will filter at a finer level to see if there's a match.

Outside of that, we don't really need to spend a lot time discussing it.  We're all just making software.  We all have unique knowledge, experience, talents, skills, and attributes, so there really is very little use in trying to categorize it much beyond the basic level.  So how about we stop agonizing over defining and stratifying "architecture" and "architect," stop worrying about controlling and governing and taxonomifying, and instead invest all that valuable time in just doing what we do--better!?

Notes
1.  More at http://martinfowler.com/articles/xp2002.html.
2. See One System to Rule Them All - Managing Complexity with Complexity and Software as a Biological Ecosystem.
3.  Read "What is Your Quest?" - Determining the Difference Between Being an Architect and Being a Developer.
4.  Good place to start: http://en.wikipedia.org/wiki/User_experience
5.  This principle is discussed, for example, in Donald Norman's Design of Everyday Things.  Christopher Alexander also discusses a similar principle in The Timeless Way of Building.

I finally gave in and bought a graphics tablet.  My budget being as huge as it was, I opted for the Wacom Bamboo, which retails at $79, but ANTOnline (via Amazon) had it for $50 plus shipping ($58 total).  I haven't been this tickled to get a new gadget in a while.

The whole experience thus far has been grand.  I placed the order at about 10p on Tuesday night.  I got an email Wednesday night saying it had shipped, and when I opened it Thursday morning and clicked the tracking number, I was informed it was out for delivery--and I paid for standard shipping.  Awesome.

I got the box later Thursday morning, and opened it to find a sleek box wrapped in tissue paper, as if it were a gift.  After sliding it out of the tissue paper, here's what I saw:

Not bad styling.  Let's open 'er up:

"This is your Bamboo.  Use it to get more out of your computer.  Let us know how it goes..."  In many languages.  Then it is signed by, presumably, the creators.  Very nice touch, I thought.  I felt like a proud owner already.  Then you lift up that insert, and there's the tablet in all its beauty.  Grab it out--there's the cord, the pen, the pen holder.  Great.  Simple. Obvious.  Beneath that is another tissue wrapped gift, a stylish little black box that has some simple instructions on getting going and the DVD.

Just opening the thing was a pleasure.  Honestly, these folks know what UX is, and this is just for an $80 graphics tablet. 

I plugged it in, and it immediately just worked.  Having read a comment somewhere, I just went to the Web site to download the latest drivers.  That was easy.  Install.  I had to try twice; it got hung up for some reason, but then, I did have 30 apps open at the time and they did suggest closing them all. :)

I immediately opened OneNote and went to town.  I started drawing the simple stuff as Dan Roam suggests in his new book, The Back of the Napkin.  (I attended his session at Mix and liked it enough to buy the book.)  Then I really went out on a limb and drew a self-portrait:

Not bad, eh? 

Well, it was a first shot.  I tried writing and realized just how bad my penmanship has become over the years.  Trust me; it's bad.  Nice thing is that maybe I'll get some of it back and improve it now that I have this (who knows?). 

I'm now on Day 2 of using my Bamboo, and I really like it.  My wrist, which had been hurting more as of late, has been loving me.  One of the reasons I tried this was to see if it'd be better to avoid "repetitive strain injury," and I noticed an immediate difference.  The other reason was because I get so tired of being constrained by drawing programs in terms of what I want to represent visually.  SmartArt in Office really, truly (as cool as it is) only goes so far. :)

So my first real use was to start diving into my Agile UX Design Process diagram to replace a particularly painful slide (Slide 19) in my Building Good UX talk.  It (both the drawing and the process) is a work in progress; just trying to visualize some of my thinking about it right now.

If you look hard, you can see my chicken scratch compared to the nice, free Journal font I picked up.  The point of this diagram is to show how to integrate UX pros into an Agile process.  Not saying this is all fleshed out or perfect, but it's a start. :)  One important point is that even if you don't have the pros, you can start doing the UX stuff yourself.

A Few Tips Using Bamboo (thus far)

1. Use Mouse mode.  When you install the driver, it switches to Pen mode, which tries to map your screen(s) to the tablet.  Even though Wacom recommends this mode (even provides exercises to get use to it), I found it frustrating when trying to draw on my right screen--I felt too close to the edge for comfort. 
2. Disable acceleration.  While it can be a nice feature when using it literally like a mouse, it messes you up when drawing.
3. Switch to the dreaded single-click mode in Explorer.  Back when the single click mode was added (XP?), I tried it out and was disgusted.  But double-clicking w/ the pen is just not easy, and actually, the single-click mode feels really natural with the pen.
4. Switch to scroll on touch ring. I don't feel too strongly about this, but honestly, I don't use zoom (the default) enough to have it as a top-level feature on the tablet.
5. Upgrade to Vista?  I think that you must not get ink in Office 2007 w/o Vista?  I can't figure it out, but it's not there for me in XP.  The Wacom site mentions Vista explicitly, and my searches haven't turned up anything useful.  Folks talk about "Start Inking" as if it is just always there, but it may also have something to do with Tablet PC.  I'll let you know if I figure it out.

It is taking some getting used to, of course, but so far I think it's a big improvement.  Ask me in a few weeks. :)

And now for the gratuitous signature:

 

 

 

 

Nice.

Just wanted to let you all know that I'll be speaking at and attending the upcoming ITARC in NYC, May 22-23. The conference is grass roots and platform agnostic. Grady Booch is giving the keynote from 2^nd life. There are some great roundtables and panel discussions on SOA, SOAP vs. REST, as well as others.

It should be a good opportunity to get involved with the local architecture community and participate in discussions on what is currently happening. The registration price is lower then other conferences because we are non-profit and just trying to cover the costs.

There is an attendance limit and the early bird registration ends this month so we encourage you to sign up as soon as possible.  Register Now!

For those of you that don't keep an eye on my work blog, my team at Infragistics just published a new Silverlight 2 sample application, faceOut, using prototypes of Infragistics' Silverlight controls.  If you're interested in Silverlight 2 and/or interested in what Infragistics is doing with Silverlight, you should check it out.

After posting my ramblings about software as a biological ecosystem last night, I kept thinking a bit more about the topic of managing complexity and what seems to be the high-end industry response to it.  Put simply, it seems that we're trying to manage complexity with yet more complexity (the whole adding gasoline to the fire analogy).  The more I think about it, the more absurdly ludicrous this approach seems.

And it suddenly came to me--we are seeking The Ring:

One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.

This is the solution the industry seems to propose with things like enterprise rule management software and other centralized IT governance initiatives. 

One Policy to rule them all, one Policy to find them,
One Policy to bring them all and in the darkness bind them. 
[Feel free to substitute System, Architecture, or any other grandiose schemes.]

Do we really want to be Dark Lords?  Is "the architecture group" the land where the shadows lie?  I guess some might indeed aspire to be dark lords ruling from a land of shadow, but it never ends well for dark lords.  As the history of Middle Earth shows (and indeed human history), you can't oppress life, creativity, passion, and freedom, at least not for long.  The yoke of tyranny will always be thrown off.  Life will find a way.  Attach other pithy axiom here.

Create software, systems, and policies that are alive, that encourage life, that can grow, adapt, and evolve.

This thought occurred to me the other day.  Maybe the right approach to managing complexity in business software is something akin to creating a biological ecosystem.  By this, I mean designing correcting mechanisms to address chaos as it emerges and, ultimately, (the dream) would be designing systems that are biologically aggressive, that is, they look for niches to fill and also take steps to preserve themselves.

I don't know.  I'm sure I'm not the first person to think about this.  It just hit me the other day as I was walking into work.  It seems like the more common approach we take is to try to create a mechanical system as if the complexities of human interactions (i.e., business) can be specified and accounted for in a closed system.

I attended a session on managing complexity at the ITARC in San Diego last October, and the presenter was, if I recall correctly, advocating the usage of more precise specification of business rules through the use of Object Role Modeling (and in fact Dr. Terry Halpin was in attendance at that session and was a active participant).  I had attended another session the previous day by a fellow from Fair Isaacs on business rule management software.

All of these folks struck me as very intelligent and knowledgeable, and yet it seems to me that they are going in exactly the wrong direction.  In fact, I left that conference feeling very whelmed.  I felt as if I were living in a separate universe; at least I got the sense that there is a software multiverse, parallel software development universes, with me living in one and a lot of those guys in another.  All this talk of "governance" and highfalutin systems (e.g., grid SOA) leaves one feeling so disconnected from the everyday experience of being a software professional.

It seems to me that the solution to complexity in IT is not to create ever more complex mechanical systems, policies, and infrastructure to "govern" the problem.  It seems like that's throwing gasoline on the fire.  Not only that, it seems fundamentally opposed to the reality that is business, which is essentially a human enterprise based on humans interacting with other humans, usually trying to convince other humans to give them money instead of giving it to some other humans that want their money.

Because humans are intelligent and adaptable, particularly humans driven by, dare I say, greed (or at least self-preservation), these humans are constantly tweaking how they convince other humans to give them money.  The point is, business is fundamentally a human and an aggressively biological, enterprise.  It consists of humans who are constantly on the lookout to fill new niches and aggressively defending their territories.  So it seems to me that business software should be modeled, at a fundamental level, on this paradigm rather than on the mechanical paradigm. 

Of course, the problem is that the materials we're working with are not exactly conducive to that, but therein lies the challenge.  I tend to think that the efforts and direction being made by the agile community and approaches like domain-driven design are headed in the right direction.  At least they're focusing on the human aspects of software development and focusing in on the core business domains.  That's the right perspective to take.

Extend that to IT governance, and that means giving various IT departments within an enterprise the freedom to function in the best way that meets the needs of their local business units rather than trying to establish a monolithic, central architecture that attempts to handle all needs (think local government versus federal government).  It means developing with a focus on correction rather than anticipation, building leaner so that when change is needed, it is less costly (in a retrospective sense as well as in total cost of ownership).

I'm not advocating giving ourselves over to the chaos; I'm just thinking that this is a better way to manage the chaos.  And as we learn the best patterns to manage complexity in this way, it seems not too far a stretch to think that we could start automating mechanisms that help software systems be ever more agile and ultimately even anticipate the change that is needed by the business, either automatically making the adjustments needed or at the very least suggesting them.  That would be true business intelligence in software.

Maybe it's a pipe dream, but I think that without such dreams, we don't improve.  At the very least, I think it suggests that the agile approach to software is the right one, and that this approach should be extended and improved, not only in software development but also in architecture and IT in general.

What do you think?

I've been getting friendly with Windows Live lately, and after getting terribly tired of having to switch to HTML view in Windows Live Writer in order to insert a note (could be a footnote or endnote depending on how you look at it), I decided to see if I could write a plug-in to make my life easier.

So was born the Blog Notes plug-in.  Unfortunately, there is no extensibility for just marking up existing text (e.g., adding a superscript button to the markup toolbar), so I had to go with the option to insert some HTML using the  interface.  I really was trying to keep it simple and lightweight (for my own sanity), so it is pretty basic.

The functionality is pretty straightforward.  Thanks to Mark James for the free icons.  Once the plug-in is installed, you should see an "Insert Blog Notes..." option in the Insert pane on the right side as shown below.

Clicking on it brings up the Blog Notes dialog:

Clicking "New Note" will insert a new superscript number (the next one in the sequence).

Clicking "Reference Note" will insert the selected number as superscript.  You can also just double-click the number to do that.

The "Notes Section" button will insert a notes section.¹

Lastly, "Write Note" simply adds the selected note plus a period and couple spaces.

As you can see, it's pretty basic, but it saves a few seconds for each note (assuming you bother to switch to HTML view, find the number, and put  tags around it like I do [did]).  You can also tweak one option/setting.  Go to Tools -> Options, and select the Plug-ins tab:

Clicking Options... on the Blog Notes plug-in brings up a tres simple dialog:

This one option will toggle whether or not the plug-in uses in-page anchor links for the notes so that the superscript numbers would link down to the corresponding note in the Notes section.  I originally added this feature without realizing the implications.  Because blog posts are often aggregated and otherwise viewed in unexpected places, using in-page anchors is iffy at best.  Community Server seems to strip them out, and dasBlog keeps them, but since it emits a <base /> tag to the site root, all of the anchor links are relative to the site homepage instead of the current post, which effectively renders them useless.  I looked at the dasBlog code where this happens, and it's in the core assembly.  I was concerned what side effects changing it to use the current URL would have, so I didn't do that.  But if you have blog software that will let you use this feature, by all means, enjoy!

Caveats

• Because of the way the plug-in framework works, I use a static/shared collection to keep track of the notes.  This means it acts a tad goofy if you close out of Live Writer or write multiple posts while it is open.  If you close and come back to a post, the notes count is reset.  To "fix" this, just re-add however many notes you had (if you want to bother).  If you write multiple posts, you just have to deal with it.  I don't know if there is post-local storage for plug-ins, but I didn't have time to dig into it.
• Your mileage may vary.  I wrote this mainly to save myself time and get familiar with the Live Writer extensibility model, so it ain't a finished product to be sure.

Get It!
Since there are numerous tutorials on the Web (that I learned from) to write Live Writer plug-ins, I won't go into those details here, but you're welcome to download my code and learn from it directly if you want.  I think I have comments and such in there.

• Download the Plug-in Only - If you just want to use this plug-in, this is what you want.  Drop the DLL into your plug-ins directory and go (typically C:\Program Files\Windows Live\Writer\Plugins).
• Download the Source Code - This is a VS 2008 solution for those who want to learn, enhance, extend, whatever.  The license is more or less the MIT license.  You'll need Live Writer installed to reference its API.

Notes
1. This is the "Notes Section."  The button adds the "Notes" header and writes out any existing note numbers.

Coming up on three years ago, I wrote "What is dotNetTemplar?" to explain the name a bit.  It briefly touches on why I chose to associate myself with the Knights Templar.  It doesn't really give an answer to who I am or what this blog is about.  After over three years of blogging here, I figure I should put up something to this effect.  I am writing this not in vanity but as a service for those few who may be curious about what and why I write on this blog.

A Bit of Personal History
I am Joshua David Ambrose Little, born just Joshua David Little.  Those who knew me prior to 2001 will doubtless have known me as Josh, except for those folks who knew me during college at Oral Roberts University, where I was known as Iain.  All these names deserve some explanation, and I'll get to that.  Born in Little Rock, AR, I moved to Tulsa, OK when I was almost three, and I grew up there, attending various public schools, but mostly Victory Christian School, of evangelical (charismatic) Protestant persuasion, from which I graduated in 1996.

On to University, or, My Life as Iain
I went across the street (literally) to Oral Roberts University the following fall.  I considered the University of Tulsa as well (had scholarships to both), but decided on ORU.  The choice came down to whether I intended to pursue engineering of some sort or something in liberal arts, and when I decided on liberal arts, I decided on ORU.¹

As I waited in the registration line at ORU, I pondered what major to go with, and when I reached the front of the queue, on the spur of the moment, I declared history to be my major.  A day or so later, still during orientation, I realized just how many Joshes there were at ORU, and decided to choose a nickname to go by so I didn't have to look over my shoulder every 15 minutes when someone yelled "Josh."

I decided to go with Iain because I was still in my Scottish phase at the time, and recently a well-known piper and member of the Scottish Club of Tulsa (SCOT), Iain MacPherson, had passed away.  Going to college seemed like a good time to make the change.  Thus I became Iain Little to folks at ORU.

Iain remained only a nickname, and sometime during my senior year, I decided that I would ditch it after I graduated.  So when I went to work for InfoTech in Tampa², during the summer of '98, I went back to Josh.  InfoTech was the first software job I got by just saying "give me a couple weeks and see if I catch on"; it was my first real foray into professional software development, even if it was in a rare language/platform called PROGRESS.  [Of course, I, like many in our industry, had toyed with computers and software since I got my Commodore 64 as a lad, but this was the first real software job I took on.]

So I was  Josh at home and at work, but still Iain at school (it would've been too much trouble to change that for the last year).  I was on track towards becoming a professor when I got married in May of '99.  That summer, I attended a Pew Younger Scholars Program at Notre Dame, which was a three-week graduate seminar, and it was there, after many long phone convos with my new wife, that I determined that professional history was probably not the best choice for me.  I found it to be a little too tedious for my tastes; you pore over sources for years just to argue the case that X is true.

Beguiled by Software, or, The dotNet in dotNetTemplar
With renewed interest in computers and software, I started researching what the best path would be.  I pretty much knew it wouldn't be PROGRESS, and at the time, it seemed that Visual Basic was the hottest thing out there.  After buying NT 4.0 and VB 6 at the university store (thank God for academic pricing!), I dug in that summer, and in October of '99, I applied to Fireant (later to be known as XOR) for work. 

They asked me if I knew what ASP was, and I had no clue, nor did I know what SQL was, but I told them to give me a chance.  After a technical screening just to make sure I knew basic programming concepts, they let me on for a probationary period.  Thankfully, ASP and SQL were super easy to pick up (at least well enough during those heady days of the dotcom boom), so after two weeks, we came to an agreement, and I started with them officially.

I went full-time there (as Josh) before graduating in 2000, and that launched me onto the career path I'm in now.  Since then, I've had the good fortune to work at numerous companies: BOK Financial, Verizon, GTE Federal Credit Union, ASPSOFT (for angryCoder), BST Global, and now, happily, for Infragistics.  In the meantime, I've written a few technical books, many technical articles, spoken at numerous technical events, and I am honored to have been recognized as a Microsoft MVP for six consecutive years.  I keep track of my professional details on my MVP Profile, in case anyone's curious. :)  Also, feel free to connect³ if you like.

So that's where the "dotNet" in "dotNetTemplar" comes in.  I'm something of an expert in Microsoft's .NET technologies (picked it up in 2001 and haven't looked back!), and a portion of what I blog about here is technical, usually related to .NET, though these days I tend to be a bit more architectural in my blogging than technology-specific.

Beguiled by Truth, or, The Templar in dotNetTemplar
But that's only the half of it.  Where does the "Templar" bit come in?  I already alluded to a post I wrote a few years ago on that, but there's more to it.  As I commented recently in reference to why I joined the Lay Fraternity of the Dominican Order, I have been enamored of truth for a long time.

As a result of my pursuit of truth, I ended up joining the Roman Catholic Church on Easter Vigil 2001, at which point I took the confirmation name of Ambrose, after St. Ambrose of Milan, a 4th century bishop, Father, and Doctor (formally-recognized great teacher) of the Church.  There were many things that drew me to St. Ambrose.  Mostly, it was his love of learning (he is the patron saint of learning) and his tenacity for truth--in his writings and in resisting the Arians and great political powers of his age, but also his love for life⁴ and for the poor.  In short, I consider myself a man after his own heart, and of all the saints, I feel inexplicably close to him, and that's why I took his name.

My conversion to the Catholic Faith was significant enough to me that I decided to not simply take Ambrose as a confirmation name that is only used at the confirmation ceremony.  My conversion was the result of a long wrestling with truth, even a wrestling with God in a sense.  Because of my upbringing, I was unconsciously suspicious of and prejudiced against Catholicism (though not outright anti-Catholic), so it took a while for both me and my wife to come around to joining the Church.  Even though I overcame my intellectual objections earlier, we didn't feel comfortable becoming Catholic until 2001 (after a few years of being Episcopalian).

So like Jacob wrestled with God and received the name Israel, I had wrestled with God and received the name Ambrose at my confirmation and reception into the Catholic Church.  To mark the significance of this event, I took on the name legally, choosing to go by it going forward, and anyone who didn't already know me as Josh or Iain now knows me as J. Ambrose Little (but just "Ambrose" in person).  I hope to at least faintly do honor to that great name.

As I hope is obvious, my faith is a fundamental part of my life.  And that's where the "Templar" part of dotNetTemplar comes in.  This blog is a blend of my musings on software and technology as well as my philosophical, theological, historical, and general thoughts on life, the universe, and everything. 

What can I say?  It's a personal blog; it's dotNetTemplar; it's who I am and what I care about.

What Do You Care About?

Everything [Subscribe] - Of course, I'd love for you to subscribe to all of my mental meanderings!

That said, out of consideration for those who may only be interested in one half of the dotNetTemplar, I set up two basic categories for you:

• Technical [Subscribe] - For my technical/software-related musings.
• Non-Technical [Subscribe] - For everything else.

There are more focused categories, but since this is the basic divide of topics on this blog, I thought I'd make it easy on folks.

Notes
1. I also had a better scholarship and had more friends going to ORU. :)
2. My mom had moved to Tampa at the end of the summer of '97.  I like to say I went to college, and my parents went away, since it's more usual that one goes away from parents to college. :)
3. LinkedIn, Facebook, Plaxo, MySpace, and last but not least, Live Spaces.  Phwew! 
4. Pope John Paul the Great quoted Ambrose's argument against capital punishment in JP's encyclical Evangelium Vitae (Gospel of Life).  For me, that was the most compelling argument against it, and what else I've read of Ambrose has a similar clarity, earthiness, and vitality.

Far be it from me to put words in Phil's mouth, but I hope that folks recognize that his post about favoring composition over inheritance is not specifically about that one best practice (the comments seem to indicate this is being missed).  It's pretty clear to me that the thrust of that post is around a philosophical approach that he thinks the ALT.NET community should make.

Two things stand out from Phil's post in this respect: 1) don't appeal to authority, and 2) don't organize yourself around a set of technical principles (best practices), but rather organize yourself around the non-technical values of independent thinking and desire to improve.  I hope that everyone can agree that these latter two values are good ones that should indeed be encouraged.

That said, should a community like ALT.NET eschew forming a more formal consensus on technical best practices?  I tend to think not.  While independent, critical thinking is valuable, it is not the summit of perfection.  The summit of perfection, in the realm of ideas at least, is conformance with truth (what actually is versus what I think is), and independent thinking at odds with what is true is not only not valuable in itself, it can be downright detrimental. 

For instance, what if you independently and critically think that security and privacy are not important aspects of the online banking application you are tasked with building?  Is that kind of independent, critical thinking valuable in itself?  Or will it potentially lead to great harm?  Independent, critical thinking is valuable only in as much as it deepens one's understanding of and conformance to truth.

So I think that there is value in a community such as ALT.NET expending the effort to define principles through critical thinking and argumentation that it will hold up as ideals, i.e., things that seemed to be most in accord with the truth as we know it.  This is where things like patterns and best practices come into play; it is the shared, accumulated wisdom of the technical community.

Now what about the broader idea of eschewing appealing to authority?  Far be it from me to claim to be an authority in logic, but it seems to me that all appeals to authority are not invalid (the wikipedia article Phil links to discusses this to some degree but does not go far enough, in my estimation).  The valid reasons for appealing to authority are discussed at the bottom of that article: 1) not enough time and 2) concern at one's ability to make the other understand the reasoning underlying the truth being expressed.

In terms of logic, it is not a fallacy to appeal to an authority on a topic that is accepted by all those involved in an argument.  We're talking about presuppositions here, and without them, we'd never get anywhere in our search for truth.  If you always have to argue from first principles (if you even acknowledge those), you simply get stuck in a quagmire.  In terms of the topic at hand, if folks accept (as they generally do) that the GoF et al are authorities on the subject of OOD, then it is valid, logically speaking, to appeal to their authority to establish the principle that you should favor composition over inheritance.

The thing to watch out for in appeals to authority is 1) thinking that the authority is incapable of being wrong and 2) ensuring that the parties involved accept the authority.  With the latter, you simply cannot argue (or at least the argument won't carry weight) from authority if the authority is not accepted.  With the former, unless it is a presupposition shared by those involved that the authority is indeed infallible, you should keep in mind that even if you buy into the authority's credentials, it is still possible that the authority can be wrong.

So I would nuance what Phil says and say that if the ALT.NET community agrees that GoF is an authority, it is valid to appeal to them, while remaining open to criticism of the concepts involved (even those backed by an authority).  The authority adds logical weight; it does not impose absolute authority.

We just don't have time to argue everything from first principles.  Others who are generally acknowledged to be qualified have already taken the time to research, think about, and propose some good patterns and practices, and unless there is good reason to object, there is no need to rehash those.  Instead, I'd suggest that the community focus on spreading knowledge of these patterns and practices all the while refining them, functioning essentially as a group in the way that Phil recommen