On this page.... RSS 2.0 | Atom 1.0 | CDF
# Tuesday, 15 April 2008

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!

Tuesday, 15 April 2008 17:13:13 (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 

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.1

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,2 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.3 

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.4

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-tested5 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.

Tuesday, 15 April 2008 04:04:01 (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [1]  | 
# Saturday, 12 April 2008

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

At a fascinating talk at the XP 2002 conference1, 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.2 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.3  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,"4 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 time5 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 ThingsChristopher Alexander also discusses a similar principle in The Timeless Way of Building.

Saturday, 12 April 2008 16:06:39 (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 28 March 2008

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:
Wacom Bamboo Box

Not bad styling.  Let's open 'er up:
Wacom Bamboo Welcome Messages

"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.

Wacom Bamboo Open Box

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:

Ambrose 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.

Agile UX Design Process

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:

J. [Ambrose] Little

 

 

 

 

Nice.

Friday, 28 March 2008 17:32:00 (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [2]  | 
# Wednesday, 19 March 2008

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 2nd 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!

Wednesday, 19 March 2008 10:10:19 (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 17 March 2008

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.

Monday, 17 March 2008 08:54:27 (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 26 February 2008

I just had a remarkable experience (hence I'm remarking on it :) ).  At work, I park way out at the edge of our parking lot, which backs up against some undeveloped land.  I do it because I figure I gotta get some exercise somehow, but today I got an unexpected and delightful surprise.

As I was sitting there in my truck, finishing my yogurt and rosary, I took note of a group of red-breasted robins hopping around.  Robins are cute, but I don't find them remarkable in themselves.  But then I saw a male cardinal.  I think those are one of the most beautiful common birds with their striking red feathers.  So I was enjoying watching it, musing about its etymology, as one, two, then three blue jays flitted into view, which is another beautiful bird in my book. 

At this point I was thinking, wow, this is really cool.  Then a squirrel showed up and started chasing one of the robins around; I guess the bird snatched something he had his eye on.  I see squirrels all the time around here, so that wasn't particularly notable in itself, but it was just like slapping on extra gravy to the full on wildlife experience I was getting.  At this point, I was feeling like St. Francis. :)

But it didn't stop there!  I looked to my left, where a robin was eyeing me suspiciously, and something else caught my eye, flitting around on the ground.  When it paused to take a breath, I realized I was looking at a chipmunk!  Talk about brother sun, sister moon!  I don't think I've seen a chipmunk in the wild before.  Cute little boogers.

So I finished my stuff and was just about to step out of the truck when an iridescent black bird swooped in to roost right in front of my truck.  Icing on the cake, my friend.  Robins, cardinals, blue jays, a blackbird, a squirrel, and a chipmunk--right there around me all together.  Who needs a zoo!?

Now, nobody better start parking out there with me after reading this!  (For those of you not from around here, yes, this really happened--in New Jersey!)

Tuesday, 26 February 2008 11:14:40 (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [3]  | 
# Tuesday, 05 February 2008

Dominican Cross Given that tomorrow (Ash Wednesday) begins our season of Lent1, it seems appropriate to me to comment on the Dominican "colors" of black and white.  The friars habit (their outfit) is black and white (well, you might say white and black, depending on your perspective).  The Dominican cross' most distinctive mark is its alternating black and white, and many other derivative insignia use those two colors.

So what's up with these colors?  Were they picked just because they look good together, have great contrast, or what?  Well, they have a meaning.  The black represents penance, and the white represents joy. 

What an odd combination, eh?  After all, isn't penance about being truly sorry for one's sins, turning away from those sins, intending to not sin again, and even doing things to try to make things right (reparation)?  How can you have joy if you're penitent?

The thing is, that penance is really an act of faith, an act of hope.  Without faith and hope, it doesn't make any sense.  If you don't believe in a transcendent, objective Good (i.e., God) from whom the nature of good flows, it is hard to know, concretely, what evil is (essentially a negation/privation of good).  Sin is a moral evil; that is, it is an act that is not in accord with the transcendent, objective Good and thus in some way negates and loses that Good. 

Penance is an act of hope because without hope of forgiveness, of restoration of the good we've deprived ourselves (and sometimes others) of, there'd really be no point in penance.  Why even bother trying to make things right if there is no hope that they can be made right?  It just wouldn't make sense to do that; it'd be a waste of time and energy, and instead we'd just waste away in despair.

But for those who have faith and hope, penance makes a lot of sense.  And its precisely that--that faith and hope--that makes penance essentially an act of joy.  We can take deep consolation and joy in penance because we know that we are making things right through God's grace.  The good that we've lost is restored and then some, and that's where the joy comes in.

So tomorrow starts what we call the penitential season of Lent, about forty days of observing a spirit of penance prior to celebrating that greatest of all days, when God made it possible for us to get things right--Easter.  Tomorrow we get ashes to remind us of our fragility and mortality: "remember that you are dust and to dust you shall return" echoing the words of God spoken to Adam as the consequence of that original sin. 

But the story doesn't end there; if it did, we may as well just do as Job's wife suggested--curse God and die.  No, the story goes on to the redemption of humanity through the Incarnation and atonement that makes it possible for us to restore that original good and in fact to go beyond that to become partakers in that transcendent, supreme Good, that Divine nature. 

So we can with true joy be sorry for our sins and do concrete acts of penance (fasting, abstaining from meat, giving to the poor, visiting the sick, and many others) because we have the end in view; we know the story doesn't end with our screwing things up if only we accept in faith and hope the grace made available to us to make things right.

So I hope that Christians will join me in joy as we celebrate this season of penance looking towards the resurrection of our Lord.  And maybe those who are not will better understand why it is we do what we do. :)

Notes
1. The word "Lent" is from earlier English and Germanic words for spring (because it's around springtime).  "Easter" is another one of those where the Church co-opted an English word for Church use; good symbolism, though--the east, the rising sun, the celebration of the rising of the Son of God.

Tuesday, 05 February 2008 22:56:16 (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Saturday, 19 January 2008

One of the questions that gets asked and re-asked over the generations is "how can a good, all-powerful God exist if there is so much evil in the world?"  There's even a specialized term that's been created for dealing with that question--theodicy.  Needless to say, as many times as it has been asked, there have been answers given.  For some, these answers are sufficient, but the fact that it keeps being asked indicates that for some the answers are not sufficient.

I'm not about to say I have found the answer to silence the question, and even if I had, very few people will ever read this. :)  But I do think the correct answer is what has been offered by others, which is that evil exists so that greater good may come of it.

This answer is hard to swallow when we can't see the greater good, when we're being brought face to face with great suffering and the terrible things that people do to others or even just the suffering of the poor, those afflicted by natural disasters, and those who suffer as a result of accidents.  I think some would argue even that "natural" death itself seems to be an evil.  It can be very hard to see the greater good because these things stand out in stark, ringing, painful contrast to what we think of as the good life we want for ourselves and hope for others.

What is Evil and From Whence?
Tied up in this question is the deeper question of "just what is evil, anyways?"  If I recall correctly, St. Augustine of Hippo, one of the great Christian philosophers and theologians, proposed that evil is the negation of good.  Depending on how you take it, this may be a good definition.  A friend of mine once suggested he thought that evil wasn't just the negation of good but that it was the twisting, or perversion, of good, but I can see that falling under St. Augustine's definition in that if you are twisting or perverting something, you are refusing it as it is and changing it into something it is not, which I think is essentially a negation.

On this question, I tend to hold with St. Augustine, as his definition seems to be a simple one that really does encompass the meaning of evil, and it reflects even our common understanding of evil--as inclusive of human suffering and death as well as the rejection of God, the ultimate good.  I do think that human suffering and death are, taken solely in themselves, evil, though not absolute or unconquerable evil.  I think that such evil can be overcome by good.

To reinforce that suffering and death are evil, apart from it seeming obvious common sense, we also see in divine revelation that we humans were not made for suffering and death.  God made us and our world and said "it is good."  Our sin, that is, our turning away from the God who is the source of our life and joy and our turning inwards on ourselves, introduced the possibility for death and suffering.  I think the curse of Adam is not so much an external punishment inflicted by a seemingly vengeful God than it is an affirmation and explication of the natural consequence of our willful separation from the source of all being and happiness.

The Transcendent Good that Overcomes Evil
But God foresaw this and, from the foundations of the universe, planned to redeem us from our turning away from our natural end, which was and is eternal sharing in God's goodness, his love, his joy, and his peace.  He planned to come down to us and become one of us, taking on our whole human nature, purifying it, restoring it, and further dignifying it by infusing his own complete divine perfection. 

He thus empowered us to turn back to him and to receive from him again that which was our natural end to begin with--that complete human participation in the perfect divine goodness.  By becoming human, taking on our whole humanity, he not only restored us to our status as "good" creatures of God, he adopted us as his children.  Through Jesus, the only, eternal Son of God--through his incarnation and sacrifice--we can now truly become children of God.

The redemption of humanity through God's becoming man and atoning for our sin, in itself, is almost an infinite good.  As far as we humans are concerned, I think it is the most perfect good, and its goodness overcomes (is greater than) pretty much all evil throughout all human history, including the supreme evil of our turning away from our source of life and happiness, which is what got us into this mess in the first place.

By joining ourselves to the incarnate Son of God, we can come to share in this unspeakable goodness.  All suffering pales in consideration of this goodness, and in fact, we can take consolation in our own suffering by uniting it to the suffering of Christ.  In offering our suffering in such a way, we make that suffering a loving act, a gift, for our own sake and for that of our fellow human beings.

Through his overcoming of death by his own resurrection, he enables the rest of us humans to do likewise.  And that is why death, for a faithful Christian, is not an evil, but a good.  We know that we have eternal life through Christ.  We know that in death, we come to share more fully in the infinite perfect goodness of God.  This is why the Psalmist can say "precious in the eyes of the Lord is the death of his saints."

Now this is not to say that suffering isn't real by any means.  This is not to say that suffering and death are not evil.  They are.  Suffering and death is the natural state of humans separated from God; it is a consequence of our original turning away, which has created a real physical and spiritual corruption of the good human nature that we were created with.  Suffering and death are very real, and they are very painful.  When speaking of good overcoming them, we are not minimizing them; in fact, I'd say that the very reality of these is a stimulus to make us more aware of the incomparable goodness we receive from God through Christ.

Why Freedom?
Given all of this, the question remains, though, of why God would have allowed us to turn away from him in the first place.  Why grant us such freedom in the first place?  After all, we human parents restrict our children's freedom in order to protect them from hurting themselves.  Why didn't God keep us from hurting ourselves by turning away from him and entering into a state of suffering and death?

It is a fair question.  I think the answer is essentially the same--so that a greater good could come of it.  In this, I see two greater goods.  The first is the incarnation of God--God becoming human so that we humans could become more like God.1  This is why the original sin is known as the "happy fault" according to our ancient liturgy.2  Our original damaging of our nature occasioned God's joining himself to us and elevating our human nature, not just restoring us to our original state of human goodness but elevating us to be true children of God, more fully able to participate in his infinite goodness.

The other greater good is wrapped up in this:  Our freedom enables us to truly love.  Love, the free giving and sharing of ourselves with others, is the greatest act of good, and God desires for us to share in that goodness.  Without freedom, we cannot love; we can only mimic the act of loving.  We would be marionettes in God's great play.  In granting us freedom, however, God enables us to experience this supreme act of goodness, which is love--love of him and of others.

Eventually, we parents must let our children strike out on their own.  We must let them learn from their own mistakes and make their own decisions.  Only in doing so will they fully become their own selves, more fully human, and not an extension of us.  Loving parents will do what they can to protect their children, but they will also let their children develop into independent human beings.  Loving parents will teach their children the best path for them to walk in life, but they will also be there when their children choose to stray from that path and hurt themselves.

So it is with God.  In wanting us to be fully independent, to share fully in the goodness of love (that is, to become fully human), he grants us freedom, even freedom that we can use to harm ourselves.  He teaches us the right path to go.  First, in creating us, he imprinted upon our hearts a knowledge of the right path,3 then he reinforced and further illuminated this through his revelation of Himself--directly to Adam and Eve and later to Abraham, then through the Mosaic Law and the prophets, and finally in becoming human himself, teaching the Apostles, and through their writing and oral teaching, directing the Church with the Holy Spirit.  So he gives us freedom and shows us the best way to use it, but he also foresaw that we would not use our freedom wisely, so he planned from the beginning to pick us up and heal us from our fall, much like a loving parent treats the scraped knee or helps us recover from other, larger mistakes.4

So we see that God can be truly all powerful, perfectly and infinitely good and loving, and yet still allow evil to exist.  Evil exists both as a result of our freedom but also as an opportunity for good to abound, as a thing that spurs us on towards the good and to overcome with good.

The Ordinary Good That Overcomes Evil
Yet I realize that there are those who may be unable to perceive and appreciate the transcendent goodness of God in his creation, his giving us of our freedom, his revelation to us, and in his Incarnation and atonement that effects our redemption.5  Even so, for those, there is more to offer here.  I would suggest that even the ordinariness of human love, especially familial love, from a strictly proportional perspective, far outweighs all the evils in human history.  Think of it this way.  Almost every human being that has ever existed has experienced some, probably a lot, of just ordinary human love--love of parent, love of sibling, love of children, love of friends, and (for many) love of God. 

One could say that throughout our lives, the average human is surrounded by a swirling sea of human love that we never recognize because it is so ordinary and mundane.  It is not heroic.  It's just all those everyday experiences of kindness and sacrifice that are so small that, in themselves, they are not noticed.  But taken as an aggregate, I would suggest that these far outweigh the more shocking instances of evil in our history.

I would further suggest that especially when we see evil, some notable and notorious evil, the everyday human reaction is sympathy.  Think of 9/11, the tsunami, Katrina, earthquakes, floods, genocides, war.  For every great human evil, there seems to be a corresponding outpouring of ordinary human love.  In fact, it is often noted that such tragedies bring people together who would otherwise not be sharing with each other.

And so I think we should not wonder at the existence of evil.  Even in a purely human perspective, it seems to me that there is far more love in this world than evil and hate.  The fact that we seem to take more notice of evil strengthens this view because, as a rule, we humans tend to notice the out of the ordinary more than the ordinary. 

When you add on to all of this ordinary love the transcendent, infinite love and goodness that God has wrought in human history, all the evil pales all the more and we become truly thankful and at peace while enduring and witnessing evil because we know that there truly and actually is a greater good all around us every day, often increased in response to such evil, and we Christians have the firm hope of sharing in the eternal infinite goodness of God, leaving behind the evils of this present world and realizing the fullness of our human potential for good.  In light of all this, rather than wondering why evil exists, should we not be pondering why God created such a world in which love is so ordinary and yet so transcendent?

In pain, sorrow, and distress, suffering and death, let us not lose heart.  Let us cry out in our humanity with the Psalmist "O Lord my God, deliver me!", but also "I love the Lord, for he has heard the cry of my appeal."  For we know the trials of this life, however painful, are already answered through the work of Christ.  Let us not forget the ordinary love that surrounds us each day, and most of all, let us put our trust and hope in Him for "those who put their trust in the Lord are like Mount Zion, that cannot be shaken, that stands firm forever."6 

--
Given on the Memorial of Blessed Andrew of Peschiera, O.P.

Notes
1. St. Athanasius put it this way: "For the Son of God became man so that we might become God," which is to say that we might become partakers of the divine nature.
2. From the Exultet, an Easter Vigil hymn of praise.
3. This is what we call "natural law," which is essentially an inherent human capability to know from reason what is the best way to live.
4. Let's not presume, though, that God models his actions on ours; it is the opposite.  We understand something about God's fatherhood through our limited understanding of what good fatherhood is here on earth.  But that's part of the beauty of God's revelation--he meets us where we are, teaches us through humans, through words, actions, and the image of God that we have received from him that has been perfected in Jesus Christ.  When we try to understand God's paternal love, we must keep in mind that we do not judge him by our understanding of paternal love but rather use paternal love as a means to better understand his actions in human history, including our own history.
5. It is worth noting, however, that given our presuppositions about God and his revelation and action in human history, we Christians can make a pretty good account of why evil exists.  A person's inability to appreciate it, which is understandable for those without faith, does not change the fact that we can make an account for why God allows evil to exist. 
6. From Psalm 116 and 125, respectively.

Saturday, 19 January 2008 15:17:21 (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [2]  | 

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2017 J. Ambrose Little