QCon Day 5

As I had to fly back home on Friday afternoon, the report on Friday’s sessions is quite short. Although I wanted attend the planned Open Space on “Reflecting on your Agile journey – How do we reach Mastery?” led by Deborah Hardman and Diana Larsen, I just did not make it. This mainly, because in parallel there was still an Agile track going, with too much of good content. So I had to sacrifice something. 😦

I decided to hear what my friend Joseph Pelrine had to say about “When Agile Hits The Wall – Dealing with the organizational challanges of Agile adoption”. Joseph’s talk was video-taped, so I hope it will be available as Video-Stream somewhere from the conference website soon. At least they promised to make the material available.

In his entertaining and metaphorically rich manner Joseph showed why there are fundamental clashes in an organization, when some part of it (like a team) tries to adopt Agile values and practices. Sometimes all goes well within one team, but as soon as the team tries to reach outside its zone of influence things seldom work out as expected. Actually even resistence and suppression can be the response.

Joseph compared going to fast with Agile adoption with running downhill – if you let go, you accelerate and accelerate until you go to fast and stumble over your own feet – a nice metaphor. Your organization might well feel fear and threat and build “antibodies”.

So the first step for resolving anything is to know the problem space and to capture the force that are at work within the organisation. Usually there is a clash in the unterstanding of “cause and effect”. Often management and an Agile team live in two different worlds. Management often remains stuck in a Newtonian world view, while the Agile team embraces a Complexity Science based approach. These are not compatible with each other.

The Newtonian point of view is that cause and effect are directly linked and can be traced and linked together in advance and with some effort can lead to the predication how a system will behave in the future.

The Agile team instead operates in the Complex realm. In this quadrant there is no direct link between an effect and its cause(s) observable, let it be predictable. Instead things can be only judged in retrospect, knowing how things evolved (this is called “retrospective coherence”).

In this realm we can not know in advance what will influence our system and how the agents within the system will react. Such a system we usually find, where people are involved, because people do not act deterministically. To many factors to influence us.

This is also, as Joseph stated, why a simple Inspect -> Adapt loop does not work. Joseph pointed out, that we need first to act, before in a complex environment something happens and any inspection is possible. So he extended the loop to: Apply -> Inspect -> Adapt.

Technorati : QCon Conference Report Agile
Del.icio.us : QCon Conference Report Agile
Ice Rocket : QCon Conference Report Agile

QCon Day 4

We have arrived at the forth day of the QCon conference. Although today there is an Agile track, I will attend some of the more technical session, too.

Deborah Hartmann introduced the sessions and off we go. I will start with the session on “Grails” by Guillaume Laforge, the Groovy project manager and co-initiator of the framework, that tries to port ideas from Ruby on Rails to the world of the Groovy scripting language. A colleague of mine that is writing a book on Grails has recommended the session, so I will go and see what I get for my money. 😉

Grails = Spring + Hibernate re-invented

Here are the main messages of the presentation:

• Even simple things are quite painful to accomplish with Java frameworks (ORM persistence hard, numerous layers and config files lead to chaos, UI integration messy)
• Grails is an MVC action-based web framework
• Principles: Convention over Configuration (CoC), Don’t repeat yourself (DRY)
• Grails builds on proven components: Spring, Hibernate, Groovy, SiteMesh, AJAX

How Grails addresses pain points:

Pain Point 1: ORM persistence (many XML config files)

• Domain model based on POGO (Plain Old Groovy Objects)
• Relationships between POGO’s based on convention
• Grails generates (called scaffolding) view and controllers for you for a quick start
• By adding constraints to fields an easy way of validation for correct values is provided
• Write only your domain model objects and generate the rest
• Modify some GSP (like JSP) page (view) or some text and reload the page and you are done

Pain Point 2: Numerous config files and layers

• Most things work over conventions (dynamic finder-method construction, based on known fields)
• Reading over relations
• URL’s have easy, consisten mapping like ‘controller/action/id’
• Parameter passing thru easys maps
• Easy job scheduling using Quartz

Pain Point 3: Messy JSP-like pages

• Predefined Taglibs and Components
• Define own Taglibs

Sweet Spot: Enterprise-ready

• Existing Java libraries
• Employee skills & knowledge
• Spring configured beans
• Hibernate mappings for legacy schemas (but still benefit from dynamic finders)
• EJB3 annotated mapped beans
• JSPs, taglibs for the view
• Deploy to your pricey Java app-server & database
• Grails will fit in your J2EE enterprise architecture

Positive impressions about Grails (maybe to incorporate somewere else)

• Conventions over Configuration
• Extend that with metadata where needed
• Dynamic language, so short code-build-run cycle

Questions that remain

