I often hear developers, and managers too, saying “It’s so much easier without, so why bother?”.  Well, design is hard.  Applying principles for life is harder.  But if you are professional developer and have a conscience about your design, your code, and your product then “an easy life without principles” is not an option.

If you are planning to come along, bring your laptop with your development environment.  I will likely have code samples in Java, C#, Ruby, Javascript, and even, yup, Basic (well, maybe).  All the samples should be very readable and you could easily translate them to something equivalent in your language pretty easily.  Better still, bring some of your own code along, that you want to share.

In reality, this is stuff that Scrum does not teach you, but need to know to avoid Scrum burnout.  Looking back, I should have done something like this sooner.

Software development is about people and the way people work alone and together.  People create code in software development.  Without that code, these people don’t exist; they have no purpose.  Code is the creation of the people, and people live off this code.  When the code is good, then life is good.  When the code is poisonous, then people start dying slowly.  When the smell of death is in the air, they look for help.  Some stare into the mirror called Scrum. They see themselves and the way they behave.  It’s an ugly sight.  They realise that they should behave better.  After all, software is about the way people work alone and together.

Regularly looking into the Scrum mirror, they improve their behavior over time, and everyone is happier than the moment before.  That’s a nice view.  Just look in the mirror and it looks good.  Very rarely do they also look again through the window into the fields of code that feeds them.  The poison is still coursing through their veins.  They will die, eventually … by the host that they created that was supposed to nourish them.  The only way to survive is to deal with the fields of code.  Get rid of the toxins.  There are two fundamental ways(*) that you can get rid of toxins: (a) eliminate duplication, and (b) make the code as you wish it to be.

If they just stare into the mirror and hardly ever look out the window, they will just exist on the plateau of complacency.  In order to avoid that state of being, they need to focus on the fields of code.  The urge to look in the mirror is strong, and as useful as it was, it becomes a very unbalanced state of existence.

So, look in the mirror, but look through the window too.  Create fields of code without toxins so that you provide nourishment for the next person.  That is ubuntu coding.

Actually, the only mirror you need is the person working next to you.

(*) Think deeply about these two fundamental things and try it out.  Everything else will fall into place from this. For example, the act of eliminating duplication forces you to consider where to locate a single piece of code, how it should be used and where it can be used, etc.  That is design and architecture.  With duplication, you don’t need to consider any of those things.  That’s toxic.

Regardless of the hyper-performing tagline of Scrum, each team settles down to something with which everyone is comfortable.  The big change that has happened is that of changed behaviour.  Scrum does that – it alters behaviours.  When everyone plays by the rules (i.e. they behave consistently) then you don’t have chaos.  It’s better than better – it’s just nice!  It is very comfortable.  But I see signs of chaos not far away again.  This is what is happening and it is almost without exception here in Cape Town.  Some are off the table top already.

Let me make the Scrumvangelists feel better for a brief moment.  Scrum won’t kill you  - directly, but your adoption of Scrum can kill you if you ignore one thing – your code base.  It is a code base out of control that leads to certain death, and Scrum won’t be the saviour this time.  Bringing your code base under control is not easy.  It is all about architecture, design and changing your style of development to live the principles that end up characterising good code.  I don’t need to tell you what you need to do.  It’s been told so many times – TDD, refactoring, continuous delivery, single code base, etc.  At the code face it’s SOLID and DRY and lots more.

The plateau of complacency is an interesting place.  We may think we are collaborating but in reality we have just found a way to work together without causing chaos.  I call it co-operation.  It’s just keeping chaos under control so that we can make the sprint, again and again and again.  A sure sign of being on the plateau is when we can’t get rid of our Scrum master.  When we work the Scrum master out of the system, then the team will need to take on more on it’s shoulders.

A major limiting factor to get off the plateau will be the people on the development team.  Hyper-performing teams have talented developers(*) that are able to design and express that design in code without breaking their principles.  A team that is unable to bring a code base under control will compensate by leaning on a scrum master for support.

In the journey of dramatic improvements to bring your code base under control, there are few things that you should take notice off.

• An architecture will emerge that supports the design of the resident parts.  Things fit together beneficially.
• The code base will get smaller and the team will shrink to about 2 or 3 people.
• Each developer will take on greater responsibility and will find it difficult to break core principles.  The act of living those principles will result in a values that don’t need to be listed on a poster on the wall.
• The scrum master will become redundant.
• The product owner will do more by working directly with the developers.

Then you won’t need Scrum, because the code base is under control, developers represent the interest of their customers, and the bottleneck is now at the customer.

Am I being idealistic?  No, it’s about pragmatic decisions and the pursuit of freedom.  It’s hippie Scrum.

(*) By talented I mean developers who have the ability to communicate, share, solve problems simply and elegantly, and can sniff out bad design and architecture.  Talented developers are not code monkeys that can churn out code.  Their single differentiating trait is the ability to design well and express that design in code.

