My entry for the latest Silverlight code contest has been posted over on SilverlightShow.Net.  Go and check it out!

I had to comment on the latest Hanselminutes podcast.  I would absolutely love to do an article in the same style as AGT, but building up a Document instead.  I have not written a document/text editor from scratch so I would be starting from zero knowledge, but it sure sounds like fun.

There's at least 10 more AGT articles to go, so don't hold your breath.

"Everyone wants to save the planet, but no one wants to help mom do the dishes"

-Unknown

We are increasing the failure rate of projects and decreasing quality of- and relevance of- software projects in America by the way we treat our top performers.

I have written in the past about what I feel is one of the greatest sicknesses in Corporate America - namely that businesses have an impendence mismatch between that which will actually help the organization meet its goals and that behavior which finds itself rewarded in the same organization.  I haven't always put it so gently.

The Corporate Ladder, and the drive to climb it,  is having a negative impact the profession of Software Architect.  The Software Architect is in some ways falling victim to what I call Fry Cook Syndrome.  In my late teens and early 20s, I was a fantastic burger flipper and all around food production prodigy.  A point comes when the owner/manager can no longer justify further rewards to a lowly burger flipper and so I was promoted to Supervisor.  The problem was, although I could make delicious burgers and a beautiful sundae I was not in possession of any leadership abilities.  Sure, working hard and leading by example is a step in the right direction, but it won't turn a sarcastic college kid into a good leader.  Furthermore, the business had lost a top producer in the attempt to reward him.

While I joke about Fry Cook Syndrome all the time this article isn't about Architects getting into something they aren't suited for.  This is about the how the organization recognizes and rewards Producers.  We have some groundwork to lay down before we tackle the core issue: Titles, Perspectives, and Recent History.

Title Wars

I once worked at a consulting company where for a long time we were able to pretty much choose our own titles.  This led to one person calling themselves "Senior Internet Architect".  Not to be outdone, the next person crowned themselves "Principal Architect", while a "Chief Enterprise Architect" won the day.  I have even heard of someone who calls themselves a Galactic Architect; presumably the architectural needs of the Galaxy trump those of the mere Enterprise.  Attaching nonsensical names to ourselves as part of an effort to be "More Architect-y" than the next Architect is clearly a sign of cultural sickness.

Perspective

I was recently operating under the ostentatious title of Director of Solution Strategy.  In a way, I'm at a crossroads where my current position would lead easily into a more management or Enterprise centric role on one hand and back into more solution architecture and technical leadership on the other.  One thing that has repeatedly spilled out as I have meetings with interested parties is that I need to ship systems  right now and I don't want to get further from directly solving problems.  There is a process of turning requirements into code and fully participating in it means getting your hands dirty.

I was once working with a most excellent architect.  He understood his particular business, was a great abstract thinker, could write code as good as anyone's, but he felt he had an issue with how he and his group were fitting into the organization.  The high level architects, he claimed, needed to get away from "shepherding projects".  I never forgot this statement for two reasons.  For one, I thought that "shepherding projects" was a good way to put the leadership responsibilities of a good architect.  For two, I thought "Well, what else should your team be doing day-in, day-out?"  When did it become taboo for technical people with Computer Science degrees to write code?

In other words, who's going to help with the dishes?

The Evolution of the Architect in Corporate America

As of the time of this writing I've been programming in The Real World for about ten years.  While I cannot personally say this with any degree of certainty, I see enough anecdotal evidence from talking to More Experienced folks that there was a time when the average software developer was more technical; back when there was a Computer Science degree but not an Information Systems degree, perhaps; back when everyone looking for programming work had done their share of pointer math and taken a compilers class or studied the Unix source code.  As more and more businesses discovered the benefits of software systems, the demand for software developers grew faster than the supply.  The supply did not show signs of increasing at a satisfactory rate for two reasons.  The first reason was that a career in Computer Science or any core Engineering discipline was even less sexy in the recent past than today.  It just does not attract people in large numbers and the culture seems to be especially abysmal at attracting women.  The second reason is that compared to many other things Computer Science is hard for a lot of people.  Hard coursework weeded out a percentage of the people who were otherwise interested in being a software developer.

