NDC Oslo Day 3, Part 2

...and here's part 2 of day 3.

"Uncomfortable with Agility: What has Ten+ Years got us?", Andy Hunt

Andy Hunt is one of the co-authors of the Agile Manifesto.

This also was a very good talk. He started by asking if we did agile. All raised their hands. "You're doing it wrong!" :-)

It's a bit hard to retell this session though, don't know why but I think I was too busy listening instead of keeping notes... :-) But I'm going to try to capture some things in essence.

He came back to his question of how many thought they where doing agile. Then he said "You don't do agile, you are agile!"

He also quoted Charles Darwin: "It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."

And this was the essence of what they where trying to tell with the agile manifesto. And he thought that, maybe, "agile" wasn't the best word for this. Maybe they should have called it "Adaptable" or something.

Because Agile is:

• ever-shifting
• ever-changing
• ever-responding

Agile is not a thing. When they created the agile manifesto they thought that millions and millions of different method would emerge. But now there's just a handful (Scrum, Kanban, Crystal etc). Agile is not one method.

• We want to be searchers - not planners!
• We want to learn - not know!

With agile development we use feedback to constantly change: Do - evaluate - correct.

It's like "live tracer bullets" - you see in real-time where bullets are landing, and adjust to hit the target.

How do you get real-time feedback?

• Coding: Paring, TDD etc
• Design: Try it!
• Requirements: constant user involvement
• Teamwork: stand-up meeting

Seek and apply feedback to change things! Become a searcher!

Un-agile warning signs:

• You should value: "Individuals and interactions"
• "Great! Which process and tools should we use for that?"
• You should value: "Working software"
• "Great! Which automated spec framework should we use?"
• You should value: "Customer collaboration"
• "Great! How Much should we commit to in this sprint?"
• You should value: "Responding to change"
• "Great! Let's build a 200 story backlog and follow it!"

The biggest missing element:

1. Agree
2. Add

Think of it as an improv theatre. If an actor says "I like it here on the moon!" the other actor cannot just say "Yes" (or "No"). Then the entire improv dies. He has to add something to it for it to become a valuable improv. "Yes, and I can see a frog behind that stone!" and the other actor continues "Yes, and..."

So, remember "Yes, and..."

One other thing he said is that agile is like crumbling papers: "No, this didn't work *crumble*. No, this didn't work *crumble*. No, this didn't work *crumble*." and so on. Always try new things, evaluate, correct.

He had a lot of other things he said as well (that where really good), but these things caught my attention.

"Why Document Databases supercharge your application development", Christian Amor Kvalheim

He didn't show that much code in this talk, it was mainly a conceptual talk of Document Databases (DD). And it was a really good pitch for using DD. I was a bit sceptical, but now I'm really keen on trying this. The thing I was sceptical about was that I thought I would miss the entire "relational" thing with DD. But he showed some nice concepts about that.

First he talked about that the world is not a structured place, it's actually very unstructured. But we try to impose structure. But DD tries to capture that unstructured place...

So if you find yourself doing (a lot) of ALTER TABLE or using key-value-pairs to go around it. Then DD might be the answer. 

But mainly DD maps better the object oriented thinking.

Then he talked about ORM (Object-Relational Mapping). And he didn't have to convince me here, I basically "hates" ORM :-)

And as Ted Neward said: "ORM is the Vietnam of our industry"

Thing he thought where ORM cracks:

• When using polymorphism.
• Ownership of schema is split
• Duplicate/Partial schema (in DB and in code)
• How to abstract away SQL
• Partial objects problem
• Lazy loading and stuff like that

But how do you solve relations?

• One-to-many:
• Embedded: relations inside object
• Normalised: use id's in object or let other object point to one object
• Many-to-many:
• Keep id in both objects (pointing to each other)

Inheritance and polymorphism. Don't have to say much here, you know it, this is where DD fits.

He also talked about that the Document Model is good at representing tree structures. And he showed some example json code to show this.

He listed some helpful tips:

• Avoid
• DD as a relational database.
• Application Joins.
• Massive documents.
• Continuously growing arrays.
• Wrong level of granularity (to low/high).
• It's just like a REST API (lots of small calls is a sign of wrong level).
• Good ideas
• De-normalize first.
• Map your document to your OO model.
• Normalize as needed.
• You have to know DD (not only OO)
• Just as you have to know SQL even though you use an ORM tool.

I asked him about reporting. And yes, DD isn't as good as a RDB at doing application joins, but his tip was to export data to a data warehouse. 

My thoughts are that no method is better than the other. RDBM have a purpose. But I like the idea that DD better captures the unstructured world we live in. And that it is good at representing tree structures.