• How much logic goes into the GSP-pages?
• Taglibs, huhhh?
• Still generation needed? Why?

All in all an informative talk of Guillaume. Maybe I should try some first steps with Groovy (although its syntax does not appeal very much to me).

The afternoon starts with another scripting language: JRuby. I first wanted to attend the Test-Driven Development session of Steve Freeman, but during his introduction I noted it was too elementary for my knowledge, so I voted with my feet and went for the session about how to integrate Java and JRuby.

In contrast to the Groovy session, the JRuby session seamed quite low-level. No so much the content, but the form of presentation. The presenter (Rob Harrop) just started with the jirb (JRuby interpreter) in commandline manner. He type away quite fast, but after the code moved over the top of the screen, I think, nobody new anymore, what exactly he was doing (actually creating a small Swing application) directly in the interpreter.

So how does JRuby compare to Groovy/Grails. I am basing my lay judgement on few things I saw on the two sessions, so see this not as an expert talking.

Ruby integration into Java is not seamless. Instead you have to use special integration classes to bind it in. Groovy instead makes the use of Java objects a breeze. Java objects and Groovy objects can be used as if they were the same.

Ruby showed a strength in creating new domain specific languages (DSLs). From the point of view of a poor Java programmer JRuby feels very awkward and strange. Many things are not obvious, this is one of my main critique points. Explicitness ist often missing, like when you overload operators, etc.

A issue I find critical with JRuby and Groovy is the dynamic additon of an API (say methods, functionality) to ONE specific instance of a class. While this might be useful in some case, it can actually be nightmarish when it comes to read and understand code. It actually decouples classes from logic making it more difficult track down, where something happens at which point in time (without recurring to debugging).

The next session was “SEAM” presented by Gavin King. He started with the usual rant against Agile and Test-Driven Development (TDD), by saying you need nothing of this “crap”, just use Seam and you are up to a quick start with your web application.

Seam generates a skeleton for a web application inclusive some simple test code. You can modify the code of your application much like in Grails.

“We need no f*cking unit tests. Any one programmer can write those simple POJOs without error. The problems come, when you test a class together with its collaborators.”. So much about a professional attitude to testing.

Seam uses much XML configuration and is in that regard not better than Hibernate or Spring. Gavin admits, that he would prefer doing it in plain Java.

What Seam brings to the table:

• Single component model for JSF, ESB, EJB, etc.
• No actions
• Persistence: No DAOs, instead binds components that access database through JPA/Hibernate directly to the view
• After changing the DB structure, you need to restart the web server.

Seam incorporates the concepts of conversation based transaction. This a very valid approach to transaction handling in web applications. In fact we have incorporated something quite similar in our own framework.

The next session I attended swang back to Agile software development, when Jeff Sutherland, the co-inventor of Scrum, talked about “Agile Project Management: Lessons Learned at Google”. The room was crowded full, which nicely reflected the interest people had in Scrum. The voices I overheard at the conference showed clearly, that many people would like to try Agile, but feel very unsecure, what agile would bring them and how to start with it. Many doubt that it is worth the effort.

At Google the Adwords project is using Scrum, they have begun about a year ago in early 2006 to introduce individual Scrum practices, like a release backlog, into the company. Originally in 2001 Google decided, that they did not need any Managers, because they were not adding value to the company. So they eliminated all managment positions. So from that time on, projects evolved organically. When Google was growing bigger and the software (in case of Adword) increased in size (500’000 LOC and still growing fast), the project manager of that project saw the need for a little bit more structured approach, which would not destroy the organic nature of the current way to do things, as this was seen as a good thing.

Technorati : QCon Conference Agile Report Grails
Del.icio.us : QCon Conference Agile Report Grails
Ice Rocket : QCon Conference Agile Report Grails

QCon Day 3

This is the first real conference day, as the last two were mere tutorial days. So here small report one the day’s session from my perspective:

I opted for concentrating on architecture in the morning, after the keynote of Amazon’s CTO Werner Vogels, on how Amazon’s single web application (yes, the famous online book shop) evolved into a application development platform that Amazon now is opening and making available to the software development community.

What stood out of his talk? Four things:

• To scale: No direct access to the database anymore. Instead data access is encapsulated in services (code and data together), with a stable, public interface.
• To decouple: Services are aggregateable from other services or very “thin” web application, allowing to mesh different services together and leave out, what you do not need, so supporting many different applications and uses.
• One small team own a service in all its aspects. This has the advantage to make the team responsible for the functioning of the service and at the same time giving it the freedom to do whatever it takes to implement it and make it work.
• Scale later. It is soooo difficult to make it right, that sometimes the effort to do it up front is not justified. Or leave it to somebody, that has the knowhow and has done it already…like Amazon (remember S3 – Virtual Disk, etc.).

