For most of us when beginning the journey of writing software, it is initially very easy to see how we can model the world around us with Objects and Types (tables, chairs, etc.). This new door appears and, when opened, it reveals a new world of possibilities where we begin to realise that more nuanced concepts too can be modelled this way (e.g. sporting statistics, weather systems and business rules).

This journey of discovery is far from simple and, depending on the learning culture that surrounds you at work, it’s very easy for the story of learning to end here.

Deadlines come by thick and fast, and the small Object that you defined on day one is now 10,000 lines long and you begin to tell yourself, “well, 20 lines more isn’t so bad, I suppose”.

Fear not though! Bounded Contexts are here to save the day!

Origins

Like most things in software engineering, bounded contexts are an approach to managing complexity by making things more specific.

The idea of a Bounded Context was first introduced in Eric Evans’ book, Domain Driven Design. The book focusses on the need to describe a portion of a system using what Evans calls a ubiquitous language. In plain english, a business process has a ubiquitous language if all people (developers, internal and external stakeholders) use the same precise language to describe the process — that’s both nouns and verbs.

For example, at The Room we have two types of customer Profiles. Those that can offer (create) Opportunities and those that can bid on Opportunities.

A traditional system might just describe these two types of Profile, simply as Profiles. But, if we were to work a little harder, we could describe these as Offerers and Bidders. This way only Offerers can offer Opportunities, and only Bidders can bid on Opportunities.

The importance here is that we have made the subtlety more obvious by the names we have chosen. The language is more precise.

The Power of Nuance

Now, I would forgive you for thinking, “so what if we’ve used 2 different names instead of 1?”.

Famously one of the 2 hardest things in Computer Science is choosing names. It turns out it’s also one of the most valuable things too. Precise naming can inspire and inform future work that builds on top of it. As developers we spend 90% of our day reading code rather than writing it.

Since our definition of Offerers and Bidders both come from how they interact with Opportunities, traditional thinking would suggest that in the code we would need an Opportunity Object (or Type or Module) that can handle both types of customer.

And here lies the conception of the Opportunity God object.

Here be Dragons

It turns out that at The Room, the Opportunity concept is arguably our most important and fundamental business idea. This is why our customers love using us, it’s what pays the bills and as a consequence it’s possibly the most risky area to change.

Sandi Metz describes this as the Death Star anti-pattern. Like the Death Star it is all powerful, has its engineers quaking in their boots but, foolishly, has a risky single point of failure.

Is now the time to bow down to the Opportunity object in reverence? Has all hope been lost?

An Opportunity would be more manageable if we could somehow divide up its responsibilities, but as ever, the hardest part is finding where to start…

Taking Inspiration from Our Current Design

Evans’ introduces Domain thinking by Crunching Knowledge — a process where we iterate on our domain model by exercising its boundaries. This technique tells us that we should start by laying out what we already (think we) know.

We have two objects here that directly interact with Opportunities, Bidders and Offerers. So let’s begin listing out how these objects interact with Opportunities:

• Bidders can view published Opportunities
• Bidders can place a Bid on a published Opportunity
• Offerers can create a draft Opportunity
• Offerers can review their draft Opportunity
• Offerers can publish a draft Opportunity

As you can imagine, these are high level descriptions and they hide some of the complexities such as data validation and access control. However, I hope it’s not too difficult to see that the matter of bid placement is considerably different to the matter of creating a draft Opportunity. This represents a poor Separation of Concerns which helps to further take us down the God object path.

Since we’ve highlighted it, maybe we have two objects here, DraftOpportunity and PublishedOpportunity. That way Offerers can interact with DraftOpportunities and PublishedOpportunities, whilst Bidders can only interact with PublishedOpportunities.

This is a great first step and helps us drastically reduce the baggage that a Bidder has to deal with. But still it is only a first step.

Bounded Contexts: The Next Step?

One important aspect of design to note is that no business domains are totally independent of each other. There are many more capabilities that we offer that interact with Opportunities (not just bidding and Opportunity creation).

As the weeks rolled by, we began to see a difference between a Bidder’s view of the world and an Offerer’s view of the world. The conditionals began to stack up around the Opportunity object and we started thinking that “**knock** there must be a better way” — Raymond Hettinger.

Maybe we have two different views of our business domain, one relating to Offerers and one relating to Bidders. Do we have an Offerer bounded context and a Bidder bounded context here?

A Source for Inspiration

Previously we have mentioned how carefully choosing precise names can inspire a more thoughtful design. An even greater inspiration comes from breaking our domain model into bounded contexts.

By having distinct Bidder and Offerer contexts, we are now free to specialise Opportunities and their representations in one context independently of the other. This opens a world of possibilities whilst also reducing the risk of a small change breaking a large portion of the system.

“Constraints aren’t the boundaries of creativity, but the foundation of it” — Brandon Rodriguez

Summing it Up

