Crowd at Java Developer Day (JDD) in Krakow

Last Friday, I attended JDD in Krakow.
This was my first time at this conference and I my general impression is really positive. Good place, decent logistics, a lot of people (I believe that around 400 folks), good speakers. And of course a pack of beautiful Polish hostesses you will never see at conferences outside Poland.

Scott Davis' presentation about Groovy was good (charisma, great slides, real coding demo), but I found it too beginner-level. Hey, we really know what unit testing is and how to do it. You could have skipped almost entirely the first 20 minutes and start from more advanced topics.
Anyway I am somewhat sold to the idea of introducing Groovy as a testing platform (with production code remaining in Java). Especially the ability to examine private fields and generally far more compact language are tempting. Still, without good tooling (and generally Groove as weakly typed language will never have such refactoring support as Java has), I'd rather stay by Java in the production code.

Mark Richards' talk about messaging was really good too. Rather nothing new to me as seasoned guy in using JMS systems, but a lot of valuable advice for beginners or people astray. Especially the anti-pattern of using multiplexed single queue instead of several queues just do to communication/collaboration problems with admins makes me think... Mark highlighted well misconceptions around priority queues and work balancing.

The talks about jBPM was also interesting, but I did not like recorded movies instead of real-time demos. After all we are all developers, we know that Demo God may strike at any time.
Definitely jBPM is something I would take a closer look at, if I was about to decide which business process management platform to use.

I liked the talk about the exception handling by Tomasz Skutnik. Good speaker, a lot of real code samples (we love it), much valuable advice given from the person who seems to suffer a lot from screwed up exception handling in the production code.
I don't agree with every single rule provided by Tomasz (especially I don't like tagging with some magic string every single place the exception may be thrown - famous ORA XYZ, I am talking to you ;)). Still, he raised a lot of valid points about very popular mistakes made to exception handling in Java EE.

Waldemar Kot gave supposedly interesting talk about using concurrency in Jave EE application servers which generally do not like managed components to use any kind of extra threading. I learnt about Work Manager API and current problems related to including it in Jave EE spec.
I am sure this talk could have been better, if Waldek better managed his time. Fortunately I feel we get only to about 50% of the presentation, when we ran out of time.

I said JDD was good. Still there is always space for improvement. What could be better:

• more strict time-keeping. I had to start my session 10 minutes late, as I was waiting for my predecessor who had did not finish on time. Then I overran by 2 minutes, which means that I not only consumed the whole break, but also immediately delayed Scott Davis by several minutes. Sorry Scott! I wish there was some kind of bell or the organisers were gently interrupting talks at scheduled time.


• probably 3 or 4 parallel tracks in smaller rooms. I hope that we can find in Poland many more decent speakers


• lunch could have been served by more people. Queues were enormous and actually one had to wait c.a. 20 minutes for their food.
  

At JDD I presented myself a 45-minute talk (including demo of Atlassian IntelliJ Connector, Crucible & JIRA) about effective code review in agile teams. Although I used slides from our previous presentation at Agile2009 in Chicago, this time I targeted the talk (especially demo part) more for Java developers and purely technical audience.
I tried to present my stance of how code review relates to agile spirit and common practices (including pair programming).
I estimate than more than 200 people were present at the session. As nobody left before the end, there were a lot of questions and I get some applause, I tend to believe than the presentation was not awful.

Here are slides from the presentation I gave.

JDD Effective Code Review In Agile Teams

View more documents from wseliga.

Sorry for all these folks whose questions to this presentation remained unanswered due to lack of time. Feel free to mail me or questions here at this blog.

On the side note: Last week I received on more spam e-mail inviting my from TSS conference in Prague.
Having read this sentence:

TheServerSide Java Symposium-Europe is where the community learns, shares and prepares for the future of enterprise development. Register now to join 300 of your peers from across Europe in Prague this October.

I tend to believe that with its 400 attendees JDD became this year bigger Java conference that TSS. Congrats folks!
Try next year to be really English conference (still too many talks were in Polish), aim for 2 days and, who knows, JDD may become really 1-st class pan-European conference.

Testing BlogPress for iPhone

I hoped for some formatting and esp. link pasting support - the days I preferred to write in HTML are long gone.

One more thing about that monster I twitted about - it seems to be a GrassHopper, very mobile one, apparently ;-)
Jean-Christophe, are you up to something?



Bottom line for BlogPress - acceptable, easier than plain safari, but not perfect:
- no formatting support
- can't see saved draft in blogger.com web UI

Agile2009 Take Aways

In addition to the usual "Made in China" conference trinkets that tend to disintegrate on the next day... ;-)

Most of the people there were not developers - quite a difference from Java One or Devoxx. This impacted how the sessions looked like - more talking, less demo's; more social, less technical.

Key points (tracks) of the conference for me (random order):

• Pomodoro technique. I attended a session about Pomodoro, it was interesting enough for me to try at home. My milleage 'varies' so far, but I really want to make it work. There is a simple but useful timer for Mac.
  
• A lot of stress on TDD. Many people talked about how great it is, how it helps them write good code, how it helps the design to emerge etc. I guess I have finally been convinced to the when.../should... style of writing unit tests.
  
  My favorite quote was "TDD (test first) is the only way to ensure your code is testable".
  
• Lot's of stress on individuals and interactions over processes and tools, despite visible presence of tools vendors, esp. continuous integration ones.
  
• I really wanted to learn about Kanban, but I rather failed to achieve that. I attended a session about Lean (and Lego bricks), it taught me a bit about Lean background in manufacturing, but not directly about using Kanban in software development.
  
  There was another session that was intended to prove that Kanban is better then Scrum that I haven't attended, but from what I heard the presenter exaggerated Scrum faults too much just to prove the thesis.
  
  Later I have read the article by Henrik Kniberg, it answered most of my questions.
  
• Agile is dead. Not literally, but many voices say that Agile already became mainstream, so it's time to bring Agile to higher level.
  
  Everybody already uses Agile for small non-mission critical systems for which Agile was originally advocated. Now it's time to bring Agile to big, mission-critical and corporate environments, or at least this is the subject the 'thinkers' should focus on.
  
• Game theory in agile contracts was an eye opener. The message to me was "stop being so narrow-minded and think". During this session it was applied to formulating an agile contract equally profitable to both parties. I was too married to my ideas of how the contract should look like that I either favored one party too much or provided too little incentives to get the best contract outcome.
  Of course this was just a simplified exercise, but it showed that out of the box thinking can be applied also for contracts.
  

The more I think about it, the more I agree with the concept that software development is not about computers and technology, it's about people.

maven-eclipse-plugin problem

Just short maven tip. Maybe someone will find it useful.
Few days ago I faced following problem when trying to generate eclipse project using mvn eclipse:eclipse:

Resource directory's path matches an existing source directory. Resources will be merged with the source directory src/main/resources ... Request to merge when ‘filtering’ is not identical.

The solution is to use version 2.6 of the maven-eclipse-plugin (version 2.7 will not work) so add the version tag explicitly to the pom or call maven:

mvn org.apache.maven.plugins:maven-eclipse-plugin:2.6:eclipse

Agile2009 Conference Debriefing

OK, so last week we spent in Chicago at Agile 2009 Conference.
Here is what I think about it.

Main facts

• 1350 attendees, mostly from the US (I estimate them to be 70 - 80% of all participants).
• more than 50% of sessions presented by a pair of speakers (pair-presenting). Unfortunately it was often problematic rather than beneficial.
• up to 22 parallel sessions
• most of the sessions took 90 minutes. Some took 45 minutes. Only a few 3 hours.
• every day sessions started at 9:00 and ended at 17:30. Then less official activities lasted till midnight or so

Main observations

• CI vendors crowd. I dare say CI tools vendors constituted with project management tools vendors vast majority of the exhibitors. Also, there was a lot of sessions related to Continuous Integration (comparing to our only single session about code review)
• max 1/3 of attendees were active developers (really technical folks), the rest: project managers, product managers, coaches, psychologists, business development managers, social sciences students and consultants,
• all really technical talks gathered relatively low attendance rate. On the contrary, social or project/product management sessions usually gathered 50+ people.
• Kanban gathers really a lot of interest (it's already an anecdotal war going on between Kanban and Scrum). However vast majority of people seem not to understand what Kanban is and how it applies to software development projects. I attended 2 sessions about Kanban and I am still confused. Just another hype? Another buzzword? Jeff Sutherland said: "Kanban is Scrum without the sprint constraint". Is it true?
  

The good

• a lot of interesting topics (with varying level of expertise expected) and excellent speakers
• good venue, hotel, food, service and the staff
• unique accumulation of sessions about social/cultural aspects of agile software development
• a lot of networking opportunities (these folks were in general keen to meet new people)
• our talk was rated at almost 4 out of 5 points. There were several positive comments (e.g. about the lack of marketing buzz from our side) and no negative ones. Still, I know that I still sucked as a speaker, but at least I can practice and learn
  

The bad

• wireless worked only in a few places (but it was really fast and reliable there)
• 90 minutes was too much time for a lot of the sessions (including ours). 45 minutes was sometimes not enough. I think that sticking to 30 minutes and 60 minutes for most of the sessions (excluding tutorials/clinics) would be much better.
• when you decided to go for 45 minute session, you had usually very few options after it, as most of other sessions were 90 minutes long and were already in their second half (especially as there were no breaks then).
• 22 parallel sessions were sometimes too much. I wish I had cloned myself into several copies. Fortunately Slawek naturally selected different sessions, so we could cover usually 2 tracks.

Interesting sessions and quotes (not necessarily verbatim)

• Alistair Cockburn: “if you ask me to give you advice about what to do to improve your agile distributed teams, my simple answer is: don't do distributed teams”.
• Esther Derby (a session about performance appraisals): “you are afraid of training your employees because they may leave when they are trained. But if you don't train them ... they will stay!”
• Jared M. Spool: “Crappy people have no problems with producing crappy products.", "Get rid of quality as a requirement and writing software becomes easy.”
• Giora Morein at a session about distributed agile: “change phones into planes”. The speaker (many years of agile experience) is convinced that only by meeting face to face and establishing personal ties, distributed teams can reasonably cooperate. It calls it “Ambassador”, with several subtypes including:
  • delegate
  • traveling star
  • people exchange
  Travel has to be voluntarily. I shared these hints:
  • sites must be located in interesting cities (touristic targets)
  • do not send two or more people to a remote team at the same time - they happen to create a ghetto (isolate and wander together) rather than immerse and socialize with others
• UX design is critical (gave Apple 75% market share over 7% of the next competitor in MP3 players market). The following 3 rules determine whether you care for UX (and thus can develop really awesome software):
  • at least every 6 weeks you (team member) observe for at least 2 hours end users actually using your software (feedback loop). You don't do it, you are screwed.
  • every employee can give you a vision of the product in 5 years from now
  • rewarding for failures (no failures -> nothing innovative, risk aversion companies fail)

Keynotes

There were two keynotes: delivered by Alistair Cockburn about next phase of agile adoption (as agile philosophy was melted down in the ecosystem and now agile is facing new challenges: how to apply to big projects in sophisticated organizations - something which agile methods originally did not (want to) address). Alistair is a great charismatic speaker but I did not find anything new, specially interesting or revolutionary in his talk, although, maybe surprisingly, I liked it.
Another keynote was presented by Jared M. Spool and treated about User Interface Engineering. This was a great, funny and energetic talk. Jared was shining. He emphasized how important user experience is and that it can be a key differentiator in company portfolio (e.g. Apple case). Key learnings were listed above.

Conclusion

This is really a good conference and I think it's worth to be there also next year (Nashville, August 2010).

Can code review be agile? WTF?

If you want to learn what role code review may play in agile teams, visit our talk at Agile2009 tomorrow (Monday 24th of August) in Chicago - 16:00 - 17:30 in Grand Ballroom E.
We are having a hopefully interesting and entertaining session about effective and possibly painless code review. We are also demoing out Crucible and Atlassian IDE Connector which makes it quite realistic.

I promise no bullshit and not buzzwords. I know that everyone nowadays abuses “agile” term (have you heard about “agile UML”, agile maturity model, etc. ...). We are not doing this. Many teams we know (including ours) are really quite agile (sure, they could always be more agile) and still code review plays a vital role in their daily work.

So see you tomorrow.

Keep your documentation website backwards compatible

Most engineers know that you should at least try to keep your software and hardware backward compatible.
If it is not excessively expensive, the new version of your program should read data files created with previous versions, your newest 10Gbit switch should talk to the 100Mbit legacy one etc.

People seem to forget that this should also apply to your website with product documentation.

I have a nice Cerberus Pentagram P6381-0 wireless router that usually works perfectly. Today, however, I had a power glitch that left the router in unusable state.
I managed to get to the vendor's site with documentation, but the closest model I could get the PDF for was P6381-2 (can you spot the difference? ;-))
I managed to reset the router to factory settings using that doco - but surprise, surprise: the default password does not work.

Almost an hour later I googled for the exact model number and I found the right manual on the very same site - it just was not linked in the support links section. If it was, it would have spared me 2 hours of looking for the problem.

And yes, the default passwords are different for P6381-0 and P6381-2 models.

Lesson learned: keep the documentation for older releases easily findable for as long as you have people using it.
This applies esp to products that are not likely to be upgraded as soon as you release the new version: either because it is a piece of hardware or when upgrade costs money or significant effort.