Brain of Brandon

Some New Books

brandon — 2008-03-27T21:13:46-06:00

As many of my friends and family know, I have a bit of a problem. When it comes to my appetite for books, my eyes are a bit bigger than my stomach, so to speak. Considering that I'm currently in the middle of a handful of books, I may have gotten a little carried away with my last visit to Amazon.com. I frequently get questions about what I read and where I get most of the data that I ramble about regarding software, business, and other matters that are pontification friendly. In addition to 'blogs and websites, the good old-fashioned codex still plays a major part in my knowledge intake. So for anyone interested, and because I still have that freshly-opened-Amazon-box excitement, here is a rundown of my newest shelfware.

It is interesting to watch your professional interests change over time. I was chatting with a colleague this evening and he remarked "I'm really surprised at how I'm so less in "bits and bolts" of languages compared to a few years ago… the key is really about the people and the how they do it… not so much what they do it with..." I agree and have observed the same shift in my own interests. Out of the above ten books only one is related to technology (the Groovy language). Of course, to be fair, in the last year I have also picked up some Ruby, Lisp, JSF, Hibernate, and data warehousing books. So I guess I haven't really slowed my technical subject matter intake as much as increased the non-technical subject matter. Nevertheless, a few years ago you wouldn't have caught me reading The Fifth Discipline or a book on Multisourcing.

These Guys Get It - Web 2.0: Tripit

brandon — 2008-02-06T20:43:07-06:00

Use Tripit to zap together a master travel itinerary, share it with others, and keep up with friends on the road.

I recently became aware of Tripit through an endorsement from Joel Spolsky. The timing could not have been better as I was right in the middle of scheduling a business trip and was, yet again, frustrated with the waste (Muda) imposed upon me (the traveler) by the various institutions along the value stream.

Womack and Jones, in the book Lean Thinking, highlight the travel industry as a specific example of a value stream that is overflowing with waste and subsequently ignoring what is truly valuable to a traveler. While Tripit isn't directly banishing the wastes of waiting and hand-offs that plague the travel industry, it is definitely producing a platform for emergence of new value to the hurried (and typically stressed) traveler.

Making Life Easier: You simply forward all your various email itinerary confirmations to plans@tripit.com. Because it understands all the significant and popular air, hotel, and vehicle rental email formats, it will parse everything you send and shove it into one visually pleasing and printer friendly master itinerary. You do not even have to register.
A Friend's Advice: After flattening your various booking confirmation emails into a single itinerary, Tripit will add some helpful information. Who would not want the weather forecast for their destinations, as well as the ever-more-endearing Google maps with driving directions?
Telling Those Who Care: Now that you have a succinct message about your upcoming journey, Tripit makes it easy to share the details with anyone you think needs to know (E.g. family, friends, colleagues, etc.).
Crossing Paths: Beyond publishing your travel plans to those who need to know, Tripit has turned the social-networking knob up to eleven. You can easily tap your address-book du jour and invite contacts to your Tripit network. I pulled from my Linked-in contacts as I travel primarily for business purposes and am always interested in catching up with my like-minded colleagues on the road. Now I can see upcoming trips of those in my network and when we will be crossing ways. Tripit calls this feature "See Who's Close."
Reusing over Reinventing: The icing on the cake is that Tripit will export your travel itinerary to an iCal formatted feed that can be consumed by such scheduling mainstays as Outlook or Google Calendar.

If you travel more than once in a blue moon you should give Tripit a spin. It might help you remember to bring an umbrella, or it might help you remember to bring an umbrella for a friend that will be crossing your path!

These Guys Get It - Web 2.0: MindMeister

brandon — 2008-02-05T22:03:39-06:00

MindMeister: Mind Mapping, Brain Storming, Collaboration, and Publication

I recently was looking for an online mind mapping tool that would allow me to create/update mind maps online and keep them in a centralized location. I really like Freemind but I'm fairly anti-desktop software these days as I find myself frequently switching between my work laptop, home laptop, and various other workstations. Being the raving Google fan that I am, I would have preferred if there were a mind-map option in Google docs, but alas not yet.

