The High Price of Contradiction

One cool factoid I picked up from my philosophy of religion lectures:

I'm used to formal logic being very picky about finding contradictions in starting assumptions. However, I didn't realize how important it was. According to the formal rules of logic, if two contradictory premises are allowed in an arguement ("P" and "Not P"), then all possible conclusions can be shown to be true. A single contradiction can thus completely invalidate everything that follows, not because it fails to make sense but because it makes exactly whatever sense we want it to make.

It almost seems unfair, like the Devil has the deck stacked against us. A single error can spawn an infinite number of lies.

Top 10 Signs You're in a WTF Company

The Daily WTF website celebrates (or should I say reviles) "curious perversions in information technology". They recently launched a new service offering job postings to save people in WTF-prone companies with new jobs in (hopefully) WTF-free organizations. I am extremely grateful that I have had few personal encounters with such incompentence on such a grand scale . . . but I have seen a few.

So here it is:

Top 10 Signs You're in a WTF Company:

1. Months of work by the marketing department gets proactively wiped out by an IT deparment trying to "clean up the servers." None of the data is backed up.
2. When asked if the users call them much with issues, the IT staffer says brightly, "No, they don't ever call us unless the servers go down. They call us a lot about that."
3. When asked if the IT staff should be called to help resolve an issue, the end user snaps, "Don't you ever let them touch my computer!"
4. FoxPro 2 applications are still in production.
5. The IT department's testing server, where they try out new stuff, has SQL Server 7.0 installed.
6. Power in half the building goes out due to a cable being cut by construction crews. The switch is fried and most users cannot access the network. Surprisingly, nobody is yelling, screaming, or even laughing.
7. An intercom announcement says, "The network is back up. Repeat: the network is back up." A user turns to his computer, tries to log in. The network is not back up. The user does not yell, scream, laugh, or even cry. There is no expression at all on her face, except maybe a distant look of sadness.
8. When told that the network is still not back up, the IT manager says, "No, it IS back up!" and walks away.
9. When asked about any particular IT system, the end users say, "Well, that's the way it was when I first started here X years ago."
10. The IT manager gets irritated because the consultant keeps asking so many questions.

Holiday Letter

2006 was our first full year here in our new home outside Hillsborough. Slowly we're starting to make it look like a real home: blinds, drapes, pictures on the walls. The whole family made a heroic road trip to IKEA in Washington DC to come back with new cabinets, beds, and chairs. (We actually got more items than the IKEA cash register could handle on one order. They should ring a bell or something when that happens.) Aidan got his own bunkbed for his room, which have a special allure for any five-year-old boy, combining "secret cave" and "mountaintop" in one cozy, private place. We're starting to forget what it was like to live anywhere else.

Aidan started kindergarten this fall at Emerson Waldorf School. The transition was surprisingly smooth. He mellowed out considerably since preschool, when he was literally roaring and clawing the air at other kids. Now he has, like, real friends, and he (mostly) looks forward to school. But he knows the difference between weekdays and weekends, and prefers the latter, which is a certain loss of innocence. The Waldorf curriculum is heavy on handcrafts, which Aidan has taken to with fiendish intensity, splitting his time between modelling in beeswax and doing finger-knitting and making pom-poms (think Koosh balls made of yarn). He inhaled the entire Little House series of books (twice), as well as the complete collection of Mrs. Piggle-Wiggle. He is enormous and has way more energy and intellect than his personality can keep up with.

While Aidan is in school, Janet is mostly working on the Emerson Waldorf campus. What started as a small project to coordinate volunteers for a painting job has turned into an intense three-month-long campaign to finish a new nursery building on campus, painting and sanding and staining her way into the upper echelons of the school community. Now people barely recognize her when she's not wearing ratty work-clothes. And all this while doing PR work for the school, and still running her Attachment Parenting group in Orange County. She recovers from work with heavy doses of Ashtanga yoga and mojitos on mom's-night-out.

Malcolm works with his mother on the job site, getting his boots caked in so much mud he can barely walk. Mostly he enjoys it, and I think his penchant for trains and trucks can be attributed to his time in a construction zone. But he's moving into the tantrum zone of development, too, and his usually sweet disposition can be punctuated with Jerry Springer-like heaving of chairs and banging of heads. He recovers by cooking at his own play stove, and taking naps, and doing whatever his brother happens to be doing, whether it's a good idea or not.

Georg still works with Relevant Automation as a software consultant, mostly at home and sometimes on the road. Work is somewhat more demanding, since the company has doubled its employees and brought in lots of new technology. But work is also a lot nicer now that he has the "corner office," with a beautiful view of trees and kids playing in the back yard. Georg has a blog (abandontext.blogspot.com) where he posts daily, nurturing the hope that he might yet find a career in writing and teaching. Certain the pace has picked up with the Self Knowledge Symposium, where Georg continues to teach at UNC, NCSU, and Duke.

We are a little older, a little wiser, and still very grateful for all the blessings of this life, and wishing you the same.

Hope left for Western philosophy

This lecture series on the philosophy of religion is redeeming formal academic philosophy for me. Just on the drive down to Charlotte and back, I picked up four or five really solid ideas that bear more scrutiny. It gives me hope that maybe there is a place for me in academic thought after all.

One of the things that James Hall mentioned in passing was, "There are very few scholars who are both good philosophers and good theologians. Usually they are either strong theologians with only a rudimentary grasp of philosophy, or they are solid philosophers with only a dim understanding of what it means to see the world religiously."

