+dotNetTemplar+

Silverlight Controls

Wed, 29 Oct 2008 09:10:19 GMT

The good folks over at Microsoft have released their Silverlight Toolkit today (or I guess yesterday, now). It's a good start to complement what you get in the core/box. I personally found the AutoCompleteBox probably the most interesting control, and the theming capabilities being introduced with the ImplicitStyleManager are promising, too. I also like the way the team is running the toolkit project on codeplex and all. Shawn Burke (of Ajax Control Toolkit fame) is a great guy to be leading that group of talented folks.

Of course, in my humble opinion ;-), no discussion of Silverlight controls would be complete without looking at the outstanding work that Infragistics is doing, particularly in the data visualization space. In our current CTP that you can download now, we have the xamWebChart, xamWebGauge, xamWebMap, xamWebTimeline, and xamWebZoombar.

If you go to http://infragistics.com/silverlight, you can read about all those controls, but I encourage everyone to just go play with them in our really awesome (if I do say so myself!) Silverlight controls samples browser. I mean, it is just plain fun tweaking around with it. I could sit and watch the datapoint transitions all day, and the chart zooming is freakin' cool. Needle dragging gauge, overview plus detail implementation for the map, timeline... Heck, who am I kidding? It's all sweet!

I'm not just saying that because I work there; I really was just having fun and am frankly impressed with the work our guys are doing. Kudos to our entire Silverlight team! Great job, guys! I'd name names, but I'm bound to forget someone. You know who you are!

And the fact that I'm playing with this in Safari on my Mac over my crappy hotel internet access just makes it that much cooler and fun. You gotta love Silverlight!

If you're interested more in Line of Business (e.g., Outlook bar, hierarchicial data grid, tree, etc.), check out our info on Silverlight LOB controls. According to our roadmap published there, you should see a CTP of our first release towards the end of this year. Silverlight rocks, and I'm looking forward to seeing it develop and being a part of making it even better.

You should stop by our booth at PDC, if you haven't already, and ask about all this. We're Booth #201 (about 3 down on the left from the middle entrance). There's still some time left, and you can pummel the guys and gals there with your questions. Of course, you can always just call, chat, or email someone as well (or use the contact link on this blog, and I'll put you in touch).

Also, feel free to stop me in the hall at PDC if you want. I won't bite. Everyone says I look like Kevin Smith (which is why I was Silent Bob at the Expo reception Monday), so you should be able to recognize me, even without the trenchcoat. :) Now I have to get to sleep so I can keep my promise and not be a zombie (and ergo not bite). G'night!

Life Isn't the Only Issue

Thu, 23 Oct 2008 03:42:12 GMT

My most recent post on how I choose whom to vote for dived into a bit of depth on the two key principles that factor into my decisions in this important part of our lives as citizens in a democratic republic. One of my colleagues said to me something like "it's just plain silly to vote on one issue." Put another way, "life isn't the only issue, dude." This is actually a common sentiment, especially by those who, for whatever reason, want to justify voting for candidates who support (usually) abortion as part of their platform.

And yes, it's true. There are more issues to think about than life issues and abortion in particular. No doubt about that.

Issues of Consequence

But to be a responsible voter, we have to think like adults--we have to weigh issues not only in number but also in importance, in consequence. For instance, is a candidate's position on technology of more or less consequence than his position on education? That's certainly debatable--there are many nuances and ways of tackling both of those, some of which would be a win-win.

On the other hand, when you compare the consequences of a candidate's position on abortion to even something as near and dear to our hearts as the state of the economy (our own personal savings), which seems to be capturing folks' imaginations these days thanks to current events, there is just no comparison. I don't care if my life savings is wiped out. My pecuniary situation must take second chair to protecting the lives of the millions who have been and will continue to be killed with the consent of the law.

Today, there are very few issues that can claim the priority and consequence of abortion. As explored in my last post, protection of life must come first. It trumps economy; it trumps education; it trumps health care; it trumps foreign policy, and it even trumps social services. If you don't have life, none of this matters. It is plain, simple, straightforward logic.

If you vote for a candidate who supports abortion, you are consenting to and indirectly participating in the death of each and every baby who has its brains sucked out, who is mangled, chemically burned, poisoned, or killed in any one of the many diabolically creative ways they've figured out how to do take human life in a mother's womb. I apologize if it offends sensibilities, but you need to make an informed decision and realize there is real, moral culpability involved in voting for candidates who support abortion. Is your 401(k) worth more than these babies' lives?

