mt open source

YAY!

Movable type is now officially, truly open source!

I have been using movable type for (/me goes to check my earliest entries) the beginning of 2003. In that time i have watched the application grow from a simple, beautifully constructed perl application to a beautifully constructed perl based publishing platform. I have a (sorely under-maintained) plugin - MTRecentImages and have set up blogs for family and friends.

Now that the release has been open sourced i am getting ready to roll it out to our many-hundred engineer team at work with some customizations to integrate into our environment better.

Congrats to the MT team for a continually improving product and platform and for keeping the platform open for all of us.

trying out the new umbrella with my flash

trying out the new umbrella with my flash, originally uploaded by plural.

i started getting back into the craft of photography recently. This is my first good shot with a little umbrella i picked up on friday. Nothing spectacular, but enough to get started wtih.

DDJ Architecture & Design World: Randy Miller's "Agile Architecture"

Randy (Granville) Miller is an architect for Microsoft. He has a Microsoft blog. Last week i attended his session, "Agile Architecture" at the Dr. Dobb's Architecture and Design World Conference.

His talk started with a quick overview of agile and its benefits. As a side note, i was amazed at how much of that talk was happening at the conference. I assumed (there i go again) that it was so prevalent now that it was roughly a given. Apparently i assumed incorrectly.

After that was out of the way he talked for a bit about the place of architecture in agile methods and the disconnect between engineering practices and an entire business process or system. He used a quote from Kent Beck that is really spot-on:

> My bias in writing XP originally was towards the
> programmers. Thats my background. Thats
> who I identified with on teams. However, the
> past five years have taught me that software
> development cant be the programmers and a
> bunch of other people?if the goal is excellence.
> Without balance between the concerns of
> everyone involved, some people will be unable
> to contribute to development, and their views are
> important to the teams success.

My team's nearly 2 year experience with Scrum has certainly proven this out. In fact, Scrum's biggest benefits have materialized in communications and project management benefits over strict engineering benefits. While combining multiple roles on a single team is a fundamental agile tenet, the role of Architect is not often discussed and less so in an Agile Context. XP, Enterprise Scrum and Microsoft's MSF stuff were mentioned as methodologies that discuss the architect and architecture. The notion that architecture was unnecessary in an agile project was brought up as a fundamental myth about agile practices. After nods all around, he made his first suggestion: build stories to verify the architecture in a deployed sense, not on paper. For a client server application, build the client and the server with a really simple interface or a stub, but make it real. Put it in your environment and let it run. The appeal of making a design tangible is pretty interesting, even if it gets difficult for a lot of cases.

The rest of his presentation focused on the concepts of shadows. Working or existing code can cast what he called "Trailing Shadows". Reverse engineering databases into ER diagrams, java code into UML diagrams, etc. In my team, this has been incredibly valuable. It is a common sense task to take stock of what you have and document it, but i really like the term Trailing Shadows as an indicator of architecture. The mixture of a legacy code base and an expanding engineering team makes that particularly necessary for my team.

On the flip side of that, he talked about "Leading Shadows" from a design. Our leading shadows could come from whiteboard sketches, notebook pages, quick visio diagrams, etc. He stressed that these shadows should turn into working code within an iteration and not devolve into Big Design Up Front. Following on this discussion, he stressed building scaffolding for these sketches, writing tests for them and getting them into your continuous integration environment. A chart from his presentation shows the ideal progression of leading and trailing shadows over the course of a project.



As part of a retrospective after an iteration, review the shadows, suggested Miller. If you have leading shadows still, you need more development. If you have trailing shadows, then you are done with this architectural change.

The final interesting part of the talk was a focus on the inverse relationship between project size and the length of iterations/integrations. He gave an anecdote about the size of the team for the last Visual Studio release (~4-500 developers) and the 2 month iteration size. They found that they spent a ton of time doing integration testing and conflict resolution. This seems like a no-brainer, but is often hard to put into practice.

The shadow architecture concept is part of the Microsoft System Foundation for Agile Software Development. On that basis, i am going to do a little reading on that system. I don't develop for windows or use Visual Studio, so we'll see what is applicable.

Miller's talk was one of my favorites at the conference and helped me get some perspective on the "What is my sprint to sprint role as an architect?" question. His speaking style was great, the presentation flowed well between his material and the audience questions.

Juliana on Same Title Different Story

Chris has been running a site called Same Title Different Story for a while now. The mix of styles and stories has been pretty cool to listen to. For his third story, "Electric Current", he asked Juliana to contribute a story. After a little talk about what the title meant and what her story could be, Juliana wrote a second Super Cat adventure. I helped her clean up her sentences a little bit (basic stuff, not content) and we recorded the story on my macbook.

Check out her story and let me know what you think!

Same Title Different Story

Dr. Dobb's Architecture and Design World

I spent most of last week at Dr. Dobb's Architecture and Design World in Chicago. While the name caused some of my colleagues to snicker, the conference had a great schedule, so i signed up.

Before i talk about any specific talks, i have a few comments on the conference itself.

* The food and drinks could have been much better. Coffee was scarce and competition for a cup fierce. The boxed lunches got old quickly and there was no breakfast served, despite 8:30 start times for 3 of the 4 days.
* Many talks needed a quick test before attendees were allowed to ask a question. Too many questions in talks with the word "agile" in the title either complained that agile was too hard for their app/company because of INSERT REASON HERE.
* Much of the talk was about finding a place for Architecture in a process that is often interpreted as meaning, "Look ahead only 1 or 2 iterations. As long as we do test driven development, a quality product and architecture will emerge." Various speakers and attendees addressed this differently, but the conversation was very interesting.

I left the conference with several pages of notes to work through from many great talks. Here are just a couple of notes.

* My favorite practical talk was Neal Ford's "Building DSLs in Static and Dynamic Languages" (download Neal's slides (pdf). Neal walked through some background on DSLs and then took 3 approaches to building one: building fluent interfaces (think method chaining) in Java, a Groovy example that cleaned up the java syntax and finally a Ruby DSL. He stressed knowing the syntax you want to be able to write and building towards that. Neal was a fantastic speaker and the session was a lot of fun.
* Scott Ambler's keynote "Evolving Agile: Time to Address the Uncomfortable Issues Wed Prefer to Avoid" focused on the results of a recent Dr. Dobb's survey on agile methodologies. An interesting takeaway from his talk was the prevalence of modeling practices (from whiteboard to formal tool) in teams reporting successful agile projects. Scott focused on simple techniques and a sort of just in time modeling done at the beginning of an iteration for a limited scope.
* Randy Miller from Microsoft gave a great talk entitled "Agile Architecture" and focused on guiding teams towards an architecture without resorting to big design up front. Modeling was a key technique he used, but as with Ambler's talk, common sense was the main rule. Model what you need to model to show what you have and where you are going based on what you know now. He also told an interesting anecdote about the last Visual Studio release. They had 4-500 developers working on 2 month iterations that resulted in a ton of time spent dealing with integration. The newest release that is in progress has apparently moved to shorter iterations.

I will be presenting some of my notes and thoughts to some of my coworkers in the next couple of weeks, so i will post some more info about specific topics and presentations over the next few days.