After the obligatory Google search for such tools, I had a handful to investigate further. I tried the first three I found; Bubbl.us, MindMeister, and MindDomo. Something about the Mindomo sign-up screen put me off, if felt too 2002. I immediately was pleased with the user-interface of bubbl.us but the feature set left me underwhelmed. Then I tried MindMeister and within minutes I was impressed several times over.

Reusing over Reinventing: MindMeister allowed me to immediately and simply upload existing Freemind mind-maps that I had already created. I wasn't even looking for this but what a great feature if you're transitioning from Freemind! As well as providing the ability to import Freemind maps, MindMeister used the same keyboard shortcuts for building and navigating the map online. This is a great example of the software designers focusing on perceived integrity and conceptual integrity as explained by the Poppendiecks in Lean Software Development.
Collaboration: MindMeister has tapped the cask of fine social-networking wine and it tastes oh so nice. Within a few minutes I was able to invite a few friends to collaborate with me on a mind-map and I could see their changes as they were brainstorming with me.
Publication: Mind mapping is a communication tool to express relationships and spawn new ideas in the same manner that the neural network of our brain operates. As such it needs to be seen to be valuable. MindMeister allows you to easily publish your mind-maps as links or embedded frames on your website. Of course you can always export and print as well!

If you would like to see an example of the publishing capability, I have started a page on Complex Adaptive Systems which displays a MindMeister mind map I'm using while I research the topic.

Try mind mapping, it can be both fun and productive. Better yet, try it with some friends on MindMeister!

Markets of Increasing Returns Demand Adaptation

brandon — 2008-02-05T21:02:50-06:00

Few would disagree with the statement that technology has changed how people, and the businesses they run, interact. Technological advancements such as solid-state transistors, personal computers, and distributed networks like the internet have not only effected new human behaviors but accelerated the rate of change for such behaviors. W. Brian Arthur, in the article “Increasing Returns and the New World of Business,” contends that to understand how to make business thrive in such an accelerating environment, we must understand the dynamics of knowledge-based markets (100). Leaders in knowledge-based markets of increasing returns must abandon optimization philosophies and harness the effects of adaptation.

The concept of diminishing returns in markets of bulk processing is well researched and accepted by the business world. Markets of diminishing returns are characterized by an equilibrium that is typically reached between supply and demand. This equilibrium ultimately causes profit margins to shrink for suppliers and gives the market a more stable, if not predictable, nature. In contrast with markets of diminishing returns, markets of increasing returns are non-linear in nature. Increasing returns are realized in industries that focus, not on bulk-processing of resources or manufacturing, but rather of turning knowledge into something valuable to the consumer. Increasing returns amplify success or failure through network effects, time to market, and heavy up-front costs (Arthur 100-102).

The rapidly changing software development industry is an excellent example of why it is necessary to prefer adaptation over optimization. The industry is plagued with failed projects run by leaders who are nestled in a false sense of security by optimization processes that worked in a bulk-processing industry. Highsmith, a known thought-leader in the industry, helps project leaders understand that centralized processes which are fine-tuned for efficiency in a repetitive bulk-processing environment, are not capable of supporting the high rate of change and uncertainty experienced when turning knowledge into executable software. Instead, Highsmith highlights the lessons that can be learned from biological organisms, specifically, how adaptation to external forces and early arrival to a solution is far more effective than trying to predict the future with deterministic cause-and-effect logic in a market that continually produces emergent behavior (9-13).

In software development I have experienced the horror of optimizing determinism and the pleasure of agile adaptation. One such deterministic project that was managed in large phases and specified in detail at the beginning of the project ran over twice as long as estimated and even more over budget. The project sponsors were continually disappointed as were the end-users while the project team experienced frustration and turn-over. In another project of equal team size and similar functional scope, project sponsors were impressed and end-users satisfied. This was achieved by adaptive techniques such as time-boxed iterations of work, frequently scheduled demonstrations to gain feedback from users, fifteen minute daily status meetings, and prioritizing the most important work at the beginning of each iteration. The adaptive team worked in time-boxes of three weeks so they could easily change direction in the next iteration when new requirements or information came to the fore.

