As always - after the first day my head was just spinning. I was so tired that I slept before I hit the pillow. But today I’m feeling great again and am ready for another great day of learning.
Dan North on Embracing uncertainty
Dan North is one of my true heroes in our industry. I’ve learned a lot of the stuff that I’m excited about from stuff he written and spoke about. This is about embracing uncertainty - which seems to sit nice with the whole BDD - Deliberate Discovery body of knowledge. Here’s a few things I jotted down:
Patterns of effective delivery (behavior patterns that is)
How we turned the agile manifesto upside down nowadays
The half-time of requirements - how long time before half the requirements needs to be rewritten
“We would rather be wrong than be uncertain!”
Christianity (!) and how faith become religion. Or values becoming rules and structure. And the values disappear in the structure. Jesus was anti-religion of the structures in his time.
The answer don’t matter - struggling with question is.
Kent Beck didn’t talk about the 12 practices of XP. He focused on values and said: What I want to do is to get business and IT to talk each others. The practices was just ONE way to reach his goal.
Get a handle on uncertainty to be able to manage it. One way to do that is embracing uncertainty:
- embracing uncertainty of scope - with rolling wave planning for example
- embracing uncertainty of technology - start code by sketching out stuff for example
- embracing uncertainty of effort - for example beyond budgeting (measure stuff and handling money as it was your own)
- embracing uncertainty of structure - structure only gives you an illusion of control. you can’t predict the future
Real options: a model of uncertainty -
- Options: making a deal that someone to buy the right to do something in the future. Buy the right to buy a bunch of SEK at a fixed price for example.
- Real options - betting against yourself in your everyday decisions.
- Create options for every decision
- “Never commit early unless you know why”
Deliberate discovery - “Some unexpected bad things will happen” - go and find them. Optimize for finding them. You can actively reduce that ignorance.
Goes without saying - that was great!
Greg Young on When not to use CQRS
Greg is going stone-age on us. No slides, no whiteboard and no sound! :) Nice! The hall is packed - this promise to be great.
CQRS and Event Sourcing is not suitable for monolithic applications. We need bounded contexts - a huge point of CQRS (and ES) is decoupling. So if you put everything in one big pile anyway - why bother?
CQRS applied in non-core (huge return on investment) applications. Is this an area where our company is where we derive our compatible advantage.
Don’t use CQRS for the technical reasons - programmer pornography. It could be considered but should be applied within a single bounded context. It’s not done for all bounded contexts.
A common problem is to do CQRS (and ES) and making a lot of decisions upfront. Deciding to use BizTalk before you know what you’re actually building.
Using CQRS and becoming use case centric without buy-in from the business. “Only the development team think is that they are core business.” Often combined with not being a domain expert. There is a difference in being an expert in how the system currently works and being domain experts.
Nice exercise; sit with the domain expert in just 2 h. Then build the complete system (or at least the domain model). You will fail! But you will raise some important questions. Now go back to the domain expert again and ask those questions. Sit again in 2 h. Delete the code you did the first day. Rinse, lather, repeat.
Don’t write a CQRS framework. Hey, don’t even USE a CQRS framework. Just do it! You should be able to be up and running with something giving business value in a day. Otherwise you might be focusing on the wrong thing.
Use frameworks for stuff that would take a long time to write it yourself. CQRS could be (and is) written in 200 lines - don’t use a framework. MVC would take considerably longer than that. :)
Richard Öberg on Event sourcing explained
Richard will talk about what event sourcing is needed for and what it will give you.
I was probably a bit tired but this didn’t grasp me. Richard shows some concise code written in his framework. Ironically Greg Young spent about 40 % of his talk on how you shouldn’t write framework.
I liked Richards concept of exposing the events as ATOM feeds. He saves them in JSON format and can then expose them as ATOM feeds for reporting for example. Or send them further to other services.
Storing the events in the first place opens a lot of possibilities; domain events that informs other parts of the system or other systems, reporting, replication, backup and an audit log for free.
By storing the events as the come in gives you a much more fine grained control.
I personally think is that to sell event sourcing to business is a bit scary. But you could probably do ES anyway by simply have a reporting database that is kept in sync with the event source. So that there still is a relation database that most businesses are used to.
Lunch
I had great discussions with colleagues and friends on CQRS and Specification by example. Again struck by the fact that best learning is taking place in the breaks. Hard to sum up in blog posts though. :)
Gojko Adzic on Sleeping with the enemy
Again Gojko is talking about something that really struck a chord with me. So why is testers and developers; us and them? Why does developers “know” more about “developing” and tester more about “testing” than developers?
Independent testing, code freeze, requirements sign-offs and document change management - none of these were done by any of the amazingly successful teams that Gojko interviewed for his book. There were the team with no bugs in production for the last 5 years, doing releases every other weeks, for examples. Or having so few bugs that they don’t even use a bug tracking tools - another example.
Disbanded the developers team and the tester team and created a team that is responsible for testing. And developing. Hey - they are responsible for the quality of the product. And they level out the knowledge gap (developing, testing) to better understand and help each other.
In the process they removed a bottleneck (undermanned in the testing department).
We took a quick poll on who should own test automated functional test? The audience argumented for both but Gojko disagreed, arguing that programmers HATE doing automated tests and hence minimizing. Testers should/could spend time their time on designing tests (that testers are good at) and programmers can then automate them (a typical developer skill).
Nice - but I disagree with the incentive for programmers to do it.
Gojko told a story where this kind of co-operation occurred by the developers just sitting next to the tester. Not testing. What happened? They started to suggest what could be automated, they learned about the problems that the testers experienced and where problems and misunderstandings occurred in the system.
Developers and testers need to start working together. Get together as a whole team and ask yourself; what is our number 1 problem and how shall we solve it?
A story on a very productive team that produced excellent quality. But after a while they needed to test a lot of platforms and hired a tester to help them with setting that up. They hired a brilliant tester. But quality took a nose dive. Why? Because all of a sudden they had a tester - who had become responsible for testing. Everybody else stopped to care about test - something they did before!
Testers should be responsible for ensuring that the right things, testing the critical (“hard”) stuff and teaching other how to test.
Testers is a common bottleneck in companies today. Why? Because they take on to big a responsibility - move the testing responsibility to everybody.
Mark Rendle on Zen and the art of Software
I moved myself into the excellence-track (hey look at me:)) to see Mark Rendle, the creator of Simple.Data and a general interesting guy. And from the topic of the presentation this promise to be interesting too :).
Mark started with some book tips:
- Pragmatic programmer
- Design patterns
- Code complete
- Clean code
- Zen & the art of motorcycle maintenance
That last one is a bit surprising and the topic for this talk. It’s a book about quality.
Mark is reading from the book and gives comments - novel way for a talk, I must say.
We’re talking about what it takes to create quality software; stripping away all the xDD and tools.
Put yourself in the mind of the user. They will use the software. Maybe 8 h a day. So if the software is boring, breaks or hard to use - your are ruining 1/3 of the users life!
Classical understanding (art or code for example) and romantic (art or UI for example). The understanding of the system for the user is actually the UI not the code.
Gumption, a old scottish word; what happens with someone who connects with quality - he is filled with gumption. Drive and enthusiasm. So what is the Gumption traps then? What draws Gumption from us?
External Gumption traps
- Getting it wrong - be safe on this by having regression tests for examples.
- Intermittent failure - this that is wrong becomes right as you start fixing it. The only way find these kind of failure is to setup a whole lot of profiling.
- Parts - third party products in our business. Choose parts from people/companies with Gumption.
Internal Gumption traps
- Value rigidity - “my programming language is better than yours”. This is a fast moving business - you can’t have value rigidity. Expect that you will slow down when you learn new things
- Ego - similar to the value rigidity. Approach everything with the attitude as if your were a complete idiot. One day you’ll find that you is not an idiot anymore
- Anxiety - don’t dare do anything of fear of failure. Get control with a Kanban-board or similar
- Boredom - flow is the other end of boredom. To get in to flow you can use TDD.
- Impatience - give yourself more time. Overestimate. Otherwise you’ll end up taking shortcuts
Living right - no job is not “just a job”. You do your job to feel good about yourself!
What is quality? How do you know when you delivered quality?
Code is not software by itself. It’s software when an user actually starts to use it. Quality cannot be measured until that moment.
The end of the talk was almost a bit emotional… until a phone rang and Mark had too use some profanity to make it stop. So in the same talk we got laughs, tears (well … almost) and profanity. Pretty amazing for a technical talk :)
Mark Rendle on Phone Apps Unlimited
And then I went out for awhile. My brain was going slower and slower so I need some air. It worked wonders and now I’m back for another, very different, Mark Rendle talk. This time on Phone Applications. Sadly I have to leave early, but hey I’ll get some goodness as long as I’m in here.
I talked with Mark before the so I know that the talk will be about moving so much as possible onto a server that your applications can call via HTTP. That means that you can write simple simple applications (views if you want) to call into the server.
65% of the internet traffic in the US is from mobile traffic and climbing. Windows 8 is a not windows anymore, it’s mobile platform. With these quotes Mark got our sense and urgency.
All different platforms (Android, IOS, Windows Phone 7) all have different tools and languages. So what could we do?
Well in the cloud we have unlimited resources and can chose our platform and languages. So we try to move as much as possible to the server (in the cloud).
As such Mark has created a Pocket C# - a small IDE in the phone. The actual compiling and all the heavy lifting is done on the server. The writing of code and viewing of the result is done on the phone. Nice!
For example - use DropBox to store files. It’s simple and straightforward to build. Using ReactiveOAuth to do authentication.
Use Windows Azure Toolkits for Phones to reach the Azure services such as SQL Azure or Azure storage for example. And some great great scalability “for free” :)
I suggest everybody interested in great ways of building phone applications using your existing skills to find the code from this talk. Some great stuff in here!
Conclusion
And now I’m off meeting an old friend.