Application state is in the head of the consumer, not the provider of the resources.  This suggests that we should be able to recompute the state of application at any time.  If we can recompute the application state, then we don’t need to explicitly implement the entire application state machine in the provider, nor the client.

You may start off with modeling an application state machine on paper and discover the life cycle of resources.  Implementing this is then simpler because we are only need to implement the lifecycle of the resource, not the entire application state.  The way the consumer drives the state machine is just be reacting to available transitions in the representation of a resource.  Now you give the provider the freedom to change the application state machine and the consumer will react to the new state machine by discovery. That is significant.

Use hypermedia to refer to yourself. This came up in the tutorial because I objected to a resource including a hypermedia link to itself, regardless of its state.  To me, it seemed to have little value because you already have the representation of a resource in a particular state, so why include hypermedia for itself.  For example, this is what a resource will look like without a link to self.

<Order>
  <id>823763</id>
  ...
  <links>
    <link rel="pay" href="http://example.com/payment/823763"/>
  </links>
</Order>

Now, if I want to GET the original order resource, I would need to know that there is some URI that includes the id of the order.  And, so, we end up publishing a URI template such as

GET http://example.com/order/{id}

If we include a link to self, then the representation looks like this.

<Order>
  <id>823763</id>
  ...
  <links>
    <link rel="self" href="http://example.com/order/823763"/>
    <link rel="pay" href="http://example.com/payment/823763"/>
  </links>
</Order>

Look Ma!  I don’t have to expose a URI template anymore.  It’s all discoverable.  That is significant.

REST support in WCF is heading in the right direction. I also listened to Glenn Block’s talk on his team’s work on HTTP and REST support in WCF.  It’s still early days but I think they are paying attention to experts in this space and giving priority to the developers that will use it.

In the past you would have to map a very specific, template based HTTP GET operation to a method like this (excluding the additional endpoint configuration too!)

[WebGet(UriTemplate = "{id}")]
public Contact Get(string id, HttpResponseMessage resp) { ... }

What Glenn showed was a method signature that resembled the HTTP operation on the resource.

public Contact Get(string id, HttpResponseMessage resp) { ... }

Sure, it’s using a lot of convention over configuration to get rid of the attributes.  Now that may not seem like a big deal, but I do think that it is moving the HTTP abstraction down to a level that is more resource friendly.  When you are building a RESTful architecture, then you do think quite naturally in terms of the resources and their allowable HTTP operations for obtaining state or triggering a state transition.  By moving away from mapping HTTP operations to a service contract, it introduces the necessary mental shift from RPC to Resources.  And that is significant.

http://www.asterix.com

My son borrowed Asterix and Cleopatra from Claremont Library last week.  It’s been ages since I read anything from that series.  But page 2 really had me chuckling.  There is an image of the page online, but it’s bit hard to read.  So, here’s the dialog.

The scene: Cleopatra has been challenged by Julius Caesar to build a grand palace that will prove that the Egyptians are an advanced nation.  She summons Edifis, her architect.

Cleopatra: Edifis, I have summoned you because you are the best architect in Alexandria – which is isn’t saying much.

Edifis: Oh!

Cleopatra: Don’t answer back! Your buildings are flimsy.  You can hear every word the neighbours say.  The ceilings fall in!

Edifis:  It’s these modern materials… Actually, what I really want to do is build pyramids and …

Cleopatra: Silence!  You have just three months to make good.  You are to build Julius Caesar a magnificent palace here in Alexandria.

Edifis: Did you say THREE MONTHS?

Cleopatra: If you succeed, you will be covered in gold!  If not, you will be thrown to the crocodiles!  You may go.

(Edifis walks out)

Edifis: (thinking) Three months!  I’d need supernatural powers to do that!  I’d need someone who can work magic.

Edifis: (shouting) Got it!  I know the very man!  He can work magic!

Now, where have we seen that before?

(And just get the original book and read on about mule-driving the slaves to haul huge blocks of stone … classic!)

So here are some of the things that surfaced at the Forum, and my narrow, unworldly opinion on each (i.e. I’m just trying to fill that hollow feeling).

When we talk about architecture, we need to define what we mean by architecture?

In my talk it was a very simple view of architecture which, thinking back, I should have disclosed very early.  I am now applying from Kent Beck who talks about mutually beneficial relationships.   So I think of architecture as the mutually beneficial relationship between two or more things.  So what is a thing?  It could be  lines code in a method, methods in a class, classes in namespace, namespaces in code base, binaries in an application server, application servers in a cluster, … see where I am going?  Architecture is about creating beneficial relationships, and the 5 things I discussed are based on this view.  If you don’t know anything about the things, then you cannot create beneficial relationships.  From an agile perspective, the beneficial relationship that you create should only be beneficial based on your knowledge right now.  Tomorrow your knowledge changes, so the relationship may not be as beneficial as yesterday.  Time to change.

Building infrastructural architecture independently of functional requirements…