Knowledge-based businesses, those that operate in markets of increasing-returns, are built by people who advance their technology and science. Harnessing adaptive concepts in these organizations accommodates several of what Cockburn calls "human failure modes" including making mistakes, inventing rather than researching, and being inconsistent (48). The business leaders that discern whether to apply deterministic processes or embrace adaptive practices will reap rewards in both markets of diminishing returns and in those of increasing returns.

Works Cited

Arthur, W. Brian. "Increasing Returns and the New World of Business." Harvard Business Review July-August 1996: 100-109.

Cockburn, Alistair. Agile Software Development. Boston: Pearson Education, Inc., 2002.

Highsmith, James A. III. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House Publishing Co., Inc., 2000.

OKCJUG Review: Build the Right System with Test Driven Requirements

brandon — 2008-01-09T21:25:32-06:00

Yesterday I enjoyed participating in the January OKC Java Users Group meeting. The presentation was delivered by Rod Coffin and Don McGreal. Their topic was on test driven requirements and lean pull applied to software development.

The question, which no doubt resonates with most professional software developers, was posed:

How can we as software professionals and craftsmen know that we are producing the most valuable system at just the right time for our users?

Rod and Don aimed to answer with:

The concept of "pull" from lean manufacturing, in combination with agile values and practices, provides a powerful guide for how we can improve our profession by allowing the incremental specification of functionality to "pull" the creation of working software.

The presentation was excellent, I think this material should be taught to all involved with creating software solutions. Don clearly explained the value proposition of Lean in the traditional terms of manufacturing and then he and Rod quickly transposed Lean principles to software development. After a foundational crash course in Lean, Rod and Don paired on a working demonstration of the concepts.

Role playing as a product owner, Don expressed some business needs and Rod made the promise to deliver. They then worked through creating a user story, followed by acceptance criteria (using green pepper), coding the spec (unit test), and making it turn from red to green.

Mingled throughout the primary theme of applying lean pull via test driven requirements, they managed to also demonstrate some behavior-driven development (BDD) techniques and an agile pair-programming game.

All in all it was really well done. The slide show reminded me of something Steve Jobs might use, limited verbiage, very to the point and excellent transition flare (it was on a MacBook Pro using Keynote).

Complex Adaptive Systems Theory, Lean and Scrum Origins

brandon — 2008-01-09T20:37:59-06:00

Over the last few months I have been reading Adaptive Software Development by Jim Highsmith. This particular book focuses on the application of Complex Adaptive Systems theory, or CAS, to the human side of software development. Foundational to the book is the idea that we fail to understand the sharp disparity between orderly systems and complex systems. An orderly system can be extremely complicated but that does not make it complex. Complicated problems can be solved with rigorous optimization whereas complex problems require not only new tools but a mindset of adaptation over optimization and arrival of the fittest over survival of the fittest.

Highsmith aims to help the software development community understand how to harness emergence. Emergence in complex adaptive systems describes a characteristic in which the interaction of the parts create some greater property or effect that cannot be explained or measured by the individual parts.

John H. Holland, a pioneer of CAS and father of genetic algorithms, defined CAS as:

"A dynamic network of many agents (which may represent cells, species, individuals, firms, nations) acting in parallel, constantly acting and reacting to what the other agents are doing. The control of a CAS tends to be highly dispersed and decentralized. If there is to be any coherent behavior in the system, it has to arise from competition and cooperation among the agents themselves. The overall behavior of the system is the result of a huge number of decisions made every moment by many individual agents."

When I see something described in terms such as "acting and reacting", "dispersed", "decentralized", "cooperation", and "huge number of decisions" I am immediately interested in the implications to organizational behavior and team dynamics. Complex adaptive systems are characterized by a high degree of adaptive capacity which in turn provides resilience to agitation, disruption, and change in environment. The application of CAS theory can be studied in a wide range of contexts as diverse as the stock market, ant colonies, human social groups, and cellular biology.

Jeff Sutherland, one of the founders of Scrum, recently posted on his Scrum blog about the background of Scrum and Lean. In this post he states that "the root of both Scrum and Lean is complex adaptive systems theory" and he goes on by saying "I think Scrum and Lean are complementary implementations of ways to deal with physical reality where things are often not linear, not simple, and not predictable." He underscores other Scrum ideas that fit right in to CAS, such as the idea of Sprints that evolve the code like a biological system. When enough mutation occurs in multiple parts of the organism then a shift occurs to a higher level of functionality. As well, he highlights the fact that management must release control of the team and let it function autonomously as a self-organizing entity that grows the system like a plant.

Along with CAS, Sutherland cites Goldratt's Theory of Constraints (TOC) and Brook's subsumption architecture as influencing the Scrum methodology. Lean has many roots from Deming's work in the early-mid twentieth century. Deming's focus on global optimization and quality control practices are well founded in CAS and constraint theory. Sutherland makes the point that Scrum is built to induce punctuated equilibrium and Highsmith underscores this idea in Adaptive Software Development that the "edge of chaos" is where emergence happens. The term "edge of chaos" describes the turbulent gray area between order and chaos. Dr. Sutherland also highlights that punctuated equilibrium is achieved in Lean through set-based engineering which allows for decisions to be made at the last responsible moment. This correlates with competition in biological environments through which the most adaptable species wins.

Rod Coffin recently blogged about the implications of a Lean decision making process. He highlighted the Toyota Product Development System (TPDS) and noted that although the Chief Engineer has ultimate responsibility for a product under development, he exercises subtle control by giving the individual teams great freedom to deliver at regular synchronization points. The team uses set-based engineering to aid in making decisions at the lowest possible level, with vision and arbitration left to the Chief Engineer. Rod also highlights Alistair Cockburn's observation that unverified decisions, those not incorporated into the system/product and accepted by customer/market, are in-process inventory and ultimately amount to waste in Lean thinking. Ultimately this approach to decision making, with it's potential impact to in-process inventory, can significantly impact throughput (cycle time to deliver new value).

In his post, Sutherland iterates "A thoughtful analysis of the relationship between complex adaptive systems and Lean will show that both Scrum and Lean are instantiations of complex adaptive systems theory… In Scrum, we introduce chaos into the development process and then use an empirical control harness to inspect and adapt a rapidly evolving system." He makes the point that CAS theory can be difficult for the masses to understand and therefore not a good motivator for implementing Scrum. Lean can be difficult to explain as well, however the success of organizations like Toyota provide the social proof to wake people up and make them listen. Ultimately Lean is just an extra teaching tool in terms of taking Scrum to the next level.

Rod asserts in the above mentioned blog entry that organizations which rely on top-down decision making process are introducing bottlenecks and subsequently disrupting flow and inhibiting collaboration and the self-transcendence of a team. I agree with that assessment and would add that those top-down organizational processes will ultimately lead to a complex system failing to adapt quickly enough and therefore losing out on the emergence that could come from the edge of chaos. Jeff Sutherland wraps up his respective blog entry by summarizing; Scrum is not a child of Lean, use Lean and Toyota to sell Scrum to management audiences, and Lean can be used to help teams understand where a Scrum implementation may be broken.

Java - An Open Platform of People

brandon — 2007-11-12T13:45:02-06:00

From a technologists perspective, I found it exciting to learn that the JSR proposal for adding closures to Java was formally submitted to the JCP on November 7 2007. I have been watching the closures debate for some time. After seeing Neil Gafter's talk on the proposal at JavaOne 2007, I have been a proponent of the addition to the Java language.

From an open source contributing/lean pull preaching/vendor lock avoiding/everybody play nice singing/tree hugging/apache t-shirt wearing/firefox hat sporting/java user group attending/wake up corporate America shouting :breath: perspective, I found it exciting to learn that the Closures for Java JSR has been jointly submitted from the Belgian and Brazilian Java Users Groups. This is a first for a JSR and will be the first Java language JSR led by individuals outside of Sun Microsystems. The BeJUG announced that the expert group will utilize a publicly-readable mailing list, thus keeping the spirit of openness alive. The fact that Sun will relinquish control as the JSR lead speaks volumes about the attitude and culture that Sun is trying to promote. It also serves as a testament to the power of change management models like the Java Community Process (JCP). I have observed in the past that Sun seemed very heavy handed in steering of JSR proposals; perhaps these recent events are evidence that the Sun culture continues to embrace change and openness.

http://www.javac.info/consensus-closures-jsr.html

http://gafter.blogspot.com/2007/04/consensus-closures-jsr-proposal.html

http://www.bejug.org/confluenceBeJUG/display/BEJUG06/Home

http://www.soujava.org.br/display/v/Inicial

Agility and Low Documentation Coupling

brandon — 2007-08-28T22:55:58-06:00

Agile developers strive to produce value through working software, which is widely agreed upon as the primary metric of productivity. The cycle time to produce a unit of working software, gain feedback from the user, inspect the results, and produce another unit of working software is what makes the agile developer tick. Agile teams love to write working software, but they do not love to write documentation. Documentation (of any sort), in my experience, is often deemed as something secondary that should only be moving the iteration of work towards producing another working unit of software. Business constituents love working software but they also love to communicate business processes effectively. Being guided by agile values and principles does not grant license to ignore all that is not source code.

It is important to note that there is a difference between business-centric documentation and technical documentation. Business users generally do not care about UML class diagrams but they do care about user stories or perhaps use cases described in textual and/or graphical formats. It is this type of documentation that any self-respecting agile developer should be happy to collaborate on with business users, as well as assist in evolving as shared understanding grows about the business process that is being supported through software. Artifacts such as use cases, user stories and business process maps, when kept alive, can be extremely helpful to any organization in terms of process improvement. When a developer needs to understand the intricacies of the system, well-crafted unit tests (preferably created through TDD) can serve as much better technical documentation than various UML diagrams.

