f3yourmind

I often talk about fake agility – agility in process and not in your mind.  And I nauseatingly tell everyone that if you want to be agile, you must become agile in your life.  The one area that I’ve been struggling with for almost nine years is fatherhood.  I don’t think there is a tougher learning ground for agility than being a father (of course, Fiona will tell me that motherhood is a lot harder, and she’s most probably right).  But after just under nine years, I still feel like a beginner on the Dreyfuss scale.  I do look for signs and feedback and adapt to parenting situations on demand but the unpredictability of being a father is undeniably higher than any software project I’ve worked on.  The reason is simple: children are naturally agile.  They react to their environment instinctively, doing what makes sense to them.  In spite of being aware of agility, the theory, the principles and practices and being a practitioner for so long, I am convinced that agility in fatherhood is a significant step in life agility.

To help me progress beyond “Beginner”, I invited some friends to write a short piece on Agile Fatherhood.  Each one my guests has either just become a father for the first time or been “coaching” for a few years now.  I left the interpretation of the topic up to each person.  Personally, I think it makes for some fascinating reading.  And if you know these amazing geeks, you will learn a more personal side of them and understand them just a little bit more.

So here are some thoughts from friends much wiser than I and for whom I have an immense amount of respect.

Claudio Perrone ( Oh man I hate you )

Being only one month on my first baby boy I feel I’m not even chartered in the Dreyfus model, so I’m not sure I have much experience to share yet

