Category Archives: Software Development

Two Angles to Sustainable Pace

Posted on by

At the Scrum User Group South Africa meeting last night Marius de Beer did a really good talk about Software Development Practices.  It’s been a long while since I saw anyone attempt to draw so much from such widely spread corners of wisdom.  In one slide Marius mentioned the practice of Sustainable Pace.  Many take the view that this is about cutting back on working overtime and that it supports the principles of energised work, and work-life balance.  Marius did make the same point, and it is correct.
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.

Flowing in the Waves

Posted on by

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.
Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

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.

Fat is the new Thin

Posted on by

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.

Stranger Danger in the Cloud

Posted on by

There will always be someone who will scream that Cloud Computing is new.  And there’s someone else that will tell you it’s old-school-been-there-done-that.  And there will always be some vendor that will try to sell something too.
Since we shrink in body and mind to the state of children when thrown into a new context, beware of stranger danger.  It’s tempting to follow strangers for cheap candy in the cloud.

And yes, like SOA, we’ve seen and done this before.  But I think it is important that we let the passage of time to gel our experiences and ideas over and over again.  Why?  Because contexts change with time and we can use new contexts to innovate again and again and again.

You’re allowed to think … for yourself … and decide … for yourself.

Launching the Services Support Group

Posted on by

“Hello.  My name is Hope and I am a Service.  Last week I was asked by a View to do something.  I told the View that I can’t do it.  So he asked the Fat Controller.  The Controller sent me the same message and I just took exception.  What kind of service does he think I am?”

“Hello Hope.  We are glad you joined us.  You are not alone.  Look around the room.  We’re all struggling to find our own identity.  Those of us that have been around for a long time are still recovering from being forced to convert DomainObjects to DTOs.  The more recent ones feel like meaningless proxies, and last week we had a guy who thought he was a Service but he was just a HelperClass.”

“It’s as if I am losing touch with reality.  My own DomainObjects don’t even interact with me directly.  Now processes want a piece of me too.  I think I am schizophrenic.  Am I now a process?  A wrapper point for Transactions?  I swear to you, there are days when I even think I am a stored procedure!”

“Ohhhh, noooo!”

“But I know who I am. I am a Service.  I like working with DomainObjects.  They need me.  Somethimes they can’t do everything on their own, so I help out.  I complete their world and it makes me feel like I belong in the right place.  One guy even refactored me from the domain package to a services package.  Can you believe that!  Actually, now that I’ve said it aloud, I am not surprised that I feel more and more disoriented.”

“Disoriented?  Oh boy, we really can’t help you here.  You see we’re recovering from abusive Controllers and Views and when you told us the story in the beginning, we thought we could help you but you’re just a …”

“But that story is true.  Apparently there was this Process on other side of  this MessageBus that needed something and he asked the Fat Controller who got involved with View and then I got sent this message and …”

“WTF?!!  The Process asked the Controller…”

“Yeah!  You won’t understand … it’s after your time.  It’s really a WebServices Controller but I hear that he also feels abused and just wants some REST.  You think there’s a support group for Controllers?”

“Wait.  I remember this other crowd … uhhmmmm … sorry – those weren’t Controllers, those were Presenters working with Models and Views, but I used to be confused as a Delegator and I can …”

“You’re NOT HELPING!!!  I told you I am a Service!  And I am confused!  I want to be part of the domain again!  I feel disoriented!  And I …”

“And I told you that we can’t help you.  The truth is that you are DOA.”

“Dead on Arrival?”

“No! DisOriented Architecture.  You know … they don’t know where to put that, so it becomes a service.”

“But, but … I am a Service … <sniff>”

“YOU WERE NEVER A SERVICE!  YOU’RE ONLY HOPE!!!”

Balancing craftmanship and methodology

Posted on by

Carlo Kruger commented on my last blog post with reference to Martin Fowler’s blog post which is a concise view of a crazy blog and twitter war around software craftmanship.  For some reason, Carlo thinks that my last two blog posts (here and here) fall into this space. Either Carlo is baiting a hook for fun 😉 or he misunderstood me. Nevertheless, my dear friend, I shall reply.
Martin Fowler and Dan North put the customer’s derived value from the software as the focal point.  The craftmanship movement puts the code that derives the value as the focal point.  I don’t feel comfortable about either.  It is unbalanced.  We always need balance.  So, what will provide an equally powerful balancing force to either of these two focal points?  I think it is the economic viability of the code base.

In Let scrum die, the key message is that Scrum should not be the end goal but a means to get somewhere better.  At some point it will outlive it’s value and I propose a moment in time when that will happen, and one way to force this (i.e. plan the exit of the Scrum master).  I also describe “talented developers” which, perhaps, feels like a craftmanship-esque thing.  It’s not about that at all.  It’s about the balance that is described in the next to last paragraph: developers will represent the interest of the customer, and the code base is under control (i.e. it is economically viable).  Balance the focus of methodology with an the economic viability of the code base.

In You can’t let Scrum die, I draw attention to this lack of balance that leads to complacency.  I mention two craftmanship things to do with the code – remove duplication and express intentions.  Again, it’s not about this alone.  It’s about the balance that is needed.  That balance is described in the next to last paragraph: look at yourself and look at what you create (i.e. the code base).  The reason why I say look at the person next to you is because the economic viability of the code that you create will affect that other person also, including the entire organisation and its customers.  Balance the craftmanship with the methodology which is balanced by the economic viability of the code base.  This reduces to balancing craftmanship with the economic viability of the code base.