The need for business-centric documentation is being championed by many through pragmatic tools such as FIT (http://fit.c2.com). An increasingly popular topic is that of "executable documentation" and how business requirements can be actively linked to working software. David Hussman has been doing a great job of preaching that sermon on the No Fluff Just Stuff tour (http://www.nofluffjuststuff.com/speaker_topic_view.jsp?topicId=534).

All this being said, I feel it is increasingly important to focus on reducing coupling between business documentation and technical documentation. If a technical change forces cascading changes through many uses cases or user stories then it is possible that these artifacts may be focusing on the wrong thing. If a change in business process causes inaccuracies in a multitude of technical UML diagrams then it could indicate that implementation (technical) documentation and abstract problem (business documentation) are tightly coupled.

Agile development should deliver working software that addresses the right problems as well as facilitate effective communication about those problems. When an agile team is asked to explain or improve the business processes and functions of their software they will be happy to have timely documentation to fuel that effort.

JBoss the Gestalt

brandon — 2007-08-15T22:39:48-06:00

I have not spent a lot of time around the JBoss community until recently. The last experience I had with JBoss was running the application server for home projects in 2002. In the last year however I have spent an increasing amount of time intersecting with JBoss related technologies. Of course a large part of that is due to the fact that so many standalone technologies are now under the JBoss umbrella. Working with Hibernate for example brings so many of us into the JBoss community and exposes us to other offerings that we otherwise may ignore.

From the perspective of working with "federated" technologies, I think JBoss (Red Hat) is performing an understated service for the global software development community. Recently I had the privilege of presenting on Drools, the open source Java rules engine at the Oklahoma City Java Users Group (OKCJUG). This project was pulled into the JBoss family back in 2005 and the progress of the team and maturity of the technology speaks to the effectiveness of the JBoss project support model.

On the other hand I've recently undergone the marketing spiel that is Red Hat sales and it feels an awful lot like you're buying a used car. Unless you happen to know that the majority of the various components of JBoss are other open source projects, you are left to assume that you are buying support for a big stack of purpose-built JBoss source code. JBoss Web… why not just call it Apache Tomcat? JBoss Operations Network… wouldn't it be more succinct to just say Hyperic. JBoss Rules… of course now they are back to calling it Drools. Aside from the JBoss MicroKernel and JMX MBean work, it seems most of the stack is "reused" from other open source projects. While I have no problem with this fact, I do find the marketing/sales approach a bit underhanded.

Is JBoss now providing a value proposition greater than the sum of it's individual projects and pieces? A gestalt it might just be, or perhaps Red Hat is just that good at making a buck off the good intentions of open source.

http://www.hyperic.com http://tomcat.apache.org http://labs.jboss.org/drools http://www.hibernate.org

No (ok maybe a little) Fluff Just Stuff 2007 in OKC

brandon — 2007-06-04T21:06:55-06:00

While it is all fresh in mind I figure I better jot down a few things from the super cool geek-fest that is NFJS. This was the first year that the software symposium has stopped in Oklahoma City. Apparently it was a success because Jay Zimmerman (founder of the event) committed to a 2008 stop as well. My company sent well over 50 people and even though they had to give up their weekend only a handful bailed early. It is a bit hard I must admit to not have any weekend at all. It might be nice if NFJS would start on a Thursday and end Saturday night that way people could have a day to recuperate before getting back to the grind.

These are the sessions that I attended...

Speaker	Session
Brian Slettin	Give it a REST
	I appreciated the demonstration of Restlets. Brian didn't mention JSR 311: "Java API for RESTful Web Services" so I asked if he thought Restlets would change significantly as that JSR progressed and he indicated so. Having seen the JSR 311 API demonstrated at JavaONE, I must say it looks far more promising. The creator of Restlets is on the JSR 311 expert group which I think could be another factor in Restlets changing. If you are interested in more info on JSR 311 check out Marc Hadley's blog at http://weblogs.java.net/blog/mhadley/archive/2007/02/jsr_311_java_ap.html.
Venkat Subramaniam	Domain Driven Design
	This was an enjoyable presentation but I felt only the last 30-45 minutes truly got into DDD. Venkat said something that struck me as profound although it seems like common sense after more reflection… "Object models are based on our perspective. When our perspective changes, the abstraction changes...". This presentation reminded me that I still need to read Eric Evan's book on DDD.
David Hussman	Executable Documentation
	I thought this was an excellent presentation in the agile space. I liked how David had the whole room participate. He focused on the "why" of executable documentation more than the "how," which was FIT. Executable documentation is living, proves what the product really does, and helps the team collaborate and communicate. We walked through creating some FIT tests for some example user stories and he also highlighted the "DoFixture" from FITLibrary as one of the most valuable all-purpose types of fixtures.
Glen Vanderburg	Everything Old is New Again
	Glen really knows his computer history, had some cool videos, and went WAY over on his time. If there was any fluff in the conference, I would say this was borderline. He did make a very powerful assertion though; we as software developers are not nearly as ambitious as in times past. By reflecting on historical achievements in science (computing specifically) we can be inspired to further innovation.
David Hussman	Coaching Agile Projects: Finding Your Groove
	David presented some very practical ways to assess teams that are trying to adopt Agile processes and practices. He also talked about transition planning, mapping a project community, specific practices of a Coach, and the idea of creating "Transition Tests." I really like this notion of transition tests because trying to discern how adoption is spreading in a large organization can be extremely difficult if left to simply asking project managers and supervisors "How are things going?".
Jared Richardson	Distributed Teams: Remote Agility
	I enjoyed the informal manner in which Jared presented this material. It was almost more of a group discussion or BOF than a presentation. He basically underscored that to be Agile with distributed teams you must focus on the values of the Agile manifesto. He especially highlighted the need for CI when using distributed teams as well as peer reviews and atomic check-ins. He also mentioned that remote pairing can be quite effective with Skype (audio only) and SubEthaEdit which is a VNC type sharing tool available on the Mac.
Venkat Subramaniam	get FIT
	An excellent technical demonstration of using FIT and FitNesse. After already attending David Hussman's presentation on "Executable Documentation" I was totally drinking the FIT kool-aid during this presentation. Venkat is very good at succinctly demonstrating technology and the value it can provide.
Ted Neward	The Busy Java Developer's Guide to Debugging and Monitoring
	Ted gave a broad view of the current free tools for debugging at the JVM level. He gave a very good explanation of how GC works including the various generations and how your application can affect them. He also gave some very good advice on building in diagnostic "sinks" into your applications from the very beginning. This was something that I had forgotten about and will likely add to the Reference Implementation (aka Reference Architecture) at my company. He gave the example of the log4j telnet appender as a simple but extremely powerful diagnostic sink (i.e. socket). I had completely forgotten that I had written something just like this back in 2001 to pipe System.out to a socket so that I could telnet to the port and watch diagnostic logs in real-time. I'm not so sure about telnet for that now, but the concept is great.
Pete Behrens	Agile Enterprise Architecture: The role of the architect
	This session was awesome. Of course it really hit home for me as I spend a lot of my time and thoughts on what exactly I'm supposed to be doing as an architect in a large, disparate organization that is chock full of functional silos. Pete says the enterprise architect is "a thought leader, visionary, and industry expert… in most companies this is a new role that combines the skills of project manager, solution architect, and business analyst with the intuition of an executive"… wow that is a mouthful. The industry expert part definitely stuck out to me as I know very little about my industry and domain (I've only been in it about a year). I have a goal to gain more business domain knowledge both of how my company does things as well as the industry. This was a huge help to me in my last life as an IT dude in the insurance industry. I think this also will aid in Domain Driven Design. Pete also contrasted the Zachman Framework and the Federal Enterprise Architecture model with what is needed for business agility. He very clearly made the argument that enterprise architecture is really based on the optimizing the organizational structure of your company. Pete brought up Conway's Law which states that organizations which design systems are constrained to produce designs which are copies of the communications structures of these organizations. I think about the long running projects at my company and it is amazing how true this is. The end game is disintegrate the organization, reduce roles, reduce communications paths, and saturate the communication paths that are left.