Being agile means to be able to quickly adapt to change, not simply react to it. Irene and I have struggled a lot. Then something happened. Instead of reacting with frustration to an ever screaming baby (I still call him the Anti Christ I began to fully accept Matteo as an individual I needed to understand better. I “reprogrammed” my tone and attitude. I read a book on newborns. Apparently I have a “touchy baby” (aren’t they all?). So was I apparently. My mum told me that, exasperated, she once brought me to the doctor asking “what the hell is wrong with him???”
Among other things, I took ownership of the kitchen (i had to) and bought a book to try many new recipes (I didn’t have to, but I was getting bored of my usual pasta).

Finally, in the last few days, I dropped my usual bottom-up GTD approach to productivity and went back to a top down approach. Mission, roles and goals, in other words (or “do the right things before doing them right”). It is still work in progress, but the sudden imbalance forced me to revisit my roles as family member, friend, self (to eat better, exercise, learn and refine my skills), my impact at work (ahah currently none), my contribuition in the community and, finally, how I can still relax and enjoy life. (if you are curious, I’m  experimenting with Life Balance for the iPhone – Omnifocus is suddenly sitting idle).

If you need only one sentence with an agile perspective:
Embrace change and enjoy the ride. And since you can’t possibly be perfect, strive to achieve instead

Niclas Nilsson I tweeted this a little while ago, and a lot of people actually found it to be a useful analogy:

Raising a kid is like playing a platform game. First everything is new and a bit tricky, but then you get a hang of it. For a while, it’s actually quite smooth and you start to believe you’re pretty good at it. About that time, it turns out you have completed that level and you’re standing at the gates to the next level. But to get to the next level, you have to pass a monster…

If I’ll connect this to your question, what I mean is that everything seems to go in phases (iterations? at least increments), and that you’ll always get a new challenge (often in surprise) that you don’t know how to handle and you have to resort to your problem-solving agile mind to figure out what to do. Or rather, what to try first, since you have to try and try again until you find what works. If your lucky (or talented? or hard-working?), you’ll find a way that works and avoid screwing them up for life, but you’ll have to wait and see until they become teenagers to be sure. There’s no roll-back functionality in life. You can try compensating transactions, but you can never go back to the exact same state.

Herman Lintvelt Wow! Selected from maybe millions of people…

Communication; the importance thereof. That is probably one of the main ideas that I am extracting from the Agile approach. One of Agile’s core principles is to place people above processes. That implies that good communication is very important. Part of good communication is regular, positive feedback. So I’m trying to really make that part of my approach towards my two-year old boy. (His sister is only six weeks old now, so communication currently consists of making goo-goo sounds, or sometimes just googling at her). E.g, we are encouraging him to say “please” when asking for something, but recently realised that we are not using “please” when we ask him something. Now I try to lead by example and use “please” and “thank you” when talking to him as well.

I still have a lot of iterations ahead with them both, and I’m excited as well as a bit afraid of everything to come. There is a lot of different “formal” approaches and recipes one reads about for raising children, and I know I won’t be able to follow all of that advice, so I’m just staying agile and concentrating on people above processes.

Chris Hedgate I really like Niclas’ analogy with platform games. I remember some games where you could move along quite smoothly through a level, save whenever you want and come back later to continue. But then, you go through a door, and you find yourself at the final stage of that level. You are not allowed to save at that stage, so you have to go through it in one try, or start over from that door. That reminds me of how it often feels with my 3-year old now. Sometimes I find myself in a situation that I either have to work through, which often requires lots of time and energy, or just let it go and come back to it later. I used to do this wrong I think, where I would try working it out but not have enough patience or time, and all of that work was lost. It’s the age old saying, “You can’t be efficient with people”. So I think that is one thing that connects work and fatherhood for me, always deciding if it is the right time to pursue some goal or try to make some change happen.

For me, the most important parts of agile is people-focus and constant learning. And I definitely bring both of those to fatherhood. Like Herman said, communication is really key. It is amazing what a 3-year old can tell you if you really ask, and understanding their reasoning will often show you that you are trying to “fix” something completely different from what the problem really is. And there’s where the patience and time comes in, you cannot rush this communication.

Regarding learning, I believe life is a long continuous learning experience. So therefore I encourage my son whenever he is interested in something. Right now he is into dinosaurs, so we talk a lot about dinosaurs, look at pictures and so on. He can name Tyrannosaurus, Brachiosaurus, Anchylosaurus, Stegosaurus, Triceratops, Pterodactyl and probably a few more from seeing them in a picture.

Regarding Claudio’s comment about retrospectives, I think even if you do not have formal retrospectives it is a great idea for both mother and father to observe and discuss each other’s behavior. It is much easier to see or hear things from an observer point. Also, we often find that if one of us do not have patience to continue through a situation, the other one can step in and resolve it.

Finally, to round off a rather long mail, I have to tell a story describing a recent situation. My son has a party whistle, the ones that make a whistle sound and roll themselves out, that he loves to blow. The problem is that my dog can’t stand the sound and tries to bite the whistle, often resulting in pushing my son to the ground and he gets upset.  So, I see him grabbing the whistle with her (the dog) standing right beside. I could have said “Do not blow the whistle here”, but I know how well that would have worked. Instead I asked him what happens when he blows it, and he said that the dog gets angry.  “Then what happens”, I asked, and he answered that she jumps up and pushes him. So I asked how he likes that, and he said that he gets upset and starts to cry. I asked if he wanted that, and he said no.  So finally I ask “What do you want to do then?”, and he says “I’ll go upstairs and blow it”, and goes directly up without blowing it on the way.

Has this helped me?  Yes and no.  Yes, because the analogies and lessons are extremely insightful and valuable. No, because they didn’t have a magic wand cure.  But that’s exactly the point.  There is no magic, just learning and adjusting all the time.  Like I always say: “You need to let it take over your life.”.  When you do, then everything becomes simpler.  Like making that 1px adjustment on the last level of that game or just blowing your whistle where the dog can’t get to you.

During a factor10 virtual coffee break, Niclas Nilsson and I had a chat about what’s going on in web app land, on the browser end of the landscape. So this is inspired by his observations and him ‘pushing’ me to write this.

Recently, I’ve seen a few people searching for the holy grail of the ubiquitous browser UI.  The usual suspects appear: Silverlight, Flex, JavaFX.  Then I always suggest “What’s wrong with HTML, CSS and JavaScript.  You are writing a browser app, aren’t you?”.  And I get this weird, one raised eyebrow look.  So, in response to the one-raised-eyebrow look, here’s what I have observed. (I use the word model and fat below, maybe it’s the wrong usage, but I think you’ll get the gist.)

In the early days of browser apps, everyone was trying to write fat desktop apps in HTML.  And that went horribly wrong because the programming model was different.  We eventually figured out page based, disconnected apps in the browser, then someone did the AJAX thing and we had out-of-bound HTTP requests and in-place DOM updates.  Another small twist in the programming model.  But we had already made the transition to a new programming model and AJAX was not a radical change.

Now we have Silverlight, Flex/Air and others.  They happen to run in a browser, but there’s nothing browser based about them.  Yes, they all let you interact with the DOM and run some JavaScript too.  But these apps might as well not be in a browser.  In fact, that’s now pitched as a super great feature: your code can run inside and outside the browser.  The programming model is different.  No matter what the marketing folk say, I think the in-browser feature is a clever adoption scheme.

The truth is that this new thin is actually fat, FAT, FAT!  It’s just fat and disconnected.  That is all.  My advice for those that want to go this pseudo-thin route, is to just write your app to run outside the browser.  Just forget about the browser.  If you want to use the browser, then go back to HTML and JavaScript. The common counter statement is that these clients get rid of browser incompatibility issues.  If you really want to get rid of browser incompatibility issues, then don’t use a browser.  Simple.  And these confused thin clients will let you do that.

But the part that really scares me is that the fat code I have seen so far reminds me of unmaintainable VB, Delphi or PowerBuilder code.  And there are other scary things too.  For example, the Cairngorm framework for Flex is based on a singleton pattern, but the underlying language does not make it easy to create singletons.  Imagine all the code to create a singleton just to get the framework to work.  And these frameworks are not very DRY either.  Somehow, it seems like a new group of developers are writing these frameworks and they have not bothered to learn from 10+ years of web UI framework lessons.  The good news is that code maintenance and framework quality issues are solvable.

But the game itself has changed.  It’s not a case of new rules in an old game.  That’s what caused the mess in 1999 with HTML.

By this time, most people either close their eyes or raise the other eyebrow at me.

Recently I wrote about the fruitless plight of a schizophrenic service.  Now, I think that some of that schizophrenia exists in the ESB too (or is it rubbing off onto the ESB?).  I’ve always felt that the ESB was just another pattern that showed how to isolate things and deal with routing and transformations.  The most common implementation was a messaging gadget with some pluggable framework of sorts for the transformations, and some configurable framework for routing.

With such isolation of parts, it was convenient to not worry about what happened elsewhere when something was thrown to this gadget for processing.  And we started wondering about scalability things and decided that asynchronous was the way to go … disconnected, stateless, etc, all good, well-intentioned things and useful things.

Then the pattern became a product.  And on top of this product we had more products like business process orchestrators or workflow managers.  And below this product we had applications and databases and ftp locations and all sorts of things that catered for every imaginable protocol.  And around all of this we had some enterprise-ish sort of management thing to keep on eye on everything that was happening inside this very busy product.

Then, services moved from applications to the ESB product.  After all, it’s a service and that’s an enterprise service bus, right?  And when the services where moved over to their new home, all the dependencies had to come along too.  And then we started arguing about getting granularity right in the ESB.  I used to just think that the ESB had a proxy of sorts to the service that still was at the application.  Maybe I got it all wrong.

Now this ESB is starting to feel like an Application Server with a messaging gadget, workflow gadget, transformers, routers, protocol handlers.  And some ESB’s have a web server too, since they have browser based management consoles.

Some people also like the idea of a rules engine for their complex domain rules and embedded those in their applications.  Hold on, those content based routers in the ESB also used a rules engine.  Ok, let’s move our rules over to the ESB too.  Cool, my ESB is also a rules engine.

Now, I see people writing the most hellish XML that is meant to do everything from configure routing, define transformations, execute code, persist messages, fire off sets of rules and more.  It reminds me so much of those weird and wonderful stored procedures and cascading triggers that we wrote.  The other day I got a laugh out of a friend when I told him that ESB’s are now DB servers and everyone writes sprocs in XML.

And we tried to do everything in the database server – rules, custom types, defaults, constraints, sprocs, triggers, batch jobs … even jump into a shell and execute something else.  It did not work out very well then.

If I was an ESB, I’d be very confused.  I started life as a pattern with a reasonable implementation using messaging and transformation and routing.  Now all of this.  In fact, I’d be more stressed than confused.

Then again, maybe the ESB is not confused, and maybe the people that use the ESB that are confused.  In fact, if I was one of those people, I’d be stressed too.

I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa.  Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change.  Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.

The one thing I can tell you is that the course is a very immersive experience.  I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along.  As a result, the day takes unexpected turns and routes.  But in the end I get you to the right destination.  Come along; you will leave exhausted, but inspired!

Take the Fast Track to Domain Driven Design

about the course /  course contents / should you attend? / register for the course

factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional.  On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.

Who should attend?

This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers.  Register for this course if you want to …

• learn more than just another syntax and set of tools
• write software for large, long living systems
• increase the quality and maintainability of your design
• design high quality models and use code to represent those models effectively
• develop applications with a good APIs
• add a design edge to your skill set

Why should you learn DDD?

More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.

One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.

about the course /  course contents / should you attend? / register for the course