For me, this journey of iterating through domain models has given me a new found respect for the power of naming things precisely and exercising constraints. It also helped me to let the domain model inform the design of the system much more than some arbitrary naming convention would.

Finally, despite many of these ideas coming straight out of Eric Evans’ book, this article is not an advert for dogmatically following ideas from a textbook. The real lesson here was to continuously iterate on the domain model, its implementation and to decrease complexity at each step of the way if possible.

If you are interested in exploring domains, iterating on domain models and reactive software design, then please review our jobs board. At The Room, we have a deep interest in continuous learning and using the right tools for the job. If you share these interests, we'd love to hear from you.

Slaying God Objects using Bounded Contexts was originally published in The Room Product & Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine having an amazing product idea but nobody to build it. Would you know where to start? How would you create a successful Product Team where everybody is new to each other and to the company?

Hiring is hard and I won’t dare go into it as part of this article because quite simply, I am not the best person to give advice on hiring. There are far more qualified and experienced people who could easily detail the best hiring processes and how to find the gems you need.

Instead, my aim within this article is to explain the three key areas that will help you to cultivate your team and work with them to become more efficient, effective and empowered.

The most important factor that can really make or break a Product Team is the product vision. Does everybody know what it is? Does everybody believe in it? If you’ve answered no to either (or both) of these questions then you’re in trouble and need to focus on improving team communication and knowledge in this area.

The team knowing your idea for the product is great but it’s not enough. You need to make sure that the whole business understands the reason behind creating the product. Anybody working in any department should be able to tell you what problem the business is solving, who they’re solving it for and why it’s important.

Remember though there is a clear difference between the product vision and the product itself. The vision is the motivation behind building the solution (the product). For example, Nike’s product vision is to:

“bring inspiration and innovation to every athlete in the world*

*if you have a body, you are an athlete”

Their products are created to achieve this in a sustainable and future proofed manner. They cater for a wide range of people in a wide range of places and stages in their lives. A great example of a product supporting their vision is that in 2021 they launched a new maternity sports bra which allows mum’s to easily breastfeed whilst training (probably not at the same time though). This not only shows empathy in understanding a problem their customers had but it also inspires their customers to see what’s possible when using their product!

It’s really key that people not only understand your product vision, but that they also believe in it. Nobody is going to be passionate about their job if they don’t buy into what they’re helping create so don’t hire a technophobe to develop a new AI system…

Of course a four person row boat is far easier to steer than a 200 person cruise ship but it can be done with clear communication and an agreed direction!

The second most important thing in my opinion to create and maintain a successful Product Team is to make sure everybody understands their value within the team. All team members should feel appreciated and know that their work matters.

It shouldn’t be uncommon for you to praise your team when they do excellent work, whether it’s completing a huge data migration without any hiccups or presenting a demo to the company — tell them how well they did! I think some people can forget that whilst an excellent level of work is of course expected in any role, that doesn’t mean that it should go unsung.

When people feel valued, they feel empowered and are more likely to put themselves forward for taking on new projects or more responsibilities. Trust your team and their abilities, give them ownership of a task and let them be creative with it! Projects are of course a joint effort and we don’t want to create silo’s but by giving people the confidence and freedom to lead it will help them (and also the business) to grow.

An often overlooked part of valuing somebody is respecting their time and attention. Make sure you know what their working hours are, minimise any interruptions they suffer from where possible and limit meetings with them to only those necessary. This isn’t to say you should never message or talk to somebody, but it’s making sure that you don’t expect replies straight away to non-urgent Slack messages and not getting annoyed at calendar invitations being declined.

The third and final tip I can give you is to make sure that you base your teams processes on their needs and preferences. Just because 8am meetings, the “To Do — In Progress — Done” JIRA workflow and Friday retrospectives worked at your previous company doesn’t mean they’ll work here.

When starting off with a brand new team, we obviously all have to start somewhere and there is usually safety in the knowledge of our tried and tested processes or methods. This is completely acceptable and I fully encourage you to do it when starting from scratch but do not get stuck in doing these things just through habit, make sure they actually are working well for everybody.

Ensure you regularly check-in with everybody if the processes in place are serving them correctly or if they’re just giving them pain. Here are a few examples of times when you might need to shake things up a little:

• Is somebody always late for the 8:30 standup because they’re having to rush back from the school run? Ask everyone if they’d mind working around this and move standup to 9 instead because lets be honest, we don’t need to add any extra stress to the school run…
• Do retrospectives feel a bit flat and are people running out of things to say each time? Switch up the format you use, focus on one topic rather than the whole sprint, or maybe get rid of whatever board you use altogether and just have a general chat about the sprint instead
• Is anybody using the “design review” status in JIRA or do all tickets bypass this and go straight to “code review” instead? Find out why people aren’t using it, if there’s simply no need anymore now you’re further into the product build then remove it from the workflow