Venkat Subramaniam	Spring into Groovy
	I figured I should go to at least one dynamic language session so I picked this one and I am glad I did. Turns out that you can create Spring applications that update dynamically at runtime by utilizing the new dynamic language support in Spring 2.0. You can push out new versions of scripted beans while the application is running and it can pick them up and recompile them on the fly without disrupting any current user of the Spring bean. This is done because of the way Spring has implemented scripted bean support using proxies. Very very cool, lots of possibilities there. The demo was with Groovy but the same would hold true with JRuby or BeanShell.
Pete Behrens	Agile Tooling: Team to Enterprise
	A good overview of the tools in the agile project management space especially pertaining to Scrum, user story tracking, and burndown generation. ScrumWorks looks nice, but it still appears the lower tech you can keep the project management efforts the better off the team will be.
Pete Behrens	Agile Metrics and Measurements
	Another session that hit home as this is a hot topic around my IT organization. Pete summed up the danger of metrics by quoting Eli Goldratt (our lovable Theory of Constraints creator) "Tell me how you will measure me and I will tell you how I will behave." Pete highlighted that there is a difference between metrics and diagnostics and that the intent of measurements should be confirmed as either informational or motivational. Good metrics will allow for reflection (inspect) and foster improvement (adaptation). In the spirit of ToC and Lean he also pointed out that metrics should be kept simple, prove more valuable than the cost of gathering, and focus on the whole instead of local optimization. We really only have one metric if we are honest and that is business value. The reason we create software is to reduce operational expense or increase revenue opportunities (obviously this is only concerning commercial organizations). Everything else that doesn't quantify the business value is a diagnostic that measures how we are doing at creating value. He went on to talk about how value is perceived and how productivity is traditionally measured. The Israeli Air Force published a case study of measuring productivity based on "Running Tested Features" that was very compelling and immediately pointed more credibility to the idea of something like FIT. There was a lot of good insight in this presentation, I hope that I can remember enough as we move forward in implementing metrics in our IT organization.