Wrap up from Ann Arbor Day of .NET

I am just now recovering from a great tip up to AA. The event went very well, and the organizers did a great job. It is really cool to see leaders from five different user groups get together to put on such a smoothly run event.

The speakers and content they lined up were just great. I ended up in the big amphitheatre room again, as the last session of the day, just like last year. But I am not complaining. I actually like that. It allows me to tie some of the things I have seen during the day together, and weave them into my talk.

I spoke on ‘How to be an architect.’ This was the first instance of this talk, and I think, with that being said, it went pretty well. I definitely found ways to smooth the delivery, and increase the connectedness of some of the value flow. I will work to make these improvements before the next time I deliver it.

I have posted the slides here, if you are interested.

I do want to follow up on some of the questions that were asked.

0. Someone asked, if you wear many hats at work (architect, developer, support guy, etc.), where can you find the time to do the continuous learning. I responded that you should just get a divorce. This actually showed up on Twitter, and I want to make it clear.

I was JUST KIDDING.

Here are some thoughts though:

a. Learning IS part of your job as a dev or an architect. So set aside an hour or two a week to do just that.

b. Keep a stack of trade magazines next to your desk, and read them during the fragments of free time we have scattered throughout the day. For example, while you are waiting for your machine to boot, or for something to download.

c. Don’t forget to ‘Eat like a bird.’

d. Keep magazines and books in the office bathroom.

e. Learn to scan headlines, and speed read. I can read a whole magazine in minutes by doing this. Also keep in mind that most journalists follow a standard pattern to their writing. The article usually has three parts: Summarize what you are going to say (this pulls you in), provide the details, and then close with summarizing what you said. When I am skimming, I just read the headline, and the first ‘part.’ I only read the detail section if the article is very germane or interesting.

1. I was describing what some of the concerns an architect should have. Someone then piped up and asked why I hadn’t mentioned ‘design.’ I immediately responded that Information and UX architecture are important too. In hindsight, the person might have been asking about the technical design that some architects do. It is an old notion that the architect on a project provides all or most of the detailed technical design. This is ok, if that is how your organization works, but I try not to play that role. As an architect, I try to layout the high level concepts of the design. This is the outline that the details will fit in. Then I work with the developers to define the detailed technical design as needed.

This accomplishes several things. First, it fits in really well in in agile process. Second, it moves some of the design to some often underused assets, your developers. They know how to write this code, and they know the frameworks very well. Let them help you define these details. They can bring that experience, while you represent the higher level concerns (business, user, project needs, etc.). This also answers another common concern of developers, in that they want to be more involved in the design, and have impact on what they are building.

I want to thank all of the people that came out. See you next time.