While an answer to the first problem seems to require a massive cultural shift and may only take time, businesses and colleges conspired to create a partial solution to the latter issue.  The Information Systems degree and its derivatives were born.  In these degrees the math component was toned down a bit - most of the businesses did not require programmers with hard core knowledge of Calculus.  The programming was toned down - you might still take C++ classes and write data structures from scratch but you wouldn't be studying compilers or Unix source code.  Businesses soon began to write real systems in higher level languages, so soon C/C++ was considered optional as well. 

Some people come out of these programs and thrive, some people demonstrate a career-long lack of polish stemming from lack of a true Computer Science background.  Only some parts of a system really required this training - Parts like the high-level technical vision for large systems.  The Architect of a system came to be known as the smartest guy in the room, needed to keep the simple proletariat developer in line...

The Problem

I assert that for various reasons there are not enough high level technical people focusing on Solution Delivery because everyone wants to be An Architect who doesn't get their hands dirty in the lowly tasks of writing code or requirements.  When I talk about people involved in Solution Delivery I mean the people who create the architecture for a solution, implement some of the use cases or modules, help other developers get things done.  I'm talking about the people who go to requirements meetings to help the business, and come back to find a line of people looking for code-level help waiting at their workstation/cubicle/office.  These people might be discussing the impact of frameworks on their project with the Galactic level Architects.  These people are on the conference calls with partners.  These people are often considered to have the best estimates, the most accurate perspective, the people you go to if you want to know how the project is really doing.

Companies large and small need people who can help get things done.  As Joel recently wrote, this can often mean that writing code is the most valuable activity.

This might be a good time to re-read Philip Greenspun's ancient wisdom.   A good software developer is often ten times more productive than a mediocre one.  A good software developer who is capable of higher-order abstract thinking, with some leadership abilities, who is not oblivious to organizational politics will often rise to the level of Some Kind of Architect.  Some times this is good, other times the company has just pulled a Fry Cook Operation and in the process hurt themselves and the entire profession.

Businesses are using career path and compensation to incent people to endeavor to become higher and higher level architects and avoid writing code.

Geek Culture is subsequently being transformed in such a way that the title of Architect is becoming more about prestige and pay grade than about one's duties.  I've even seen people declare that they "Architected the HTML and JavaScript for these pages...".  Is that their way of saying "I am awesome at HTML and JavaScript", or a way to declare that they are not "just a mere programmer" ?  I wonder.

The problem is that businesses don't understand the value of writing good code, the true value.  The developers with a proper mindset of Software Engineering and Craftsmanship may very well be providing their highest value possible to a business when they are turning requirements into code.  Too many managers view writing code as a low-value task, something that's just a stepping stone on the way on the way to something bigger.  This ultimately leads to a culture where writing code becomes a "guilty pleasure".  The organization goes about systematically promoting the best developers and the organization suffers for it.  "What can I do?", a manager might wonder, "I can only pay a software developer $75,000 but the pay scale for Enterprise Architect goes up to $125,000."

Nonsensical constructs like this will quickly motivate people to do anything to attach the word "Architect", or "Architected" to themselves or their work.  As Phil so rightly observed, great developers can often implement large systems or tremendous modules entirely on their own, but the organization fails to recognize this as an extremely valuable talent that ought to be rewarded.

Call to Action

None of this is to say that we don't need great Software Architects.  Hell, I (like everyone else) consider myself a great Architect/Application Designer and sometimes those skills are just what's needed.  Businesses big and small need to stop considering writing code a low-value activity.  Software Developers need to have soft skills just like everyone else today.  We need to recognize the value of great developers, we need to recognize that highly skilled developers with human skills who can also quickly turn requirements into code should be rewarded in proportion to the value they deliver and not because of an ostentatious title.  We need to remember that it takes True Craftsmen to deliver great systems and that Craftsmen should not be second class citizens.  We need to be sure that people can be successful without needing the title of Principal Inter-Galactic Senior Integration Architect.

Now, if you'll pardon me, I have some UML diagrams to finish.