We can disagree on the propriety of the Iraq war (I have always opposed it but believe we are responsible to try to fix the mess we've made); we can disagree on the most effective means for social and economic stability; we can disagree on the death penalty, and we can argue about the right way to fix the environment. There are plenty of issues where good, honest folks can have good honest disagreements. We have to think about all these, but we also have to weigh them proportionately.

Religion or Science?

[If I could do side bars on the blog, this would go there. So just imagine it being there.] A lot of folks, including Senator Biden, seem to think that when life begins is a matter of faith. It's not. Life is not just a religious issue; it's about as biological and primordially human as it gets. Human life begins at conception; this is scientific, not religious--if you don't interfere with a newly-conceived human being, he or she will develop into an adult human being. It doesn't matter if they're self aware or not; they're still alive and have everything, genetically speaking, they'll have as adults. You can't distinguish based on awareness--that's a slippery slope. What about the severely mentally retarded or the senile? What about newborns? What level of self-awareness do you require? What's the IQ score you have to have? Who decides?

Our Current Choices

Obama has said that the first thing he'll do if elected is sign into law the so-called Freedom of Choice Act, which would have the effect of overturning all existing laws that limit abortion and making it harder for future limits to be created. He has a strong, indisputable record supporting abortion, which is why NARAL and other pro-choice organizations are so keen on him. When asked, he claims issues of life are "above his pay grade," but he has no reluctance to take actions based on this purported ignorance.

As George Weigel wrote recently in Newsweek, "Is John McCain a perfect pro-life candidate? Of course not. But Barack Obama is a perfect pro-life nightmare." I really wish there were a party that embodied my perspectives completely, but that'll never happen. I think that's true for pretty much everybody, so we just have to decide what's more important and vote along those lines. For my part, I just can't see how anything is more important than protecting human life, and I can't deaden my conscience enough to vote for someone who has clearly deadened his own. Life isn't the only issue, but it is the most important one.

How Do I Choose Whom to Vote For?

Tue, 02 Sep 2008 00:16:38 GMT

[Download/Print]

In writing this first and hopefully last political entry, I hope to help others who struggle with the question “How should I vote?” or “How do I choose whom to vote for?” If nothing else, I hope it will contribute more depth to the often polemical and superficial discussion that is our political milieu.

First off, let me say that sometimes I wish I could be a Democrat. Democrats have a great story. They work for the average Joe. They want to make sure that the poor are taken care of. They want social justice. That’s admirable; that’s something I can get behind.

For my part, I consider it part of my moral obligation to help the poor and those less fortunate. As a Catholic (or even just a Christian for that matter), it is pretty clear that caring for the poor is a basic moral principle for us, and what this means has been elaborated on and acted on throughout our two thousand year history. It has taken different forms as the cultural, political, and religious landscape has changed, but it was and remains a core concern for the devout Christian.

Fundamental Principles

By the same token, it’s also my Catholic/Christian philosophy that informs how I think about other social and political issues, including those far more fundamental, those that are the logical source of an active care for the less fortunate

You see there are those, both antagonistic and sympathetic, who suggest that a concern for others, a care for the less fortunate, should trump these more fundamental concerns. For some, this argument is purely rhetorical, but there are surely those who honestly believe in this perspective. Some of these people are close to me, and I don’t doubt their sincerity.

The problem is, I think, that there is a failure to understand the connection between these more fundamental issues and governments’ role in them, to understand the pragmatic importance of these issues, or, in some cases, to even properly value them. The fundamental issues I am referring to are those of life, first, and family, second.

Why Life Matters

Let’s begin with the first principle of life. Even our founding fathers saw the primacy and importance of this topic. Our Declaration of Independence begins with what they claim are self-evident truths, a list of unalienable rights, the first of which is the right to life. These are there to introduce the primary principles for which government is established and, in particular, our own here in these United States.

It doesn’t take a religious perspective to appreciate the fundamental importance of life, and it is not a logical jump to understand that government, which should be directed toward the common (i.e., shared, social) good, should set as its number one goal to protect the lives of its citizens--all of them, especially those who cannot, for whatever reason, protect their own lives.

It is from this fundamental principle of life that the other principles and rights both logically and practically flow. And therefore there is an implicit subjugation of these other rights (such as liberty and the pursuit of happiness) to the right of life. It follows then that a government can, in order to ensure the most fundamental right to life, restrict these others. I would suggest that it also follows that if a government inverts this order, it is inherently disordered and consequently needs to be corrected.

For if a government cannot duly ensure the right to life, all of these other rights and, certainly, privileges are in no uncertain jeopardy. We must protect life first and foremost and, if necessary, at the cost of other admirable ideals such as liberty (or “choice” as some put it) as well as concern for the economic welfare that enables the pursuit of happiness (or property, as John Locke would have it).

This is why I think that life issues must always trump economic issues (including care for the poor). If we don’t get life right, we have to seriously question both our priorities and maybe even our ability to properly think about care for the less fortunate.

Similarly, we have to vote for candidates who have these priorities straight, those who understand the primordial and fundamental importance of life and government’s principle obligation to protect it in all forms, from conception through to its natural end. Because if they don’t then they--just like a government that does not prioritize life over liberty and other rights and privileges--are unfortunately and seriously disordered. However well intentioned they may be, we must seriously question their judgment and their ability to govern wisely if they do not understand the government’s priority to protect life.

Why Family Matters

Let us turn now to our second fundamental issue--the family. It is often said that the family is the fundamental building block of society. This is true both in terms of societal stability but also in terms of the fundamental concerns of the perpetuation of a society. It is through the family that the future members of society come, and, therefore, it is through the family that the future of the society itself is perpetuated.

Any human society that values itself will inherently value its own perpetuation; it is essentially societal self-preservation that we are talking about. From our earliest human origins, the family has been the normative means for the perpetuation of society in all its forms. It is the most tried and true (and logical) way for this self-preservation to occur.

Similarly, the normative form of the family has been that of a man and woman. The simplest reason for this is, if for no other reason, due to our biological situation, our needing male and female to engender new lives. And given the very real (even biological) personal investment in the creation of these new lives, it follows naturally that those who engender them will normally be those who care for and raise them. This is of course ignoring the psychological and, dare I say, metaphysical factors that inform us that the biological parents should normally be the ones who take on the roles of mother and father.

(I hate to seem overly simplistic here, but we are talking about fundamental human principles. It seems to me that so many of us must take them for granted, so I think it is worth verbalizing them to help us think about this stuff more clearly.)

Any society worth its salt will do what it can to strengthen the normative family because it is, simply put, in the society’s best interests to do so. And we see this played out in those governments (like our own) that do create formal structures to support it, such as marriage and the many privileges given to spouses and parents in our laws. These privileges (not rights!) are there to support the normative family in hopes that it will further the perpetuation of the society and, by extension, our common good.

Supporting the normative family (like life, though secondary to it) is a fundamental issue for government. Supporting and reinforcing this primordial social unit through which the future of society is ensured should therefore supersede other concerns. And ensuring its elemental structure--a man and a woman having children and responsibly raising their children--must supersede concerns about economic welfare because in the same way that life logically precedes the exercise of other rights and privileges, so the structure of the fundamental family unit logically precedes concerns about other social conditions.

It is unfortunate that we have to make this priority explicit—because we should absolutely care about ensuring economic welfare—but this fundamental family unit structure is in question in our society today and is being pressed by many who recognize clearly the secondary concern of economic welfare. Sadly, we must first deal with this question and settle it correctly, in a way that ensures the fundamental structure of our society and consequently its perpetuation. Only then should we turn our attention to the very important concern of economic welfare.

Again, since the essential function of government is to secure the enduring, common good of the society it serves, and since any society that values itself will preserve itself by ensuring and protecting the normative family consisting of a man and a woman having and responsibly raising the future members of society, it follows that we should elect members of government who will likewise work to ensure and support this fundamental unit of society. Right now, while the nature of the family is in question in our society, we must more than ever work to elect those who share this urgent priority to finally settle this issue in a way that is in the long-term best interests of our society. We cannot redefine and dilute the elemental structure of the family, however well meaning we may be, without endangering the long-term good of our society.

Have Your Principles and Welfare, Too

Now, I started out by saying that there are times when I wish I could be a Democrat. I said this because they do have many admirable ideals, chief among which is care for the less fortunate. But the thing is, unlike ensuring that our government protects the fundamental principles of life and family, the impact of which can only most fully be realized through government, care for the poor can be (and most often is) attended by charitable works that are not governmental in nature.

In other words, you don’t have to work through the government to care for the poor, but you do have to work through the government to ensure the right to life and the fundamental character of the family. Therefore, if we must, sadly, choose between a government that protects life and the family and one that is focused on economic good, it seems clear to me that we must opt for a the former.

The good news is that in doing so, we don’t have to leave care for the less fortunate behind. In fact, I would suggest that a more effective and laudable approach would be for us to make personal, active investment in the care of the less fortunate. Give to charities. Volunteer in charitable works. Give to those who ask and even to those who do not. It is much more blessed and, indeed, enjoyable to choose to give than to be forced to give by your government. And if we all did it, we wouldn’t need to try to make each other do so through the government.

So that’s how I think about choosing whom to vote for. I hope that there are those who will find some help here, and if nothing else, I hope it will help those who are of a differing persuasion to see that despite the rhetoric, there are good reasons to make issues like abortion, euthanasia, marriage, and family deciding factors in deciding how to vote. These issues are fundamental and primary for society and government and will therefore have a much more profound and long lasting impact than other, albeit important, issues like foreign policy, economic policy, and national security. It’s not a matter of laziness or simplemindedness; it is a matter of principles.

Peace be with you all.

--
Mr. J. Ambrose Little, O.P.
Given on the First Day of September, A.D. 2008

UPDATE (6 Sept 2008): I was happy to see one of our pastors, Most Rev. R. Walker Nickless, reiterate essentially what I've said here and expand even further. Always nice to be in such illustrious company. :)
UPDATE (11 Sept 2008): Seems that Pelosi and Biden's remarks have provided a very timely opportunity for the Church to reiterate her changeless teaching on these crucial issues as well as provide more solid guidance for Catholic (or just plain conscientious) voters.
UPDATE (14 Sept 2008): I just ran across this little video on CatholicVote.com that kind of says in pictures what I say above. I should say the conclusions about the primacy of life and family are the same, though I deal with it from a not-specifically-Catholic perspective in my text.

UPDATE (12 Oct 2008): Just noting more bishops reinforcing this. Bishop Joseph Martino of Scranton (where Biden likes to point out he hails from) and Bishop David Zubik of Pittsburgh. Bishop Martino is one of the clearest and forceful messages on this issue so far.
UPDATE (22 Oct 2008): Most Reverend Kevin J. Farrell and Most Reverence Kevin W. Vann (of Dallas and Ft. Worth, TX, respectively) have offered yet more clarification (PDF) on these issues.
UPDATE (1 Nov 2008): This'll be my last update I expect, given the nearness of the election. I've come across a few more bishops speaking out, but I was pleased to find that someone's been keeping a lot closer tabs. Over 115 U.S. bishops have spoken out in recent months to defend the (true) Catholic position on these and related matters as they pertain to our participation in the democratic process. Honestly, this is amazing and heartening. Our bishops seem to be hardening their collective backbones. Kudos to them and thank God.

Clan Little Expanding to Six

Wed, 27 Aug 2008 01:42:05 GMT

Today I went with Mrs. dotNetTemplar, along with our three ambulatory munchkins, to see the latest addition to Clan Little on the big screen. Well, it was like a 25" screen, anyways. At the last ultrasound, the technician said she thought it was a 90% certainty that the new one is a boy, but today it was confirmed pretty much beyond doubt. That makes 3 boys! Yikes! :)

It's always nice to see the little boogers kicking around, even in low fidelity, and the other kiddies enjoyed it too. It's very clear that there's a person there, and he already bears the name Thomas Martin Bonaventure, after St. Thomas Aquinas, St. Martin of Tours, and St. Bonaventure.

So it was with that in mind when I bumped into the news that Speaker of the House Nancy Pelosi totally misrepresented the Catholic position on abortion in an interview on Meet the Press. Thankfully numerous Catholic bishops have spoken up to provide the accurate Catholic position, but it's unfortunate that it happened because no doubt there will be plenty who take what she said at face value and never hear the correction.

I must say I was very surprised. I mean, most politicians who identify themselves as Catholic at least have some integrity to dodge the issue by saying that their personal opinion should not be their public policy, which of course is deeply questionable in itself, but to outright contradict one of the most well-established Catholic doctrines--established in one of the earliest Christian documents we have and held since--and say it is an okay position for a purported "ardent, practicing Catholic" to hold is just plain wrong.

It may be challenging to argue against abortion without reference to Divine revelation, but it's just plain easy to do with it. I mean, come on.

Cooper's Keynote at Agile 2008

Sat, 16 Aug 2008 18:45:23 GMT

I just ran across Alan Cooper's keynote at Agile 2008. The gist is that he's making the case for integrating interaction design into Agile development, something that is near and dear to me, as well. I was pleasantly surprised by his talk, and I recommend it to all my dev friends.

You can quickly scan through the slides and his notes to get the whole story. I'm not sure if I could have said it better myself!

Get My UX On!

Sat, 09 Aug 2008 02:36:18 GMT

I'm heading out to San Francisco Monday to get my UX on at UX Week 2008! It's my first time both in the city and at that conference. Looking forward to meeting new folks and talking about making great software experiences. If you're in the area or at the conference, send me an email (ambrogio[at]gmail) or ping me on crowdvine. I'd be glad to get together to talk about UX, software, architecture, whatever!

Wrox Silverlight 2 Programmer's Reference Early Access

Tue, 29 Jul 2008 18:35:41 GMT

Wrox has started a new thing as of late they're calling Wrox First. It's essentially a wiki of the book that I and my fellow Silverlight 2 authors are working on--Silverlight 2 Programmer's Reference. Not only do you get early access, you can also shape how the book develops by making comments and suggestions. My understanding is that it's just $19.99 and will get you access to drafts, revisions, and the final chapters as they are in the book for up to a year after publishing.

Seems like an interesting option for those who want the book and sample code now rather than waiting until later this year when it is published. Let me know what you think!

Podder Skinning Contest Extended

Wed, 02 Jul 2008 13:39:04 GMT

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!

Minimizing Email Distractions

Fri, 20 Jun 2008 21:28:31 GMT

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.

Procrastination is...

Thu, 12 Jun 2008 13:38:08 GMT

Thanks to Mark Hurst over at Good Experience for blogging this one. I thoroughly enjoyed it. My favorite: "Procrastination is playing imaginary computer games with your furniture." I laughed out loud in public..

Now I'm going to try my first embed; let me know if there are problems.

OpenSocial - The OpenID for Social Networks?

Thu, 15 May 2008 17:02:49 GMT

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

We Don't Need No Architects--Really!

Wed, 23 Apr 2008 19:15:42 GMT

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

Radical Freedom and Lasting Happiness

Sun, 20 Apr 2008 22:24:28 GMT

I was just reading the sermon Pope Benedict gave today in the Bronx. The following struck a cord:

The Gospel teaches us that true freedom, the freedom of the children of God, is found only in the self-surrender which is part of the mystery of love. Only by losing ourselves, the Lord tells us, do we truly find ourselves (cf. Lk 17:33). True freedom blossoms when we turn away from the burden of sin, which clouds our perceptions and weakens our resolve, and find the source of our ultimate happiness in him who is infinite love, infinite freedom, infinite life. "In his will is our peace."

Real freedom, then, is God’s gracious gift, the fruit of conversion to his truth, the truth which makes us free (cf. Jn 8:32). And this freedom in truth brings in its wake a new and liberating way of seeing reality. When we put on "the mind of Christ" (cf. Phil 2:5), new horizons open before us!

I've thought about this seeming paradox on a few occasions--that real, radical freedom is found in truth and living in conformity to that truth.

Loss of Freedom?
There's a common perception that morals, ethics, and religion in general limit our freedom--that we're sacrificing freedom for some greater good. But we're not actually sacrificing freedom--we're still free to choose to think and act otherwise, however, we are using our freedom, choosing to live in accord with what we believe to be true. It's a different way to think about it, one that puts it in the right perspective. I think it is put in a negative perspective so often because we focus on the things we're not supposed to think or do instead of on what we are freely choosing--positively--to think and do.

The funny thing that I've found is that in choosing to align my beliefs and actions with Catholic doctrine, I feel far more at peace and far freer. I think it is because if we're constantly struggling with the basic (but important!) questions of life, such as our origins, the existence of God and our relationship to the Divine, as well as our right relations with others, we never get off the ground, so to speak--we're always stuck in an infinite loop, wondering and (maybe) worrying, if we are conscientious.

But if we settle all that, we're free to move on and explore new horizons. Not only that, I think we are better equipped to explore those new horizons, because we are aligned with truth, with reality.

Mental & Conceptual Models
This reminds me of the idea in psychology of mental models and conceptual models. My understanding, based on Donald Norman's The Design of Everyday Things (a.k.a., The Psychology of Everyday Things), is essentially that there is a conceptual model that designers create and use when they design and build things. This is the actual and correct model. Then there are mental models that users of the design form and use when perceiving and interacting with the design.

The trick in design is to sufficiently express the conceptual model (through a variety of design mechanisms like affordances, feedback, "knowledge in the world," etc.) so that users will form the correct mental model--one that closely aligns with the design's conceptual model. The reason this is important is that it empowers the users to use the design effectively and not spend undue time and energy trying to figure it out, dealing with frustrations and inefficiencies that come from having a wrong mental model. You could say that having the right mental model makes the users more peaceful and more free to explore other things because they don't have the frustrations and aren't wasting unnecessary time on it.

Applied Mental Models for Freedom and Happiness
Now map that to how we think and act as human beings. Imagine that there is a correct conceptual model that specifies how best we human beings can think, act, and relate to others. This model can be discovered through a variety of the Designer's mechanisms such as nature (e.g., affordances in biology), reason, experimentation (use & feedback both personal, scientific, and historical/anecdotal), and even revelation (documentation, as it were). Now if we form the correct mental model, one that most closely aligns with the human conceptual model, it follows that we'll be more at peace (less frustrated), more efficient, more effective, and freer to explore other things. In short, having the right mental model would give us the most radical freedom and happiness.

Wouldn't we be crazy not to use the human design in accordance with the right mental model, once we figure it out? I think so. For instance, once we figure out that our door key is inserted into the key slot in a particular way that gets us through the door in the least amount of time, we'd be silly--bordering on insane--to keep trying to use the key in ways that don't match that mental model. We'd be wasting time, getting frustrated, and getting stuck outside!

No, once we discover the right mental model, the only sane thing to do is to keep using it unless someone comes along and demonstrates a model that seems to work better. Doing this--adhering to this mental model--is not "blind faith," as many liken the faith of Christians (and others) to be. On the contrary, adhering to a mental model that seems right to you is pure sanity, absolute reason; doing anything else would be idiocy of the first degree.

Sharing Your Mental Model - The Right Thing to Do
It also follows that if you see someone standing outside a door, fumbling with a key, unable to figure out how to use it, that what else could you do but walk over, show, and explain the right mental model--the one that you've found is the most effective and least frustrating? Would it be kind of you to just say "well, whatever that person believes is fine for them" and just leave them stuck and frustrated? (I'd suggest not.)