There is one area where I don’t know of a powerful enough balancing force.  In Politics of Software Delivery, I draw attention to organisational power grabbing that will always result in non-delivery.  I suggest raising the importance of the delivery value.  But I think this is still too weak a force to balance the power battle.  I don’t know how to fix that one.

Footnote: Jimmy Nilsson reminded me of an article he wrote about why TDD, Refactoring, DDD, and all such things matter.

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.

Patterns at the September SPIN Event

Posted on by

I suspect that many people did not understand what I meant about forces at play and that patterns describe a solution to bring some harmony among the forces in the problem in a particular context.  For the example of the airplane and wanting to serve the right meal to the right person, the challenge is to serve the meal without knowing about the seating arrangement on the plane, and still sequentially access each seat.  Let’s look at how to get rid of the need to know the seating arrangement.
We start with the solution where we need to know the arrangement of seating and number of seats too.  BTW, it’s ruby code.

for row in (0..29) do # 30 rows
    for pos in (0..5) do # seat A-F
       passenger = airplane.seats[row][pos]
       next if passenger.nil?
       passenger.serve_meal("nut free") if passenger.meal() == "nut free"
    end
end

Of course, if we know the seat number, for example, 15C, then we can do this.  But that does not help at all.

airplane.seats[14][2].serve_meal("nut free") if airplane.seats[14][2].meal() == "nut free"

But, we still expose the data structure of the seats.  So, let’s make it a little better by using the iterator pattern on the data structure for the seats.

airplane.seats.each do |row|
  row.each do | passenger |
    next if passenger.nil?
    passenger.serve_meal("nut free") if passenger.meal() == "nut free"
  end
end

We could be cuter and do something like this and hide the seats array, but we still expose the numbering scheme of the seating.

airplane.serve_meal("15C", "nut free")

So, we can have the iterator on the seats data structure, which helps a bit.  But we can make it a lot better if we put an iterator on the airplane itself. Now, we just care about occupied seats.

airplane.each_occupied_seat do |passenger|
  passenger.serve_meal("nut free") if passenger.meal()
 == "nut free"
end

In the airplane class, we have the following.

class airplane
  ...
  def each_occupied_seat &block
    @seats.each {|row| row.each { |pos| yield pos if not pos.nil?} }
  end
end

We are using iterators on the encapsulated seats structure and exposing a new iterator for the airplane. Also, we are only work with seat that has a passenger

So, we started out with a deep need to know the structure, layout and limits of the seating in the airplane. Then we started hiding the data structure for the seats, put iterators on this seats data structure which helped a bit.  But the real breakthrough happened when we started asking the airplane to just give us a way of sequentially accessing each seat that had a passenger.  No more conflicting forces, just a simple harmonious way to access each occupied seat on the plane.  And when the plane seating changes, we don’t care.

Intention Revealing Names

Posted on by

Update: A small elaboration of this has been published on the Architects zone at DZone.com.  Read it at http://architects.dzone.com/news/intention-revealing-designs.
The value of naming of variables, methods and classes is highly underestimated. Given that code is read more than it is ever written, the readability of your code will get more attention than your original thought process that led you to the code. I will be so bold as to say that the reader really does not care how you arrived at those lines of code. The reader is actually focused on what you mean by the code and not how it does its magic.

Often the problem lies in carrying implementation details into the name of the intention. For example, assume you have designed a social network as a directed graph and you want to find all circles of friends that are in this social network (e.g. Joe knows Mary who knows Peter who knows Joe). Since it’s a graph, we can find all cycles in the graph, or closed loops. So, you write code such as:

class ObjectGraph {
  public Collection<CyclicGraph> findCyclicSubgraph() {
	  ...
  }
}

class CyclicGraph extends ObjectGraph {
  ...
}

This does not reveal any intention of finding circles of friends nor does it surface the domain adequately. The same code with intention revealing names just reads better:

class SocialNetwork {
	public Collection<SocialNetwork> findCirclesOfFriends() {
	  ...
	}
}

There’s a subtlety hidden in the refactored code. Both the circle of friends graph and the graph of the entire network are of the same type. SocialNetwork is a composite and has the advantage that all operations executed on a composite will yield a composite of the same type as well. In other words, all operations on SocialNetwork will yield another SocialNetwork. That is also intention revealing design as well as a bit of suppleness.

Here’s another example. You wish to set a boolean to indicate that an object is dirty in your cache.

public void setDirtyFlag(boolean dirtyFlag) {
	this.dirtyFlag = dirtyFlag;
}

But refactored with intention revealing names, the purpose is now explicit.

public void dirty() {
	this.dirtyFlag = true;
}

public void clean() {
	this.dirtyFlag = false;
}

Whenever you are writing code, ask yourself: “Is my intention clear and unambiguous?” If the answer is “No!” then your code is most probably lacking readability. There are refactoring techniques and many patterns that can be used to increase the suppleness of your design, but just spending a few extra brain cycles on the names that you use in your code can make an enormous difference in displaying your intention and not your implementation. This alone will increase readability and reduce maintenance of your code.