The important thing here is to ask for feedback regularly on the processes you have in place, listen to what people have to say and don’t be offended if changes are requested. As your team grows, whether in size or maturity, your processes should adapt to fit with that. What worked at the beginning when you were a team of two sitting in a room together won’t work when you’re a team of 12 all remotely dialling into meetings.

Within a team there will often be times of compromise and growing pains too but as long as everybody is open to trying new approaches and gives it time to bed in then you’ll keep growing together!

To summarise, here are my top ideas for how to ensure you grow and maintain a successful Product Team:

1. Ensure everybody knows and believes in the product vision and it’s continued purpose
2. Value your team: give people praise, trust and respect
3. Regularly review and adapt processes to fit your team needs and do what’s right for them now

Do you agree with what I think makes a Product Team successful? I’d love to know your thoughts on what I could add to this list and how we can continue growing our team!

How to create a successful Product Team was originally published in The Room Product & Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many changes have been incorporated into our daily lives since the start of the global pandemic. To keep up with today’s near-frantic pace of change, most of us have put aside our travel cards and stayed home. However, life doesn’t stand still, and the need for developers to remain agile and productive has never been more critical.

You may have been working from home since the outbreak; perhaps you are just about to start a new role where you are required to, or you’re struggling to stay focused at home, and you have found this article. No matter why you’re here, take in my five ways to stay focused when working from home — derived from my personal experiences.

1. Put your pants on!

When I initially started working from home, I opted for comfy clothes and
even stayed in my Pyjamas on some days!

It’s all about the mindset for the day, do not drag yourself out from the bed straight into the 9am meeting. Get up, take a morning shower and make yourself look good — even if you’re not planning on leaving the house!

2. Leave the house

Go outside during breaks! Take a walk, go to the gym, sit in the garden, grab some snacks or milk. Fresh air has been shown to help digest food more effectively, improve blood pressure, reduce obesity rates and strengthen the immune system, leading to a healthier you. Did you know that 20% of the oxygen you breathe in is used by your brain to function?

I personally found walks very good for my mental health.

When the pandemic first hit, I felt like I was tethered into my work laptop.
At the end of each day, I would replug myself into the TV, often checking in on work items.

Over time I felt horrible about myself and generally unhappy about unimportant things. It’s no wonder when I spent 98% of my days looking at a screen!

Taking regular breaks at work was just half of the puzzle. What I think really helped improve my mental health was the fresh air.

3. Communicate consistently

On a typical office day, conversations will form by themselves in the workspace. It’s also easy to tap your desk neighbour on the shoulder and have them have a quick glance at a bug you are trying to resolve. These interactions are vital in a functioning tech team.

To maintain these interactions in the work-from-home environment, we use Slack, and I personally use it in two ways.

1. We like to keep our conversations about the feature/ product in the public domain, so our project work-stream has a dedicated Slack channel.
2. If I’m having an issue with some code or need specific assets, I post messages in our developer general channel.

One feature I love on Slack is huddle — when the writing isn’t enough to explain the situation, a quick and easy way to jump into a voice chat is a perfect way to communicate with your fellow developers. And anyone can join once you’re huddled up!

4. Planning

Benjamin Franklin once said:

“If You Fail to Plan, You Are Planning to Fail”

Planning is different from a ‘To Do List’. The point of a plan is to document the tasks required to reach an outcome goal (or several). A ‘To Do List’ is just a set of tasks. See the difference?

To be honest, I’m not a Jedi master at planning, but I recommend outlining clear goals at the start of each day and concluding each day with a review of those goals. In addition to creating these outcome goals (e.g. fix ticket/build feature), I like to set out 5–7 actions that will help me accomplish them.

Top Tip: A great time to list actions is during your morning stand-up!

One last thing to mention about planning is it’s all about work/life balance — I like to mix each day with work and personal outcome goals.

5. Don’t try to remember everything. Write it down!

We absorb a lot of information daily, in the meetings, group huddles, reading up stack-overflow posts, or reviewing pull requests.

There is no way to remember everything said during your 8-hour working day, so I would like to introduce you to the “Mind Backlog.”

Any information that seems interesting, important, or it’s just something you can’t think about right now, simply write it down on a note.

Simple eh?

I have exactly 32 of these notes waiting to be read when I have time.

No, they’re not as important as my daily goals. However, if something was important enough to write down, I’m confident it will have value moving forward. Now I just need to plan some time to review them.

Bonus Points: Organise the notes in priority levels and introduce them into your daily or weekly planning activities.

Conclusion

I hope my take on the world of ‘work from home’ helps your daily life become more productive and enjoyable. We all work differently, so please take my post and adapt it to your life accordingly.

Most importantly, be happy!

P.S. We are hiring for an Android Developer. Know anyone? 👀

5 Ways to Stay Focused When You Work From Home as a Developer was originally published in The Room Product & Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.