Thursday, 8 October 2015

Sharing Databases Within Bounded Contexts

A contentious topic in distributed systems is if/when/how to share databases. Some developers/architects will tell you never to do it. Others, like me, will cautiously mention a few acceptable scenarios.

"Components [within a bounded context] work together very closely; therefore, having shared dependencies increases cohesion... without necessarily causing problems"

Patterns, Principles and Practices of Domain-Driven Design

Who is right? What is the one true way?

In this blog post I won't be wasting time on such futility. Instead I’ll be elaborating on my belief that sharing databases, and other dependencies, within bounded contexts can be sensible and savvy.

Thursday, 10 September 2015

Please Use The Cascade Rule

Amongst all the hype of shiny new technologies, fashionable working practices and clever design patterns, sometimes I think the absolute basics of writing readable code are ignored or discarded as boring. I can’t think of a more saddening example than the unloved cascade rule.

Please can we use the cascade ruuuule?

We write code from left-to-right because we read left-to-right. Our eyes go from the left of the screen to the right, and then down to the start of the next line. It’s easy and comfortable because that’s how we read books and articles.

Logically, then, we should write code that reads from top-to-bottom since our brains are trained to read that way. That's all there is to the boring-but-effective cascade rule. It makes code easier to read and I love it.

Saturday, 15 August 2015

Domain-Driven Architecture Diagrams

Domain-Driven Design is about creating shared understanding of the problem space that is reinforced ubiquitously via conversations, code and diagrams. DDD’s Shared understanding enhances synergy and alignment, increasing the ability to deliver value sustainably - ideally over the lifetime of a product.

As I most recently attempted to justify at the London Women Who Code Intro to DDD Architecture workshop, the architecture of a system, expressed via diagrams, is a profitable avenue for reinforcing DDD’s shared model.

Highlighted in red: where architecture diagrams can be advantageous using a domain-driven approach.
Diagram modified and borrowed from Patterns, Principles and Practices of Domain-Driven Design published by Wrox

Saturday, 25 July 2015

Trying to be a Good Code Teacher

It's a privilege to be responsible for the education of others. But it's also tiring, relentless and a tough lesson in modulating your emotions. Undoubtedly, teaching programming is hard, especially on-the-job training where you are under pressure to produce deliverables.

Thankfully, playing the role of teacher also confers enlightening personal growth. Guiding a learner's progress is rewarding; dynamically tailoring their learning plan in real time is a vigorous lesson in empathy; and trying to inspire the persistent desire to learn in others is a marathon of emotional intelligence training.

The opportunity to teach others is an opportunity for immense self-growth and self-exploration. By writing this blog post, I hope to solidify my learnings as a teacher and contemplate how I can improve on my many weaknesses.....

Sunday, 14 June 2015

What I Learned from the Business Model Canvas Workshop

How can you make developers happier, more engaged, and poised for innovation? If you relied on developers to achieve your goals, how would you foment these potent productivity multipliers?

My feelings, as a developer, are that freedom and responsibility are the key - explain the problem, and then let me and my team pursue your goals with frequent collaboration and minimal constraints. I say this because when I am not being pressured, and I feel important, that’s when I feel at my absolute best. My developer friends express this preference, too.

Freedom and responsibility are extremely dangerous, though. Not only can they unlock peak potential, but they also risk catastrophe. Instead of helping our organisations to steam past competitors, we can can get too focused on clean code or microservices, forgetting we are supposed to be making someone's life better.

If we want the freedom and responsibility, we need to have a deep situational awareness. This is why I think the Business Model Canvas is a marvellous tool for improving alignment between developers, executives, and just about anyone else in an organisation.

Having experienced the alignment benefits of the Business Model Canvas, I wanted to get the opinions of others who have operated within a variety of different organisational structures and cultures. So I ran a Business Model Canvas workshop for the London Agile Leadership Community.

In this post I will tell you will what I learned at the workshop and where I am focusing on improving my understanding in the future.

Wednesday, 27 May 2015

Starting a Tech Team Transformation

A horrifying revelation that shocks many companies is the realisation of how ineffective their development teams are. Excessive time spent fixing bugs, inability to support business growth, and being out-iterated by more agile competitors are often the distressing trigger symptoms.

One common reaction is to follow the “we must be agile” hype and bring in an agile consultant expecting a quick fix. As good as a select few consultants may be, for 99% of companies there is no quick fix. Culture, practices and personnel often require radical change.

I’ve had this conversation about improving lagging tech teams what feels like a millions times over the past year. The latest one triggered me to put my thoughts in writing and clarify my thinking - this post is as much for me as it is for you.

In summary, my general recommendation is to create a shared vision of change based on the mission and purpose of the organisation, and then gradually implement it. Without doubt, though, individual circumstances will play a huge factor in any change initiative. In this post I will outline my thinking along with some key details and an example implementation roadmap.

Be prepared for a long journey

Saturday, 11 April 2015

Win a Copy of Patterns, Principles, and Practices of Domain-Driven Design

To celebrate the launch of our book, Scott Millet and I will be donating a few free copies. Just email your name or twitter handle to by Friday 17th April.

If you are selected as a winner, a hard copy of the book will be posted to an address of your choice. The book comes completely unconditionally - I would love to hear your feedback though.