Something about that rang inside me. I immediately thought, "I could be both." That might even define what it was that Augie saw in my Kierkegaard paper -- the ability to bring a genuine spiritual perspective to an otherwise impossibly tangled philosophy. And that might even be a calling worth the trouble -- to redeem thinking for those who believe in more than thought.

Some areas that might be worth a deeper look:

• The logical realm of philosophy seems to have a very hard time with paradox. "P" and "Not P" do not mix without violent explosions of nonsense in the logician's world . . . but it would be good to provide a framework to address paradox sensibly, recognizing the possibility of paradoxical truth without surrendering to complete nonsense.
• Intuiting premises. Rational philosophy freely concedes that all conclusions are dependant on the premises from which one starts. But I've read very little about the actual process by which one evaluates premises. It seems that this is the realm where immediate knowledge is not only possible, but absolutely necessary.
• Applied leaps of faith. What are the principles, if any, that guide us in action when we don't know everything? What's the right way of acknowledging intuition while still testing it?

That's _Lord_ God to you, buddy

I've been gulping down large sections of a "philosophy of religion" taped lecture series, and I've been enjoying it very much. The course focuses on the philosophical questions of ethical monotheism, i.e. "Is there a God?"

I'm no stranger to many of the arguments for the existence of God, but one thing that surprised me was the fact that we had to go back and define what, exactly, we meant by God. It only shows how emeshed I am in the culture that it didn't occur to me at first that it needed to be defined. Moreover, some aspects of the definition surprised me. You would expect God to be perfect: omniscient, omnipotent, omnipresent, and of infinite goodness. But tack on to that one more property: God must be deserving of worship, or else he doesn't deserve to be called God. And that struck me as well -- "God" as we typically understand the word is a title, not merely a person. I can almost imagine the personals listing: "Seeking: Deity. Must be all-seeing, all-knowing, infinitely loving, and deserving of wonder and awe. No smokers."

My IT Philosophy

I recently referred to "my IT philosophy," and I was slightly surprised that I did have a philosophy about this job, one that had evolved over time and had some unifying principles. Some of this is received wisdom, but most of it comes from my own experience. I imagine there are writers about patterns and anti-patterns who have better articulations of essentially identical ideas, but these are how I've thought about them in my own work:

1. Serve the business need first. IT staffers are sometimes so emeshed in their technical challenges that they forget that their mission is to solve business problems, not to merely build or maintain systems. When evaluating priorities or weighing possible solutions, an IT manager should always ask: "What's the business need, and how can respond to that need as quickly and effectively as possible?" For instance, if a salesman can't get an order processed on the last day of the month, a typical IT guy might just treat it like any other issue and tell them to wait for the technical issue to be fixed. A superior IT guy would address the business need first ("here's how we can manually by-pass the bug for this one issue") and then fix the system later.
2. Sales uber alles. Every IT guy has more issues pending than time to address them . . . which means they have to make decisions about which issues to address immediately and which to let burn. The typical IT person will address issues in the order they were received, or worse, reverse order in which they were received. Others categorically ignore everything and only pay attention to the squeakiest wheels. But ideally, issues should be addressed according to a hierarchy of how they impact the business. I work according to the following hierarchy: executive-level issues, then sales-related issues, then customer support-related issues, and then everyone else. Executives are first in line for purely political reasons: you don't get to keep your job unless the top brass are kept happy. But after that, sales is the number one priority. If an issue is keeping a salesman from selling, or keeping him from closing a particular deal, that's top priority. This reflects my overall business philosophy: I believe the most successful organizations are those that are sales-focused and sales-driven.
3. Start with the user in mind. Every aspect of application development should begin with the user. Requirements should be gathered first from the users themselves. Specifications should always flow from use-cases first, and then into underlying technology. Actual development should alway start with the user interface and then implement the actual business logic. All this flows from the first principle: stay focused on the business need, as it is experienced by the users.
4. Gather requirements from all levels. Nobody has the entire picture when it comes to a significant application. The mangers might think they know everything that needs to be known about what an app needs to do, but they often miss important details that are obvious to people working in the trenches. Likewise, end users may know what's important for day-to-day operations but be myopic about long-term issues. When gathering requirements for an application, talk to everyone involved if at all possible.
5. Be agnostic on technology. All that matters is that the solution works and is maintainable. If the solution works, and works soon enough to meet the business need, all kinds of other flaws can be overlooked. A solution might be ugly, use old technology, be less-than-ideal, or just plain un-hip, but the boss's boss won't care if the business need is met. It's amazing how many techies get stuck on trying to find the perfect solution while the world is burning.
6. Design for the long run, but implement for the smallest measurable change. A staggering number of IT projects never get completed, usually because the business needs change before the development could be completed. To avoid making perfect and irrelevant software, you need to always err on the side of making the scope smaller. Don't overbuild. Do exactly what is absolutely necessary to meet the business need, and no more. If the app proves to be effective and important, you will get a chance to build it out some more and add features.
7. Understand your issues (or be doomed to repeat them). This is probably the only exception to the "meet the business need first" principle. It is entirely possible that "try rebooting your computer" will solve the immediate problem, but that's not a satisfactory level of support. You have to make every reasonable effort to really understand what's going wrong, or issues will linger, multiply, and resurface at every turn.