Redgate Open Space — Coupling, UX, and Messaging
Last Friday, Redgate ran its first Open Space Event, and as a proponent of Open Spaces I was eager to see how this would work within Redgate. I was worried that people wouldn’t be willing to propose sessions to this new and potentially scary format, so I’d got a fair few sessions up my sleeve. Thankfully, the event was a success, lots of people turned up and there were lots of varied topics and people seemed to be engaged.
Session 1 — Connascence
I was introduced to connascence at the SoCraTes Belgium unconference earlier this month and found it an interesting tool for describing coupling in a system. Connascence comprises of three axes:
- Strength — a measure of how easy it is to discover the Connascence, or how hard it is to refactor it. We should be favouring the weaker connascences.
- Degree — how many other entities is this entity connascant with? The higher the degree the more difficult this connascence will be to change.
- Locality — prefer connascant entities to be closer together than further apart (think functions, classes, modules, etc.).
We cannot eliminate all coupling from our systems, without any coupling none of our code should run, but we should be favouring the weaker, localised connascences with links to the fewest number of entities.
I ran through the Checkout Kata discussing the different types of connascence we could find at each stage and using the connascence to guide us to order the refactorings we can takeand importantly when to stop refactoring.
I am finding the language of connascence takes a bit of getting used to, like all new things we can take this too far (e.g. does the fact your language allows nulls introduce connascence of meaning into your system?), but it gives a common language for explaining coupling.
Session 2 — Integrating user experience research in development?
Sometimes on teams there can be a bit of a strain between the need to learn, to know what to build, to know what we are building is right and the, often internal, pressure developers feel to build something. Each team at Redgate should have an User Experience Designer to help us do the research and produce the best experience for the customers. Yet, sometimes we feel a tension between researching and learning. I found the discussion engaging and open and, in the Open Space tradition, carried on after the end of the session so I missed anything in the 3rd session.
The two main issues that stuck in my mind the most were:
- Developers want to be building something, often finding research “slow and time consuming” that takes them away from coding.
- User Experience Designers feel the pressure to “get it right first time” because once the piece of work is finished.
The two main issues can result in an anti-pattern, “we’re entering a user research phase” which means the developers feel they have to “down tools” until the designs have been finalised and the user experience designers feel like this is their only chance to get it 100% correct.
In the end both groups want the same thing, to deliver customer value quickly and consistently (i.e. without incurring too much technical debt, or design debt).
User Research and Development are not mutually exclusive, the early stages of research for a new feature should be running in parallel to the development of features that we have validated. While we are developing a feature we should be getting feedback on slices of the functionality to guide the development and when we are satisfied the feature is good enough we should be gathering usage data and feedback from users in more passive means occasionally revisiting the feature.
Session 4— Modelling message queues with humans
This was a very interactive session where people had to move around and play the roles of different parts of a system, though a little rough around the edges (it was proposed without any preparation) the session involved some interesting discussions.
We were broken down into 3 main systems:
- Applications — systems that generate and receive messages.
- Message Queues — receiving messages and holding them until someone asked for them.
- Message Broker — a system that applies rules to the messages it receives.
We played out scenarios like:
- What happens if the listener isn’t listening anymore? Drop the messages? Hold onto the message forever?
- What happens if the queue fills up? Does it drop the first message or the last? (It depends)
- What happens if an application fails while processing a message? One solution is to have a transaction for removing the message that is only committed after the processing is done.
- Broadcast messaging
- Request/response over a messaging system
We used post-it notes as messages because they were available, we have lots of post-it notes, but I could see a lot of this working with balls or beanbags and it got me thinking about how we could improve things, could we represent a queue by a tube with balls as the messages? It would take more set-up but may make things better.