I was recently interviewed for The Thirsty Developer podcast.  We talked a bit about home audio but the main conversation dealt with AGT, Silverlight, and the topic of visual tools in general. 

The next AGT article should be out this weekend or next week.

I wanted to write up some thoughts based on attending yesterday's MSDN Dev Con in Chicago.  Since I knew this was coming, I purposely did not do much reading about the technologies announced at PDC.  This was my first exposure to these items. 

Keynote: Ron Jacobs's keynote was of course the typical "Lots of cool stuff you can't have yet".  I'm interested in Windows 7, I'm one of the folks who actually really likes Vista.  While I had hear about VS 2010 being rewritten in WPF this was the first time I had actually seen it, in this case showing some kind of comment view provider.  This will be huge.

A lap around Oslo: I've been following Dan Rigsby's blog for a while and I got a chance to meet him before the show. 

Here's what I learned from his talk: Oslo is the capital of Norway, and Microsoft wants to buy it.

Just kidding, Dan!

Now that I have a super-basic understanding of Oslo I have a couple of concerns.  The first regards Dan's comment about creating a DSL that some kind of business user could use to create functionality.  It is my firm belief that this won't happen in the next ten years, not because it's technically infeasible, but because Business Analysts, Managers, and the like do not want direct responsibility for systems.  They like a nice, thick neck to get their hands around if something goes wrong and by that I mean us Technical folks can always be blamed for any shortcomings in the implementation of any Grand Vision.  Maybe I'm pessimistic, but I cannot imagine this direct accountability happening any time soon.

My second concern is a smaller technical issue.  Dan showed an example of a DSL specific to WCF services.  This seemed well enough for expressing WCF specific ideas (endpoints, URL patterns, etc.) but I wonder if there is or will be a mechanism for using generic code from another CLR language.  For example, I may have a business logic or data access component already written in C#, and my WCF service is just a thin layer on top of it to expose it as a service.  Enquiring minds want to know.

Business Apps in Silverlight: I heard before the conference that this talk would involve a brief look at some new features in Silverlight 3 so I had to check it out.

The future stuff was billed as ideas taken from the Artist Formerly Known as Alexandria.  Overall, I'm sorry to say I was disappointed in what I saw and here's why:

• A demo was shown whereby a server side business operation exposed via WPF was automatically linked to a generated Silverlight class in the client.  This was nice, since I have nothing but issues with the automatically generated endpoint configuration for WCF <--> Silverlight.
• Data Source: MSFT is bringing the notion of an ASP.Net Data Source into Silverlight/XAML.  All in all, I wasn't sure I liked the magical nature of this, but it's optional.
• Navigation: my ears perked up when the speakers said they were going to bring a notion of Navigation into Silverlight.  My problem with what was shown was that it was NOT NavigationWindow and Page, but something new: Frame and so forth.  Why not use WPF concepts?  I have heard many times that the intention is to bring more parity between Silverlight and WPF.  The ability to deep-link to the application using the URL query string is good at least.
• An ASP.Net-ish Login control was shown as well as some declarative security you can place on functionality.  It wasn't clear if this would ONLY work with ASP.Net Membership and Role providers on the server, or if the client side mechanism would be extensible via a provider model as well.

Overall, I'd like to see Silverlight going in more of a WPF direction than an ASP.Net direction and I'm worried about what I'm seeing.  The vibe I got from this talk was that Silverlight is going to "Work real well with ASP.Net" or "Something you can do instead of Web Pages, if you want".  There was no mention of bringing Commanding or other awesome (fundamental) WPF features into Silverlight.  I hope that I'm wrong.

F#: I first looked at F# something like two years ago and got frustrated and dropped it.  Having done some functional style stuff in C# and LINQ of late, I've been meaning to pick it up.  Aaron Erickson gets big points from me for using the term "Hand Waving".  His presentation, however, I felt wasn't basic enough for an intro to F#.  If the goal was to tell the audience why they might want to look into F# then mission accomplished.  If his goal was to show us how to do some basic things, not so much.  What do the |> or -> operators mean in F#, things like that.  By this time of the day, my 100% lack of sleep the night before was seriously weighing on me, so these things may have actually been explained.