Then Kevlin Henney introduced as host the architecture track, talking about architecture quality attributes, something I need currently also look at.

The session of Martin Fowler talking about “Modifiability”. His approach to hold the session, made him even more sympathetic for me. He downplayed his role as Agile fore-thinker by taking a backseat during the session and let instead five of Thoughworks’ senior software designers (or architects, if you like) illustrate different ideas around evolutionary architecture.

More detailed notes on this will be published on these pages as soon as I have transcribed them.

In the afternoon I attended the “Performance & Scalability” talk of Cameron Purdy of Tangorsol. Besides that he put up just too many slide for a talk of one hour (more than 70) and his talking stile is somewhat monotonous, his talk was very information-rich. Especially I liked his list of architectural “Don’t’s”. Recognized several of them in our own architecture on the current project we are doing. We really have to throw out the legacy code, that is lurking in all corners of the current framework we are using.

In one point Cameron made somewhat contradictory statement in contrast to the keynote of Werner Vogels: Architect for performance and scalability up front, because it will cost you way too much to put it in at a later point in a project. So who is right? Well, when I try to consolidate those two talks overall message I come to this conclusion: Include thoughts on performance and scalability in your initial draft of your architecture, but be ready to revide it and to optimize it at a later point, when you know a.) more about the real requirement for your system, and b.) when you are able to see with your own eyes (or mesure), where the effective bottlenecks hide.

The next talk was again by Werner Vogels, about “Availability & Consistency”. A very interesting talk, that needs further digging, because there a lot of ideas essential to high end web applications. More on that in a later entry.

The last talk was by Peter Sommerlad on “Security Patterns”, based on his new volume of the famous POSA (Pattern-Oriented Software Architecture) books. Unfortunately he was not able to present the theme in an involving manner, that would spark more interest in the auditorium. Partly this can be traced to him not being a native English speaker, so he was sometimes having difficulty finding words and he often lost the flow that is so important to a talk. At the same time he bothered to explain far an long what patterns are and instead of analyzing thoroughly only two pattern (an easy one and a complicated one), he wanted to give an overview over the whole book. An impossible task to accomplish in one hour. Too bad. It seamed more like a sales pitch, than a session, people can actually take something away. I know he can do better, especially in German.

Technorati : QCon Conference Report
Del.icio.us : QCon Conference Report
Ice Rocket : QCon Conference Report

QCon Day 2

On the second day I participated in Kevlin Henney‘s “Hands-On Agile Development Workshop”. You may ask yourself, why as a proponent of Agile development and coming from a company, that tries to employ Agile practices across all its projects I attend such a newbie-event.

Well this is mainly for one reason: Part of my role at Löwenfels Partner is that of a Agile advocat or evangelist. The other part is to coach our teams in Agile practices and values, by leading through giving an example.

So my main interest in this session was to see how Kevlin presented the session. Some things I observed about his session:

What I liked:

• Organized Scrum-like in four Sprints
• Complex-enough problem to solve
• Sprint 0 used to introduce Agile concepts in a very fun and lightweight fashion.
• Sprint planning/commitment included
• Strong test-first approach thaught effectively
• Team collaboration stressed through pair-programming, changing pair, focus on clean interfaces for easier integration of team results
• Practical stories from real world projects mixed in
• No dogmatic propagation of Agile practices, but pushing common sense conclusions
• Real struggling with personality types (people you do not know) when pair-programming and cope with that diversity
• Introduction of kind of a metric for a good unit test: nearly non conditional logic in the test itself. This leads to more readable and understandable tests, that communicate well the intention of application unter test, a lot like a good a specification.
• Nearly as much test code as application code to be tested.
• “By omitting tests we will not be able to write the double quantity of code”.

What could be improved:

• Kevlin talked very much himself. I at least would have prefered more interaction

And the reaction of the attendants? Most of them were convinced to need to apply the trained practices in their organizations, some even against the current paradigma in their companies.

Would I recommend the workshop? Definitely! We should do something similar in our organisation (at least for new employees, if not all). I will try in the coming months to build on that.

Technorati : QCon Conference Agile Report
Del.icio.us : QCon Conference Agile Report
Ice Rocket : QCon Conference Agile Report

QCon Day 1

Monday was my first day at QCon 2007, the new over-spanning conference on software engineering. I attended a whole day tutorial given by Larry Constantine named “Usage-Centered Software Design: An Activity-Based Approach”.

This was to be a very interesting session, because I was very curious to see what Larry thought on the integration of interaction modeling into Agile software development processes. This is an interesting problem, because there are voices, that contend, that UI design is hard to implement in an Agile manner, because the UI designer needs to analyze the complete set of requirements to come up with a consistent UI, that supports all possible usage patterns the customer expects.