So it is with those who share their faith, their mental model about life, the universe, and everything. They think they've found the right mental model, the one that is most aligned with the ultimate human conceptual model, the one that if applied will provide the most peace, satisfaction, and happiness. It is an act of kindness, an act of caring, indeed an act of love, to take the trouble to share such a mental model with others. Correspondingly, it would be an act of meanness, selfishness, even perhaps of hatred, to not share it and try to help others to understand and use it.

So to those who think having faith is ignorant, blind adherence and loss of freedom, I'd suggest they reconsider. Using the analogy illumined here, it seems clear that such faith is actually the opposite--it is wide-eyed, reasoned, experiential, and ultimately more radically free and more likely to provide lasting happiness (which is a goal I think any sane human being can agree upon, no?).

Similarly, perhaps the most popular philosophical adage of our age--"what you believe is okay for you and what I believe is okay for me"--is not in actuality the most humane, reasoned, or livable approach. On the contrary, it seems far more humane--even positively caring--to try to show each other why we think we have the right mental model. It's something to consider, anyways.

DeveloperDeveloperDeveloper Ireland

Tue, 15 Apr 2008 21:13:13 GMT

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!

Creating Software is Not Like Building

Tue, 15 Apr 2008 08:04:01 GMT

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.

Just Do It! or: How I Learned to Stop Worrying and Love the Job

Sat, 12 Apr 2008 20:06:39 GMT

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'sDesign of Everyday Things. Christopher Alexander also discusses a similar principle in The Timeless Way of Building.