Oh, I guess I’ve got to do something about the site layout again.

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.

Here’s a few splintered thoughts from my email exchange.

• Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
• There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
• Code from my heart because I should trust myself first.
• Be part of the exploration, not just an observer.
• This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
• Passion is constant whether I succeed or fail.
• Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
• The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.

Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing.  I am not sure what I will uncover in this exploration, but I know that it will be very personal.  I don’t even know if it will be worth sharing, that’s why I am sharing so early.  It just felt right.

I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.

PS: I don’t think Jimmy will ever ask me a “How’s life?” question again

No collaboration, no heroes!

I thoroughly enjoyed Karen Greave’s talk on Agile Testing.  She had just about 100% coverage (pun intended, groan).  Yet, testing is really a pain in the rear.  Testing is execution, and Karen was dead-on right, that automation is the path to follow.  Computers are very good at testing.  A computer does what it is programmed to do, and it can test the way it was programmed to test.  It’s simple: if testing is your constraint, move that constraint away from testing by automating.

Now, you have to deal with the constraint that shifted to the next point: test authoring.  While testing (i.e. execution) is just a passive, laborious effort, test authoring is a very creative, active exercise.  It is actually an exercise in confirming a shared, common understanding.  Kristin Nygard said “To program is to understand” and test authoring is a programming exercise.  That’s why outside-in, behavior driven development style scenarios are actually tests, coded in a human language.  The act of authoring a scenario proves your understanding and the expected working of the software.

This is why I separate test execution (passive) from test authoring (active).  And Karen said that early feedback is good (right again), which is why I author my tests very early.  I’m extreme about this.  I test first.

Automation creates time for collaboration

But there is another angle to Sustainable Pace.  As a developer, you need to build a rhythm, or flow.  It’s a cadence that you establish as you are writing code.  It’s a cadence that TDD helps you establish itself.  This cadence is also sustainable pace.  And one thing that kills this cadence and your pace in a flash is a mid-stream meeting.

In the panel discussion afterwards, there was a question at the end regarding ways to reduce the number of meetings which I just glossed over.  If you schedule meetings with developers for only the first hour in the morning, you not only reduce the number of meetings but, also, you don’t destroy the sustainable pace built up from the morning.

So, don’t think about pace as just working 7 hours a day, it’s about what you do in the 7 hours that matters.  Get the rhythm going and be anal about things that can kill your flow mid-stream; especially meetings.

DevDays 2010 in Cape Town was slick.  Very slick.  You guys really know how to put an a good show.

Most of the speakers were good.  Most demos were good.  Most jokes were funny.  The food was mostly good. The mood was mostly good too.   And the fan club was mostly impressed.  And most noobs were converted forever.  And the new features were mostly so good, apparently, you won’t have to write so much code anymore.  And the most underused word was design.  Most absent words were TDD, refactoring, quality, and clean!!

I understand that DevDays is a product showcase but, come on, MS South Africa, at least cater for the entire spectrum of developers, just a little bit, and in a responsible manner.  How about pitching content that shows that you do care about design, about clean code and quality.  How pitching the new features in a way that shows a trend towards agility, to being able to refactor code continuously,  to test first and other vital aspects of professional software development.

Let me give you just an example to illustrate what I mean.  The EF4 code first demo was explained completely as if the classes in the model are no different from entities in a table.  Even the language used was “entities” and “keys”.  I don’t think I heard the word “class” or “object” once!  You may have slides with the words “Code First Model”, but if you don’t actually do it for real, then you’re just leading dataset-happy developers that are marginally object-oriented further away from good code and good architecture.  You need to explain why it’s better:  that it promotes better object orientation, that POCO models disconnected from an ORM can be done test-first, and you can evolve your model, instead of designing up-front, blah, blah, blah.

Another time there was a ping-pong table with a developer at one end and tester at another with a bug being batted between them.  That pulled quite a laugh from just about everyone.  While that is reality in many organisations, there are many of us that test our own code and deal with our own bugs.  The tester that we toss our code to is our automated continuous integration server.  Tossing code downstream when it’s too late for reprise is not very professional.  How about focusing on the testing tool, as opposed to pitching it in a manner that makes everyone believe that dealing with the bug downstream is just the way its meant to be.

Sure, I know that you need to show off the latest cool things and evangelise your products, but there is a sector of developers that you are blatantly ignoring.  It is the sector that is, perhaps, the most influential amongst other developers. We are those developers that value our craft of software development.  We evangelise the craft and the value that it brings to our lives, our teams, our projects, our clients and our organisations.

Perhaps I am just delusional.

Oh well, so long and thanks for the fish.

A couple of months ago I ran into OSGi again, but with SCA on top of it.  Horrid!  SCA is yet another warm and huggable specification.  But it’s so ugly to work with.  Everything feels so over the top complicated and restrictive in expression.  And the tools that I saw built on this SCA implementation were just awful.  Beyond being buggy, the enforced paradigm was just counter-productive.  When will tool vendors realise that talented developers do not want a diagramming interface to write code?  But the root cause is that the SCA specification describes the diagramming notation. Yuck!  Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.

And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.

More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall.  If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?

Why?

There are deep lessons and principles lurking beneath this surface.  Agile demands you to be a lot more aware of actions, decisions and consequences.

So why do you choose not to be agile when you are trying so hard to be agile?

So let’s try a weird-ish thought experiment.  You’re in such a project and you’ve reached this point.  You are about to start the dead last sprint and then it’s over.  The team will be disbanded, but the software will live on.

You have just one more opportunity to work on this product, with this code base, with the people on this team.  Your legacy is in this software.  Every decision you made is sitting in a vast time line of deltas in your version control repository, all the way back to day 0.

What do you choose to do in this last sprint?