f3yourmind

Do you remember that catchy Beatles song?

Oh yeah, I´ll tell you something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand

So what made me think about this?  That frustrating construction of the new M5/N1 interchange in Cape Town!!  When you’re sitting in traffic, you can’t do anything but look and think.  And I’ve seen this scaffolding get taller and taller and wider and wider and longer and longer and more and more people appear on it each day.

Sourced from http://www.capetown.gov.za

I know that one day, they will remove the scaffolding and the concrete will just hang there in mid air on those massive pillars and walls that they’re busy building, and I won’t be sitting in traffic any longer, and it will all just work.

What a shame that software is not like that !!  So many people get turned on by scaffolding.  And The Beatles sang on …

And when I touch you i feel happy, inside
It's such a feeling
That my love
I can't hide
I can't hide
I can't hide

And just like the M5 construction, so much scaffolding gets built, and so many people climb on.  But then, they don’t climb down.  And they don’t tear down the scaffolding.  And it just stays there mashed in with the concrete bits.  And then they ask people to use it.  And it takes strain and then it’s a performance problem, or a load problem, or it just crashes down.

I do use scaffolding, but most of the time it’s in a spike and more often it’s in a test, just to get me over my point of fear.  Deploying software with scaffolding is just dangerous and negligent.  I really don’t want to drive my car over the M5 interchange while those thin steel pipes are holding up the concrete slabs.

But above all of that, the most important scaffolding is social scaffolding.  It’s better to provide human scaffolding to support each other on a team that is focused on delivering quality software.  It’s worse to plug in weak struts in the code base that will just collapse when the next developer builds on top of it.  Very un-ubuntu!

So, the Beatles song still holds true, but only for social scaffolding.

Yeah you, got that something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand
I wanna hold your ha-a-a-a-a-a-and

Most agile people say big designs up front rarely pay off.  You spend so much time doing design that you delay the opportunity of feedback from real, working software.  But I sometimes do BIG DUF.  It’s not that the design is big, it’s the problem that is big.  So I need an up front big picture with just a few big parts.

It helps me conquer and divide.

That’s not a bad thing.  What I find really painful is casting the design in concrete.  When your design is cast, then your mental state is already cast in concrete too.  And that means that it is a lot harder to do the right things.  So, more gets added to the concrete slab and it’s real hard work to break anything off.  When I have a BIG DUF, I often look at how to reduce it, rather than increase it.

I don’t think it’s wrong to have a  BIGDUF, it’s worse if you have a BIGDIC (BIG Design in Concrete).  That concrete block will hurt you later … a lot.

In other words, the size of a BIGDIC does not matter, it’s the rigidity that’s the problem (– That’s so lame, I could not resist!)

If you hate reading lengthy blog posts and dig the mind map view of the world, then add Steve van der Merwe’s blog to your feed gadget.  What I really like is his short quick observations and great views about software development.  But for me, it’s even better that I get to speak to him regularly, in person.  If you’re in the Cape Town area, make a point of finding him and chatting to him.  He makes ubuntu real.

Trust has popped up in so many of my conversations recently.  It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course.  And I got a one line email that said this.

The entire world lives on trust. Every aspect in life moves with trust.

The more I think about situations in life that will prove this statement false, the more it seems to hold true.  Even in design it holds true.  Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.

It’s true for code too.  If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.

I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up.  Here again, aspects and the classes into which they get woven, need a trust relationship.  It may seem like a stretch to make that statement, but I think it holds true again.

So, how do you gain trust?  I am not sure, but I think you have give up something first.  Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space.  Then, perhaps, they will let you in to their space too.  When ego walls are erected, then trust finds it hard to grow.  By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear.  Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.

In code, trust lies in interfaces and types, not in implementations.  It’s really about trusting the implementation that makes types worthy.  When you trust the type and send it a message and it behaves as expected, then you trust it.  If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type.  You don’t hope that it does behave consistently, you trust that it does!

Trust is tied in with ubuntu too.  You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them.  I think ubuntu coding needs trust as one of it’s values.  It’s already a value in XP, and Scrum, and families.  It needs to be in teams, and organisations, and communities and nations too.

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.