I do plan on getting the book he described as the Most Basic learning F# book he showed, if I can remember what it was called.

After the conference several of us went to Fogo de Chao where I had a tremendous amount of excellent meats with bell peppers and some Malbec.

The AGT (Argentum Tela) series of articles is an effort to do two things. Usually an idea is presented only in its finished form. The first goal is to do some Reality Blogging, to show an idea evolve over time without pulling any punches. The second goal, and the example vehicle for the evolution aspect, is an extensible Design Surface for Silverlight similar to what we have in Visual Studio 2008. This type of application has all sorts of interesting uses. My example is a Home Theater layout tool. Read the entire saga: http://www.damonpayne.com/2008/09/14/RunTimeIsDesignTimeForAGT0.aspx

Gestures, Commands, Transactions, and Undo

There's so many sexy things coming up, it was difficult to postpone them further.  There's two more important categories of plumbing that needed to be built.  We'll cover the design of one category and its pieces in this article followed by two dedicated implementation articles.  The other functionality, Document Types and Serialization, will be next.

I would like to be able to use the keyboard for some gestures on the design surface: for example the arrow keys should move the selection and I should be able to delete items from the surface with the delete or use CTRL-Z for undo.

Additionally, I would like to support some kind of undo.  The plumbing needed for undo will allow for other cool interactions later...

Implementing Undo using Transactions and Commands

Undo can be an incredibly hairy thing.  In my opinion, going back to a working system and suddenly trying to add undo can be a very good test of how well designed the system is.  Those following along should take careful note of the degree to which the changes we see are additive (feels like we're just adding another feature) versus things that are refactoring (changing code that was already working to support this new feature).

Now to reveal a personal bias: I seldom find a use for "Redo" as it is sometimes implemented.  For example in MS-Word you can apply some formatting to text.  You can then use "redo" to apply the same formatting to some other text.  I'm really only interested in in redo as an Undo-for-Undo. So Move something, undo, no wait I really wanted to do that, redo.

This is something that's important to get right so let's list the primary goals:

1. The changes made to items on the surface are easily captured to be undone or redone.  This should be true for both surface interactions and property editing.
2. The number of undo levels should not be artificially limited. In some cases an undo won't "work" because the state of the system has changed -  we don't want Units of Undo to have to know about other Units of Undo.
3. There should be a centralized means of manipulating, creating, or querying currently known Units of Undo.
4. Interactions should be able to be grouped together where it makes sense to do so.  For example, moving an IDesignableControl around on the surface may in fact be 200 small changes, but we really only care about the starting position and the final position when the move interaction is over.

Item #4 in particular is important to me.  Visual Studio sometimes has some odd behaviors where what is perceived as a single Gesture by the user actually requires several Undo operations to erase.  For example, I might paste some code in or use a shortcut Chord and the first undo changes the formatting of the created code and the second undo actually gets rid of the code.

Gestures and Commands

Would it be best to try to mimic the Commanding system from WPF, even partially?  I debated this point long and hard: is it worth some research, some effort, some potential confusion due to subtle differences?

I played around on several different occasions and I did come up with some things that I liked better than the other "Commanding in Silverlight" code I've seen out there but for now I didn't want to use it.  Specifically, the ability to map keyboard gestures to a command from XAML was problematic.  Still, Silverlight does contain the ICommand interface, and I tend to like the Command Pattern for encapsulating units of work, so by this time I had most of a design in mind:

Controls that need to affect the change of something living on the Design Surface will go through some kind of Change Service.  This is similar, but not exactly like, how Visual Studio does this today.  Using this design I will allow interested parties to be privy to (but not cancel) all the changes going on in case this is needed for some custom logic.  The IDesignerChangeService will also be the gateway to creating and undoing transactions.  This bears some disucssion.

The IDesignerTransactionService and IDesignerChangeService are both public and overridable or replaceable, but they work in tandem.  In any circumstance I can immediately think of, client code will want to deal strictly with the change service.  The process will look like this:

Note that it will be up to the Client who is initiating the change to determine if gestures need to be grouped together into a transaction or not.  No one else would know!  We'll explore more about how we accomplish this in the forthcoming implementation article.  The stimuli shown here are not going to map directly to real method calls, but this gives you a good idea of what's going to happen as objects are edited.

I do like the way WPF creates some ways of specifying commonly used UI commands.  I can also see how the ability to customize the mapping from gestures to specific ICommand implementations would be useful.  Towards these goals, I am going to build some infrastructure modeled after what's in WPF.

These classes all exist in WPF.  My goal here is that I will mimic the WPF functionality as closely as possible and provide a public interface to InputBindingCollection.  With this, an application that wishes to customize the keyboard behavior of the design surface can simply replace the default ICommand for a gesture.

AGContrib

Over the course of the AGT project and several other efforts, I've written (or at least started) some useful things for Silverlight that may have usefulness beyond the AGT effort.  I'm going to be moving these things into a new project: DamonPayne.AGContrib.  For the sake of my time, this will be a part of the AGT solution for now, until I get time to move it into it's own CodePlex project.

The first denizen of the AGContrib project will be the Input Binding framework as shown above.

I should most likely move some other handy code from the DamonPayne.AG.IoC project into AGContrib as well.  When I get some more time in the coming weeks, I will also be evaluating Unity 1.2 for Silverlight, possibly deprecating my own custom container in favor of it.

Conclusion and Next Steps

It's been a while since I've done an AGT article that's entirely design without code.  I'm trying to keep the articles reasonably bite-sized.  I've checked in the most recent design documents, CodePlex change set 10098.  In the next article I'll implement the all the undo functionality.

Key Democrats criticized President-elect Obama's economic stimulus plan today.  John Kerry called it "A return to trickledown economics."  This development is fascinating for a number of reasons.

First and maybe least important - the unified Democratic party, the combination of Congressional seats, State Governors, and the Executive office all under Democratic control so feared by the Republicans doesn't appear very unified after all.  The infighting has started before inauguration.

Second, and slightly more interesting, is the fact that these particular tax cuts and so forth are absolutely not the platform that Obama ran on.  Is he and out-and-out liar, or is he only now recognizing certain aspects of reality regarding the true costs of big government programs?

Third, we must thoughtfully consider John Kerry's use of trickledown economics as a bad word in the context of recent history.

I won't (yet) try to argue that Trickledown, or Reaganomics, or Supply-side economics is the best system for raising the standards of living of the entire nation.  For now let's just examine the popular opinion as to the results of Reaganonmics.  It was called Voodoo Economics.  It has been claimed that it didn't work, that it could never work, that it was a laughable disaster.  Walking down the street, one would be hard-pressed to find someone who thinks of Supply Side Economics in a positive context.

Now let's just break this theory and it's opponent down into simple bite-sized notions.  Supply Side Economics states just what its name implies: that the economy does best over all by encouraging Production through whatever means.  Typically more freedom and less taxes is considered to be means of encouraging Production of goods and services.  Damon opens a factory in order to produce Glow in the Dark Towels.  The opening and operation of this factory including borrowing money, dealing with suppliers, marketing and advertising firms, hiring workers, buying land, contracting with builders, and so forth, will be a positive impact on voluntary business dealings between individuals.

In the other corner we have the Keynesian view, the view that Consumption and not Production is the best driver of the economy.  This encouragement to spend boils down to market distortions and wealth redistribution, but these are not bad as far as the pro-Keynes camp is concerned.  If the masses are unable or unwilling to consume, then the government must step in for them: spending everything it has and then borrowing more and printing money to keep on spending.    If the government can spend enough, we can float across tough times until individuals are willing to start spending again.  There are a lot more middle class spenders than factory owners, the thinking goes, and together their habits represent a much stronger force on the economy.  For now leave be the question of what the government should spend this funny money on.

Now we come to my point.  The original pre-crisis Obama plans involved some tax increases on the wealthy and a great deal of government spending on "building of infrastructure and green jobs".  Obama supporters praised these ideas, and the irony seems to have been lost on nearly everyone.

The notion of creating jobs and increasing prosperity by building infrastructure and creating goods and services is a Supply Side concept.  Contrast this with the idea of just giving every middle class American $1,000 on the condition that they spend it.  The idea that Production, not Consumption, will rescue the economy, is stolen directly from the so-called conservative side of the fence.  Why is Production the answer when the government is the producer, but not when private owners are the producers?  The answer is simple: because the Profit Motive has been removed.  The ethics of altruism tell us that it's moral to open factories and produce energy "for the benefit of everyone" but a private business engaging in the exact same activities and competing with others for profit is immoral, barely to be tolerated by a "progressive" state.

Obama has gone from government spending on infrastructure, which appears to me to be a smoke and mirror operation to reap the benefits of supply side production without calling it such, to an even more blatant supply side tactic: namely lowering taxes across the board and even on the wealthy. 

Whatever else he may be, Obama appears to me to be an intelligent and educated man.  He knows that big government welfare state policies can only be afforded by a wealthy nation and only then to the degree that they do not make the creation of wealth too difficult, too inconvenient, too undesirable.  At some point, he knows, the disincentive to produce is too great and the lifestyle enjoyed by Soviet Russia is the result.  He recognizes that when the chips are down, when there's no more wealth to "share", when printing even more money can't work, that only one thing will work.  He looks at American history and economic reality and sees that only by giving the freedom to engage in production and trade can creativity and hard work be unleashed, wealth quickly created.  Only by lengthening the leash given to this nation of smart and hard-working Americans will people take responsibility for their own actions and ultimately create enough wealth he can use to accomplish his redistribution goals later.

Obama supporters thought he would be a great redistributor, cashing in on our general prosperity in the 1980s and 1990s.  The .com bust, the Federal Reserve, and George Bush have beaten him to the trough though. 

It must trouble them to see him backing off his altruistic plans, but reality is the final arbiter in any clash of ideals.

Next week, January 13th, is the MSDN Dev Con in Chicago.  I will be going, as will some other Milwaukee area folks.  I am looking into the parking situation and organizing a carpool, but I am also organizing a trip to Fogo de Chao afterwards.  I'll probably be taking the car seats out of the DamonMobile and driving, so leave me a comment or an email if you'd like a ride.

I'll be bouncing around, not sticking to any particular track, and doing some socializing since I know some of the speakers. 

So here I am in 2009 starting off the year horribly sick and unemployed in a terrible economy.  Still, I have very high hopes that I can make some good things happen for me and my family this year.

Last year I posted some goals, and I only hit 40% of them.  This year the 2009 goals are much more personal and private.  Still, it's pretty interesting looking at the posts from January 2008 to see how myself and the world have changed in a year.  Here are some thoughts on year old topics:

Warner Goes Blu-Ray exclusive:  Even a broken clock is right sometimes, and I'm still glad BD won the day.  A year later, HD optical media is still where I said it would be; the infrastructure is not there yet for downloads to rule the universe.  Since I will most likely end 2009 with 1.5mb DSL (come on, U-verse...) I don't see this changing in 2009.

Program Control: Man, I continue to be somewhat disappointed in the entire Windows Mobile/Compact Framework universe.  I will not shed a tear if I never do mobile development again.  I have a post coming out regarding what I think (whatever that's worth) MSFT could do to use its strengths to Win in the post iPhone world.

Task Parallel Library: I went on do do a LOT more parallel programming in 2008, my favorite being getting xUnit.Net to run my unit tests in parallel.  I have a lot more stuff coming this year, including a re-working of the tree-based scheme.

New Office: Hard to believe, but Wednesday was my last day in the aforementioned new office.

I think 2009 is going to be a great year.  I don't think it's too pessimistic to think that in terms of the economy there are areas where we might not have hit bottom yet, but in general I think America is still free enough to pull ourselves out of this.  A lot of people are excited about the new president, who seems to be settling into Reality and his economic team has promised to lower taxes across the board which is what we need; definitely not the platform he was elected on though.  Markets are driven heavily by Expectations, and a lot of folks expect great things from this guy, so at the least I'm glad to see some positive energy out there.