Tag Archives: agile

Trust Everything

Posted on by

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.

Introducing the A-* Stack

Posted on by

Nowadays, software architecture and agile methodologies seem to be inextricably inter-twined. Everytime I have a chance for geek-talk with a bunch of software architects, there is always someone that will throw in some of the softer issues that deal with how we run our projects, how do we estimate, something about big design up front no-no’s, YAGNI, DRY and other buzzwords. Since architecture is full of metaphorical stacks of many kinds, I thought it might be useful to invent of an agile stack. Humor me, and let’s call it the A-* stack 🙂
I think there are several layers in A-*. I have no idea what is stacked on top of what, but Here is my A-* stack as I think of it right now, and we’ll try and refactor it later to gain deeper insight into the layers of responsibility and order that must evolve out of the chaos.

  • People Layer: This layer is responsible for establishing a team ethos. It is vital to creating a common work ethic in the team, shared values and principles. It is the lowest common denominator. In high conflict teams with high discord, things fall apart easily. Under these circumstances, you need to drop to philosophical introspection of your team values such as honesty, respect, reasons for existing on the project/or building the solution.
  • Project Management Layer: Managing a project founded on agile practices, even those that use agile practices partially, is no easy task. There is a dedicated layer of responsibility that keeps track of project velocity, prioritization of stories, facilitating feedback and managing change. Sure, we embrace change in agile projects but it still needs to be managed within the prioritized list of stories and other constraints of the project. This is different from traditional PMBOK style project management and deserves its own layer of responsibility.
  • Development Layer: This layer embraces the technical practices of the software developers. It includes niceties like continuous integration, test driven development, code refactoring, single code repositories that guarentee one version of the truth. This is, perhaps, the one layer that is best understood and have tangible actions at the code face.
  • Architecture and Design Layer: This layer is more than it’s really cool acronyms like YAGNI, DRY and BDUF. The focus is on gaining deeper insight into the problem domain. It very likely shares a gray and fuzzy area with the Development Layer and that’s ok. It really doesn’t matter that we have spillage into the development layer or vis versa. As long as we focus on gaining maximum understanding of the problem domain and modelling the solution as simply as as is possible.
  • Run-Time Layer: This is an oee one that I’ve dwelled on for a while. Sometimes the run-time environment really gets in the way and obstructs fluidity and rhythm in the development and architecture layer. It may well be the least agile of all layers in A-*. So, choose wisely … if you can. Let me explain a little further by example. The Ruby on Rails folk have made many screen casts that show how you can change code and you can just reload the page and, magically, the change is visible. Now compare that to someone writing EJB’s. Write, package, undeploy, deploy … it’s just painful, even if you are POJO+TDD inclined. The EJB container will bite you, eventually. So, in some respects the RoR runtime is more agile than the EJB runtime. (Aside: I think the only agile runtime in Java world is OSGi because it supports dynamic loading and unloading of classes and multiple versions classes in the same namespace. Now that’s agile!)
  • Environment Layer: The place where the team work is an equal contributor to agility. From how your workpace is layed out to desk configurations in an open plan office space, it is significant. Audible and visual communication is important and this may overlap ever so slightly with the people layer. I think the environment has a dedicated layer of responsibility in A-*.
  • Toolbox Layer: The tools you use can help you become more agile. I find that a flip chart, white board and multi-colored markers keeps me fluid and helps me progress rapidly, especially when I am working in the Architecture and Design Layer. We all have our special favorites that include the full blown IDE with our special key bindings, code diff tools, and even specialised items like shared whiteboards. I know of one team that has a Skype bot that acts as their JIRA interface – chatting to thet Skype bot allows them to update statuses and query JIRA. What tool ever keeps you agile has a place in this layer.

Perhaps, you have some other thoughts about what goes into A-* and what should be taken out. Maybe you have some real world insights that go beyond my meagre learning experiences. Drop me a note … I really would like to know how your A-* stacks up.

Behaviour Driven Development at Cape Town Geek Dinner

Posted on by

Earlier this year I got to hear about Behaviour Driven Development from Dan North at the Software Architecture Workshop in Arosa, Switzerland.  Since then, I’ve been using BDD to various degrees on various projects, and I have to say that it works for me.A few nights ago, I presented BDD at the July GeekDinner in Cape Town. I had no idea how this approach will be received, but I was quite surprised by the interest and chatter that I had with others after the talk, especially around rbehave. I wonder how the conversation would have turned out had I used JBehave examples instead?The rest of the GeekDinner was, as always, an interesting mix of techie, geeky things. Jonathan Hitchcock has a nice wrap-up of the evening.Download my presentation here (PDF format).