I am not convinced of the benefit of this approach.  In my limited experience, every business need defines the constraints or needs of the infrastructural architecture.  I find it hard to find the point of departure, yet there is a school of thought that suggests that function is orthogonal to the architecture.  Perhaps I just don’t understand this.  However from an agile perspective, I want to release early and there are many constraints on infrastructure from the business (for example, administrative processes like procurement of hardware).  I like to understand what these are early on, reach agreement on what we can release at the earliest and design accordingly.  Perhaps the first release is on lightweight infrastructure and that means we “limit” scalability.  So, I don’t design for beyond what I know is real.

Model Driven Architecture …

My view is more philosophical and abstract.  What is a model?  For me, a model is something intangible.  It is a way we understand something.  But we represent our models in many ways.  Through words in written or spoken conversation, in unstructured pictures, in structured notation like UML, even code is a representation of a model.

What do we mean by driven? I view it as a something that takes an input that produces an output.  In this case, we take an input, the model, and produce an output, an architecture.  So, I take an understanding of problem and use that to derive an architecture.  So, that’s nothing new here.  However, I don’t like to confuse driving out an architecture from a representation of the model.  That’s different.  Now we are going beyond thought processes  into mechanical processes.  Then the challenge is about how to apply the feedback to the representation of the model – and that is what will make you agile.  Too much for my small brain.

Plumbing …

Yup, we do too much hand crafted plumbing!  It’s something that we have been working on for a long, long time.  I think convention over configuration, dependency inversion, meta-programming are all attempts at addressing this problem.  Some early success that I have experienced is on taking a polyglot approach. I am not talking about mixing general purpose languages on one runtime only.  I am also including domain specific languages. I’ve had some early success where using DSL to describe functional intentions and then generating a large portion of the plumbing.  Where I’ve suffered is when I mix concepts from different domains.  There is the domain of plumbing and the domain of the business.  Whenever I’ve mixed the two, it pains later rather than sooner.  Right now, the only way I’ve had some success is with aspect orientation and meta-programming.

@StatelessSessionBean …

Chris Naidoo is right.  That thing called J2EE and subsequent versions is just horribly broken.  It’s broken encapsulation and a whole lot more.  The fact that we now must use an annotation and not implement an interface is immaterial.  Both result in the same pain – mixed concepts (see plumbing above).  Annotations should be specific to the business such as @RecalculateCostsOnRerouteOfCargo can be used as an interception point for injecting a rule on a class or method.

I would go even further and say that the POJO JavaBean specification is also broken.  Why on earth must I have a no-argument constructor and accessors and mutators.

Last thoughts …

I may have missed some of the other discussions but these are the ones that I woke up with this morning. In general, my observation is that we need to be very concrete very early if we want to be agile, even in architecture.

Technical debt is one of those metaphors that have been extended so far, that it is believed by many to be something tangible.  Let’s get real here:  Technical debt does not exist.  It is just a metaphor for us to realise that our code base may cost us more money than it should, and that is a future view.  Sometimes our metaphors become euphemisms, and then it is dangerous.  When it comes to technical debt, the less I think of code problems as debt the more I am able to face the problems head on.

Ironically, I did a talk recently on dealing with technical debt.  My fundamental position is simple.  Either your code base has things that exist as a result of broken principles or it does not.  The more principles you break, the more potential problems you have in your code. It is not a problem right now, but it may be a problem in the future.  This future can be a minute away when I run my next test or a year away.  If the future is infinitely far away, then it is not a problem at all.

My first prize is to not break principles, so I don’t create potential problems.  My second prize is to deal with real problems and just leave the potential problems for the future.

(Warning: I’m drifting into my enlightenment self-reflection, so feel free to stop reading now.)

If I am part of the exploration that is looking for a solution (living in the moment and not outside it as an observer), then I should be aware of principles that I am breaking and I should change course immediately.  If I am part of the exploration that is dealing with the potential problem that is now a real problem, than I need to understand the principle that was broken and fix the problem by restoring the principle.  Restoring the principle could mean going on a search for the right solution to the original problem, not just trying to fix the problem that is a result of breaking a principle.  This problem that broke the principle may just be the wrong solution that we thought was the right solution because we ignored our principles in the first place.

Hmmm, that’s an interesting thought.  Karen Greaves asked me if a re-write can be justified and I mumbled something about technology, etc.  What tripe!  Now I think I’ve just reflected on when a rewrite is justified.  When refactoring will not fix the broken principle, then the right solution was never discovered in the first instance.  That is also what I mean when I say that clean code is necessary by not sufficient.  At factor10, we call this a radical makeover.  Radical makeovers are a viable way of getting rid of real problems, and restoring principles.

Heck!  This blog post is less about technical debt metaphors than I thought.  Oh well, the ride on this journey never stops.

By the way, a huge thank you to Steve for helping me realise that all problems come from breaking principles, in code and in life.

But, I think I am equally excited at the possibility of seeing some familiar faces again in Johannesburg.

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

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!)