When following Larry’s explanations the problem interaction experts have with the Agile way to do things became apparent.

Larry advocates a usage-centered approach to UI design instead to a user-centered approach. The difference is, that usage-centered approach focuses on the work to do and to optimize that, instead to put the user primarily at ease and neglecting the efficient solution of the user’s problems at hand.

So his motto is: “Put good tools in the user’s hands, that he can creatively solve his daily work problems.”.

This I would say alines very well with the Agile approach to develop software, because we also focus on what problems the user wants to solve in a as easy way as possible.

One thought that alarmed me, was that Larry said: “I am the usablility expert, so I need to involve the user only a bit, so I know what he wants, but I decide, how he gets it.”. Sure, the UI designer knowledge is very important, but it should not remain – at least in Agile development – with the interaction designer. Every team member should have at least a basic knowledge of the field and should build up the rules and guildlines for the UI as it goes on with development, in an incremental and collaborative manner. Up front UI design should be very short and revised as the project goes on.

Technorati : QCon Conference Architecture Agile Report
Del.icio.us : QCon Conference Architecture Agile Report
Ice Rocket : QCon Conference Architecture Agile Report

On my way to the QCon Conference in London

I am sitting at Zurich Airport and waiting for my flight to London right now. I am attending the new QCon Conference there and am quite curious, how it will be like.

The roundup of speakers and tutorial hosts promises an information packed week. Besides quite an interesting Agile track, there are lots of sessions about technological themes that have caught my eye. After investing lots of my time recently in Agile processes and soft factors in the software engineering field, I feel it is time to go a bit back to my technical roots and have a look at architectural and “hype” themes this time.

Besides that I hope to meet many known faces, like Deborah Hartman, Joseph Pelrine, Peter Sommerlad, Steve Freeman and some other I got to know and appreciate in the past. But I am sure, there is also room to get to know some new and interesting people. And besides that London is always a place that never gets boring.

So stay tuned, as I will try to post some daily conference update on these pages.

Technorati : Agile, Conference, Java, QCon
Del.icio.us : Agile, Conference, Java, QCon
Ice Rocket : Agile, Conference, Java, QCon

Recruiting People With Agile Potential

We are currently in need of new developers and testers for our teams. As we try to live Scrum as an Agile development process I often ask myself, what kind of criteria we should expect of the candidates, besides the usual developer or tester skills.

Sure you can not see inside the cadidates’ mind. But more and more we try to ask Agile questions during the interview. Often I ask a question, that I hope will show the candidate’s attitude towards Agile practices and values and to see whether he would have the potential to lead other people by giving them a strong example.

One such question was recently: “The build fails. What will you do?”. The usual answer I get is: “I will fix the build.”. Then I add the tweak. “But, if your code did not break the build?”. Often people then revert back to the ‘I am not responsible for THIS!’ attitude, so they say “I wait till the build is fixed by the developer who broke it.”. The better one’s will propose: “I contact the developer that broke the build and we resolve the problem together as soon as possible.”. As I often see people not acting pro-actively, but in the ‘wait and see’ manner, I hope to get more people on board, that act on problems, instead of tending only their own garden.

Another question I recently asked a potential senior developer and team lead was: “Your team seams not to be able to deliver the functionality they commited to at the beginning of the sprint, because of quality problems. Your demo with the customer at the end of the sprint is to be compromised. What do you do?”. One answer to this question was: “I go to the customer and postpone the demo.”. Boing, a warning sign! Further questioning revealed, that this candidate did not even know what a commitment within an iteration was and how it worked.

Another small test I do with candidates is to refactor a piece of bad code with them in a pair programming fashion. I am not so much interested in solving the particular problem at hand, but in the way the person approaches the problem, how she thinks about the code and how she works herself through to understand it. Does she write a unit test first to frame the working code? Does she rename variables and classes to have a better grasp of what the code is doing?

To people previously not exposed to Agile development I first explain our development approach (Scrum) and then try to ask practical a question on consequences this has on the interaction between team members or between developers and the customer (product owner). Their answers usually reveal a good deal about themselves. How they think about the development process, what they would like to happen in a development process, etc. The additional question I then add is: “What would YOU do to improve the process?”. So I try to at least see how their attitude is concerning the development process. How do they want to live their lives as software developers? Do they think about improving something, they see, is going wrong?

What are your questions you come up with to check for job candidates’ compatibility with Agile values? Let me know about it.

Technorati : Agile Recruiting HRM Scrum
Del.icio.us : Agile Recruiting HRM Scrum