Tagged: dan north Toggle Comment Threads | Keyboard Shortcuts

  • danielsaidi 8:43 pm on January 21, 2012 Permalink | Reply
    Tags: dan north, doc list, gamification, ginger cake, jim benson, kanban, , short software half-life, spike and stabilize   

    Øredev 2011 in the rear-view mirror – Part 6 

    Øredev logo

    This is the sixth and final part of my sum-up of Øredev 2011. Read more by following the links below:

    This is the final part of my Øredev sum-up. It will cover the last three sessions I attended to and conclude my visit to Øredev.

     

    3:4 – Jim Benson – Healthy Projects

    After gathering some key-words from the audience, Jim’s defined healthy projects to be:

    • Happy
    • Productive
    • Stress-free
    • Focused
    • Nice to the workers

    He gave a good description of when things tend to go wrong within an organization, visualized with the following organizational structure (a single node topmost and several nodes bottommost):

    • Company (has many portfolios)
    • Portfolios (has many projects)
    • Projects (has many tasks)
    • Tasks

    Imagine someone working at task level being “promoted” to project level, e.g. becoming product owner. If this person cannot understand his new area of work and keep focusing on the details of task level, it will lead to micro management. The same goes when moving from project to portfolio and portfolio to company level.

    Speaking about rules, Jim states that when you add a lot of rules, you will also have to introduce a process. If the rules are then hard to follow, people will fail…and when they do, they will blame the process. Methods like Kanban, for instance, visualize the work, minimize the amount of ongoing work and lead to healthier projects.

    A good technique that can be used to visualize how the team feels is to have it marking the scrum/kanban notes with an illustration that describe how they feel after completing a task. I found this to be a very good idea! It is so simple, yet communicates so clearly how the team is feeling.

    This session grew on me afterwards. While sitting there, I found it hard to stay focused and found large parts of the session rather passable, but after reading my notes afterwards, I found some golden gems.

     

    3:5 – Doc List – Development is a game

    Okey, so this session was about Doc having an idea…and wanted a lot of stuff to happen. His question was, how do we measure how good we are at what we do and what are the tools of measurement that we should use? Certificates? Level of success?

    Doc asks us – why can’t life itself be a game? Why can’t we have rewards in our professions (actually, Visual Studio has just introduced achievements, so we are getting there)? Why can’t we have quests? Want to measure how good a person is – give him a quest! Want to measure how good a team is – give them a group quest!

    Doc wants to create a globally applicable system that ranks people according to what they know. With this system, if you need “a level 24 Java developer”, you will have a specification of what a level 24 Java developer knows…and a list of persons who are at that level (since it is measurable). Doc wants to build a global community for this and wants…

    …well, there you have my biggest problem with this session. Doc is a really charming man who has been around a while and has a great rep, but…he wants a lot of things and talks about it without having created nothing so far. So, he just describes a vision.

    I could have found the session interesting, and Doc convincing, if he at least had started. So, I eagerly await Doc to prove me wrong and announce that he has started working on that global system of his. Until then, I will lay my focus elsewhere.

     

    3:6 – Dan North – Pattern of effective delivery

    With Dan’s keynote being the undeniable highlight of Øredev for everyone that I know saw it (I did not, unfortunately), I really looked forward to this session…as did the entire Øredev. The room was packed.

    Dan spoke of some exciting new patterns, like:

    • Spike and Stabilize (easy, semi-effective) – try something out, then build it well. Optimize for discovery.
    • Ginger Cake (semi-hard, semi-effective) – break the rules once you go senior…”it’s like a chocolate cake, but with ginger”
    • Short software half-life – how long does it take, before you have to fix a bug? Optimize for throwawayability.

    No, in fact, I did not find this to be a interesting session at all. In fact, I found it rather pointless, which was a huge disappointment.

    Dan, like many of the big speakers, is very charming and passionate when on stage…but I cannot help to feel that I perhaps should choose more concrete sessions than these “inspired and fun” ones, the next time I attend to one of these conferences. I am obviously not the target audience.

    Please watch the video? Do you disagree with me? Let me know in the comment field below.

     

    Conclusion

    Øredev 2011 was a fantastic conference, with high mountains and, unfortunately, some rather deep valleys. Next year, I hope to see even more local talents, and more odd and exciting selections of speakers. How about a grave russian who (in bad English) demonstrates some kick-ass piece of technology without one joke being said or charming smile being fired?

    I would like to see that. Maybe next time.

    Anyway, a big, BIG thank to the Øredev crew – you delieved a really inspiring conference that I still return to mentally.

     
    • Henrik 9:11 pm on January 21, 2012 Permalink | Reply

      Agree, Dan’s keynote was much better. This was a bit hard to grasp.

  • danielsaidi 11:41 pm on December 6, 2011 Permalink | Reply
    Tags: cqrs, dan north, ddd, event sourcing, , , rickard öberg, uncertainty   

    Øredev 2011 in the rear-view mirror – Part 3 

    Øredev logo

    This is the third part of ny sum-up of Øredev 2011.

    I will label each session with day:order to satisfy all structure freaks (myself included) that read this.

     

    2:1 – Dan North – Embracing Uncertainty – the Hardest Pattern of All

    If there is one session I really regret not attending to, it has got to be this one. Everyone I spoke to afterwards were totally blown away by Dan’s keynote about how we humans strive to avoid uncertainty at all cost, even in situations where uncertainty would be a much better mode to be in than being certain.

    Uhm…I’ll just point you guys straight to Daniel Lee’s excellent blog, where he write more about this session.

    Dan North

    The quote “Fear leads to risk, risk leads to process, process leads to hate… and suffering and Gantt charts”, “We would rather be wrong than be uncertain!” and the way Dan reasons about how faith become religion makes this the top session that will keep me waiting for the Øredev videos.

     

    2:2 – Greg Young – How to not apply CQRS

    I just love Greg. After this session, I stormed out of the room and bursted out “I think it is SO cool that Greg is, like, the Henry Rollins of software engineering”, on which a complete stranger turned around, equally happy, and almost shouts “I KNOW!”. A minute or so later, I happen to overhear a conversation, where one guy says “Wow, Greg looks JUST like Phil Anselmo”.

    Greg Young

    Henry Rollins?

    Yeah, Greg is the personification of all those metal vocalists we always wanted to be (or be friends with) and lets us embed ourselves in a thick layer of ignorance that allows us ignore that we are a developer converence. Oh no, we are almost those rock stars we dreamt of to become…and almost friends with Phil and Henry. I also think I saw a little bit of Mike Patton in his eyes, and a piece Christian Bale in the way he speaks.

    Henry Rollins

    Greg Young?

    All this despite the fact that Greg wears Five Finger Shoes. Five Finger Shoes!

    That is quite an achievement.

    But hey, what did he talk about, I hear you ask. Well, I frankly do not remember. No, that was a lie. Greg talked about how one good way to fail is to apply CQRS everywhere within a monolithic system. CQRS is not a top level architecture. It requires a bounded context. So, to apply CQRS in a non-core context, and without a bounded context, is an almost fail-proof way to fail. With CQRS applied everywhere, nothing can change.

    Greg then went on to speak about CQRS and DDD, and the dangers of imaginary domain experts. Who can be considered to be a domain expert? The consultant who have worked with a system for a while, who maybe even answer to another consultant? Or is it an employee who have worked with the domain for a couple of years? How about twenty years?

    This is really important, since CQRS is business-centric, which is why CQRS and DDD without domain expertise does not work. The result will become like playing the telephone game and translating Shakespeare with Google Translate. BA:s are really good at asking the right questions, but they are not domain experts.

    As an exercise, Greg talked a bit about Programming as Analysis, which I’d like to try. The point is that you are supposed to build a system for a domain that you do not know. Now, timebox your access to the domain expert to two hours. That is it. In two hours, you  have to find out everything you need to build your system. The entire system. Sure, you will fail. Fail hard. But, in doing so, you will come up with a bunch of new questions. So you throw everything away. Everything. Then you do it all again. Two hours. Build the entire system. Then again. Then again.

    Greg finally summed up his session with pointing out the most certain way to fail – by learning CQRS by building a CQRS framework. Instead, focus on the business value of applying CQRS. He finished his great session with calling frameworks “crack for architects” and  stating that frameworks are evil.

    Great one, Greg. Thanks a million. Now, drop those five fingers and I would not hesitate to put a poster of you up on my wall.

     

    2:3 – Rickard Öberg – Event Sourcing explained

    Next to CQRS, which I have not had the pleasure of applying (maybe I should build my own CQRS framework…or?), Event Sourcing is something that I’d love to try out.

    Rickard Öberg

    Rickard started with describing a common architecture:

    Client <- Service facade <- Domain <- Storage

    and how with Event Sourcing, things look a bit different:

    Client <- Service facade <- Domain (Commands -> Events) <- Event storage

    We do not store state – we store events, which is a huuuuge difference. By storing the events, we can replay all the events that has affected an entity during its lifetime, and in such a way build it up from scratch to its current state. In order to avoid really heavy operations, we can store snapshots as well. With snapshots, an event stack like this one (the latest event is topmost):

    Event
    Event
    Event
    Event
    Snapshot
    Event
    Event

    is handled by starting with the lastest event. As long as the item is not a snapshot, we keep it for later. Once we reach a snapshot, we grab that representation, then apply all the events that we have kept for later. This way, we do not have to replay the entire life of the entity, just a part of it.

    That is basically it.

    Rickard, however, then went on to talk a bit about his event sourcing framework. Obviously suffering after Greg’s recent framework burstout, Rickard had the balls to still insist that his framework was really good…and that he likes to use it. I for one believe him.

    With event sourcing, report generation becomes a breeze. Also, you never loose data. If I add 5000 to my bank account then withdraw 3000, and no events are stored, all I know is that I now have 2000 more than before I started. Sure, maybe the system writes transactional details to the log, but with event sourcing, the event storage becomes the log.

    Due to its log-like nature, event sourcing also simplifies debugging. Who did what when? With event sourcing, nothing gets thrown away. My events is what makes my entities look the way they do. If an event accidentally was not saved, that is bad, sure, but it is another problem. My entity does not know about it, since the event does not exist.

    Event sourcing continues to interest me. Maybe one day, I will actually get around to use it?

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel