Goodbye Slack

For the last several years, we have used Slack as our primary way of communicating in the Development department. However, company-wide we have Microsoft Office 365 licences, so other departments use Teams. I always thought it was a dumb decision to use Slack due to essentially paying twice for a communication tool. Slack isn’t that expensive on the lower tiers but it adds up when you have a large amount of staff. Plus, due to stricter security policies, we wanted to use single-sign on so had to upgrade to the Business+ licence which didn’t seem to be worth the cost.

As time goes on, we keep “improving security” which I often think is just an excuse to get rid of certain software. How do you really determine which software or companies are secure anyway? They could tell you they use certain security practices or have some accreditation but if your data is exposed in a data breach is another story.

“not sure what you can hack via Slack. Just over reacting like everything these days. 2FA all the things!”

me

On Slack’s Enterprise licence, they boast even more security features and with our new strict security policies, the management decided that we would have to pay significantly more to keep using Slack, or just get rid of it. So they decided to get rid of it.

To be fair, Teams has improved a bit over the years, and although I prefer the way Slack looks, and its excellent emoji support (you can add custom emojis!); I can’t justify the cost.

why is slack not secure as opposed to teams? probably just nonsense. Where does the data go when it is lost? surely doesn’t leak out onto the dark web!

Rob

We somehow had over 900 members according to Slack Analytics but I reckon that was every historic user since we started using it. Scrolling down the list and roughly estimating, we seemed to have around 300 which could reasonably be called “active”. Then looking at the Business+ costing, it should cost $45,000 per year. Enterprise is one of those tiers where it says “contact sales for a quote”. One manager reckoned it would cost $250k a year to use which doesn’t sound right. How can you justify such an expense for a chat application? Even if it did cost that much on paper, surely you can haggle that down significantly. I’m sure Slack won’t want to lose us. Surely charging $60k is good profit for them.

I often think the way companies charge for software licences doesn’t make sense. They often just charge “per user per month” but there will be times where people don’t actively use the licence due to the work they are doing, or maybe have annual leave to take. Then there’s people that join temporarily, then people just naturally join/leave the business over time. So who really tracks what the accurate amount you need to pay. Companies just end up overpaying for licences they don’t need. Slack seem to suggest they charge just for active users. But what happens if you just send a few messages for 1 day in the month; is that an active user for the month? I often think the best approach would be to charge for a certain amount of users, but then give out an extra 25% keys for light usage.

One thing that I found interesting when looking at Slack Analytics is that most people seemed to be sending as little as 20 messages per day. I think that they are either super focussed and just work independently, or they are chilling out. It’s hard to believe that you can work well in a team, or even have a good relationship with them if you only send 20 messages. I find that some people use instant messaging by sending a sentence per message, which will inflate the message count which makes the numbers even more surprising. For example, they could send 4 messages for this interaction:

Hi

Are you free?

I was wondering if you can help me work out this error

I have just got the latest code but am unable to log in

The decision to remove Slack was disappointing for some, but the bizarre thing is that we got told by our manager on the Wednesday, it was formally announced on Thursday, and gone by Friday 4pm. If you were on annual leave that week, you would be confused when you could no longer access Slack on the following Monday. There was some great information that we had on there, and was great to search for common errors and find solutions to them. We didn’t have enough warning to try and extract the information.

“Has the cost of the loss of productivity and collaboration been factored into the decision to remove slack?”

Sad developer

One developer had a crazy idea of  developing our own solution:

“We are a software development company. If we’re that desperate, can’t we write our own messaging system, protected to the security standard we want?”

Ambitious developer

The thing is, we already made a chat application for our users. I never understood why users would want a native chat app when they could use something more widespread. Since we already have a chat app, then it could actually make sense to add more features to it; then use it internally.

Making your own tools isn’t as cheap as you would think. If a developer’s wage is £35k, then paying only 1 developer to develop and maintain it each year is £35k. You may as well just pay for Slack then. But if we are using it and selling it to our users, then it does make more sense.

The weird thing is, for our upcoming software, we originally used Okta for the login functionality but it was decided it was too expensive, so a few developers got together and made their own solution. That seems bonkers to me because that is about security, so surely you should leave it up to the company that specialises In security. So the fact that we do make custom authentication makes the idea of making a chat app even more realistic.

However one of the architects working on this upcoming software ironically replied:

“We need to move away from homegrown solutions, especially based on the presentation happening now from our Head of Security”

Hypocritical software architect

Another architect supported this claim:

“This is about minimising home grown solutions when an off-the-shelf solution would do just as well”

Software Architect

Does that mean he should be bringing Okta back?

Learning at Work Week

Each year we have a “Learning At Work Week” where there’s usually a few optional meetings where people either do presentations about their department, or some “soft skills” like management advice, or some philosophy like Growth Mindset. Then you are encouraged to use resources like LinkedIn Learning.

I never get involved and just carry on doing my work as usual. This year, I received an email:

Good morning, We are in the process of putting together a social media campaign around Learning at Work Week, and we’ve seen that you’re a regular user of LinkedIn Learning. We wondered if you’d be happy to share your experience and answer the following questions for us to use as a quote in marketing (e.g on the website and on our socials)?

  • What is your name and job title?
  • How often do you use LinkedIn Learning and what do you use it for?
  • Why is it important to you that you get the opportunity to continue learning and development at work?
  • Feel free to add any further details you want to include!

If you are happy to be involved, please can you send me your written answers to the above questions by the end of the week, along with a photograph.

I watched some of the playlists they put together that were on the topic of our company values. I watched the playlists that were compiled by the Development department about Cloud Technologies. Then I watched some about woke issues they also told us to watch, like on Unconscious Bias. Our company is massive and I know there are plenty of people that will want any excuse to chill and not do work, so I was extremely surprised that I was one of the top users. I would say I have rarely used it, and often forget we are even signed up to it. If I am one of the top users, then that means we must waste loads of money on it and should probably just get rid of it.

So my answers would be:

  • Senior Software Development Engineer
  • Never really use it. Just watched a few courses on wokeness for the bants. Then a few on Cloud Technologies and Entity Framework.
  • LinkedIn Learning is not important, and mainly for chillers.

 I asked Bing Copilot to write me a humorous response. This is what it came up with:

Good morning,

Thank you for considering me for your Learning at Work Week campaign. I’m flattered to be mistaken for a LinkedIn Learning aficionado! While I may not be the power user you envisioned, I’m all for learning and development. To be candid, my engagement with LinkedIn Learning has been more of a casual flirtation than a committed relationship. I dip in occasionally, like a cat circling a fishbowl, pondering whether to take the plunge.

As for my job title, let’s go with ‘Aspiring Knowledge Sponge’ – it has a certain ring to it, don’t you think? The truth is, if I’m one of your top users, it might be time to audit those subscription numbers. It seems there’s more ‘linked out’ than ‘LinkedIn’ in our company’s learning stats!

Nevertheless, I believe in the power of continuous learning. It keeps the brain nimble and the skills sharp, like a Swiss Army knife in a world of plastic sporks. And who knows, maybe this email will spark a renewed zeal for e-learning in me. I’ll aim to send you a more detailed response, along with a headshot that hopefully doesn’t break your camera, by the deadline.

Warm regards,

[Your Name]

Aspiring Knowledge Sponge

Minimum requirements when logging defects

A colleague wrote a list of ideas to improve bug reports. The more detail a report has, the more stakeholders are aware of the impact and can triage it accordingly. When it comes to fixing it, software developers can work out the issue more easily…

It is important that all the required information is added to a defect at the time of raising it. This stops the need to refer it back to the original author for more information and therefore saves time.

It should also be noted that we report all defects raised to certain user groups, and it is important that they are able to understand what the issue is and how severe the issue is to them.

In order to meet the minimum requirement all bugs should contain the following:

Title

  • The title must be clear and concise
  • It should describe the problem
  • Avoid using technical jargon

Description

  • The description must clearly outline the problem being experienced
  • It should explain the impact to the customer
  • It should describe a workaround if known.

 Reproduction steps

  • Reproduction steps to recreate the issue
  • These should be clear and easy to follow
  • Include any required environment configuration
  • Include the actual and the expected outcome

 System info

  • Enter the version of software the bug was found in

 Other checks

  • Have the Area and Iteration paths been set correctly?
  • Are relevant examples present with the record? (record number, sample data, screenshots etc.)
  • Have the relevant error details been included? (stack trace, error message, error number etc.)
  • Has the bug been linked to the test case/user story etc?
  • Has this been linked to a relevant user story, requirement, or similar bug report?

 Root Cause Analysis (RCA)

If the defect is found during integration testing, the following must also be completed

  • Stage Detected In
  • Use Release Testing
  • Complete Release Introduced In field

Why Blog?

I was going through my old Twitter bookmarks and I have this from Jack Rhysider on blogging. Jack makes one of my favourite podcasts, Darknet Diaries which I recommend if you are interested in cyber security stories.

If you’re in IT, I highly encourage you to write a blog.

Here are 17 reasons why you should be blogging.

1. Don’t think of the blog as some new profound insight that makes you look smart. Instead, just write notes to yourself. If you make the blog useful to you, it’ll be useful to others.

2. Throughout your career you’ll stumble onto lots of great tips and advice and commands and tricks and ways to do thing. Blog all that. You will remember it better if you write it down. And it’ll be easy for you to find it later.

3. You are in IT, so how’s your web presence lookin? You know there are people who have a bigger web presence than you who live out on a farm and know nothing about computers? This is your passion. Show us what you can do!

4. Have you ever run into a problem, Googled for a solution but couldn’t find one? You’ve gotta keep doing trial and error until you fix it. That’s gold blog content. You’ll have the only page on the internet with how to fix that problem, and maybe save lives.

5. Do you keep seeing people ask the same question over and over that is so obvious to you? Blog that. Then point people to it every time you see the question. Psst, your co-workers will bug you less if you point them to your super helpful blog posts that answers their questions.

6. The more you explain technical concepts to people. The better you’ll get at understanding technical concepts yourself. Sounds backwards but it’s true. Teach to learn.

7. The most underrated skill to have in IT is ability to communicate effectively. Blogging is leveling that skill up. Are people getting what they need efficiently and effectively when they land on your site? Can you explain the concepts even better? Rewrite it, level up.

8. If you’re sending people to your blog and it’s not helping them, learn why so you can do better. My system is to clearly state the problem first, then write the answer after. Then explain details and alternative solutions. Don’t waste time with making people scroll for the answer.

9. If you find yourself having to Google answers to the same problem over and over, that’s good blog content. Write down exactly how to solve that problem that’s most effective for you, and it’ll be faster to reference your own notes, and it’ll be better suited to you.

10. Chances are, if you work in IT, the only people who know you’re any good are your co-workers and customers. Blogging expands that and suddenly there are people all over the world who respect you and appreciate your skills. This can open a lot of doors for new possibilities.

11. Taking classes on a technology new to you? You’re taking notes ya? Blog those notes! Trust me. Taking your notes from class and rewriting them into your blog will help you understand the content so much better, while helping others too. It’s a magical thing.

12. Now once you start putting content out into the world. Some magic stuff happens. First people will start correcting you. It’s inevitable. Don’t take this negatively. Take it as an opportunity to learn how to do something even better or more thoroughly.

13. Strangers might write to you thanking you for helping them. And let me tell you, fan mail is one of the best drugs. Because it’s pure and clean and feels great.

14. Did you know blogging was the precursor for my podcast? I blogged for 7 years before starting a podcast. It taught me how to write better, and produce content. It was from there that I got the idea and skills needed to podcast. Now I podcast full time. Blogs take you places.

15. If you blog for a while, you’re now a content creator with an audience. Chances are the blog won’t be the last thing you create. You can use your blog audience to seed your next project. My blog has been one of the best places to get new listeners for my podcast.

16. Bloggers can make money. You can put ads in your blog, get Brave rewards, or even just get tipped by random strangers.

17. Oh yeah and when you blog you have to solve all kinds of problems like domain registration, DNS servers, hosting, backups, web design, securing the site, and HTML/CSS/JS. The more you have your hands dirty in doing different IT stuff the more well rounded you’ll be.

So to recap. By blogging you will become a better writer and communicator, learn the concepts better, open new opportunities, have a fantastic notebook for self reference, maybe make money, become appreciated by more people, and show off your IT skills.

The Outage Part 2: Feedback on the new process

In my blog, The Outage, I described a Major Incident and a knee jerk response from the CTO.

He described this situation as a

“major incident that impacted the whole estate, attributed directly to a failed Change. We recognise that the change was not intended to have the adverse impact that it did, but sadly the consequences have been a major blow to Users and us. Therefore, we are seeking to create immediate stability across our estate, and are implementing several amendments to the way Technology Changes are approved and implemented”

CTO

He came up with 5 changes that he came up with, presumably with no consultation from others. I gave my view on them in the blog. After a few months of carnage, the CTO has put out some revisions to the process.

CTO = Chief Technology Officer

SLT = Senior Leadership Team.

ELT = Executive leadership team

BAU = Business as usual

Suggestion from CTOMy View at the timeCTO’s update
“There will be a comprehensive change freeze for the month of June, with only changes meeting enhanced criteria being passed for implementation.”The size of the release wasn’t the problem, so cutting it down won’t solve anything. It might annoy the users even more if we then delay features that we announced.“as a knock-on effect, we have also reduced our delivery capacity and timescales.”
 “Pre-approved changes are suspended”The idea of a “pre-approved” change is that it is something that is often run on the live servers to fix common issues and is low risk, hence it is pre-approved (eg the ability to restart a crashed server/service.). This is just going to annoy staff members in Deployment. The CTO also remarks:  “Preapproved changes are wonderful. They have been reviewed and tested to death. My goal is to increase the number of preapproved changes in the future. It’s just with the existing ones, we don’t know if they have been reviewed or not”.  You don’t know if they have been “reviewed” but they have been run 100’s of times, and never caused an issue. So you are temporarily banning them on the grounds that they could cause an issue?“The door for pre-approved Standard Change has been re-opened. Standard Change templates can be proposed and put forward as before. As part of our continued governance and enhanced view of change taking place, we do ask for the following:   Each Standard Change template requires approval from one SLT or ELT member. A full review of both the implementation and rollback steps needs to have been undertaken.”
“Any changes submitted for approval will require TWO members of SLT. ”How many times has there been some kind of approval process and the people with authorisation are too busy or on annual leave? Why are we going from 0 approvers to 2? Would the managers understand a change to enable a feature for users belonging to company A, B and C? Would they go “hang on, C don’t have the main feature! I’m rejecting this”? It’s going to be a box-ticking exercise.  We already have a problem when changes are Code Reviewed by Developers – there’s not enough “expert” people that can review it in the required level of detail. So how would a manager understand the change and technical impact? It will be more like “does this make us money? Yes we like money”; approved.“A significant challenge impacting time to deliver has been the ‘two eyes on’ stipulation. We recognise that not every type of Change requires two sets of eyes and so are refining this slightly.   Standard Changes will need to follow the above process. Where ‘two eyes on’ is not deemed necessary, two SLT approvers will need including in the template submission verifying that this is not required. Normal Changes will follow the BAU process. Where ‘two eyes on’ is not deemed necessary, two SLT approvers will need including in the submission verifying that this is not required.”
“Implementation activity must be witnessed by two or more staff members. Screen sharing technology should be used to witness the change. No additional activities are carried out that are not explicitly in the documentation.”This might actually help, although might be patronising for Deployment. The CTO made a comment on the call about having “Competent” people involved in the deployment process. So if a Developer has to watch a member of Deployment click a few buttons; it feels like babysitting and not respecting them as employees.no specific comment was made
“All changes must have a comprehensive rollback plan, with proof of testing. The rollback plan must be executable within 50% of the approved change window.”The rollback idea is one of these ideas that sounds logical and great in theory but this is the biggest concern for the technical people in Development.no specific comment was made

So in conclusion, it seems I was correct.

Strava

Tweets:

I was looking through some old Twitter bookmarks and found this interesting thread on the running app Strava.

Note: Strava have apparently drastically improved their privacy options and default settings since this discussion. There are options to hide your home and work place using a buffer zone where it won’t track you.

“Out running this morning on a new route and a lady runs past me. Despite only passing, when I get home Strava automatically tags her in my run. If I click on her face it shows her full name, picture and a map of her running route (which effectively shows where she lives). This is despite the fact that I don’t follow her and she doesn’t share her activity publicly. So basically if someone sees a woman running alone there’s an app they can go to see her name, picture and address”

Andrew Seward

Other people pointed out that all visibility settings default to “Everyone” and this feature was called “Flyby” but was not clear that people will be able to see your running route and similar.

Discussion:

When a feature is designed by someone without bad intentions, an idea can sound great on paper but with more thought, can potentially have negative implications. In this case, the feature sounds like a great social aspect, and maybe runners can learn better running routes and compete for the best times. However, it can be used for nefarious purposes: 

  • A stalker can learn where you will be and at what time, and can even determine where the most secluded area will be. 
  • A thief will know when your house could be vacated and how long for.

This doesn’t just apply to running apps, and caution should be used when using all apps. The classic example is not posting on social media about how excited you are for your holiday, and instead: posting about it when you come back. Exposing when you will leave your house is useful for burglars.

Of course, features could have more nefarious purposes. People often accuse Google of collecting data to use for its primary business which basically makes money off your data with its advertising business. These features can often be framed for your own benefit with claims of “personalised experience”.

Often features can be enabled by default which takes advantage of people’s laziness to read the options and turn them off. However, even if you do check the settings, you might not understand what the feature actually is, just like people didn’t fully understand Strava’s  “Flyby” feature.

Notes On: The Art of Captivating Conversation – Patrick King

Introduction

I’ve finished reading The Art of Captivating Conversation by Patrick King. I made notes from the most interesting points and ideas. I’ve always found small-talk to be awkward and the author gives tips on how to make the conversation flow and sound more interesting, and more interested in the other person.

Conversations 

Conversations are the threads that weave the fabric of social interaction, and they serve two primary purposes: entertainment and utility. The art of conversation lies in the delicate balance between these two elements, ensuring that our interactions are both enjoyable and productive.

At the heart of our interactions are the six primary emotions: happiness, sadness, fear, anger, surprise, and disgust. These emotions are universal and often drive the direction and tone of our conversations. Recognizing and responding to these emotions in others can lead to more meaningful and empathetic communication.

Small talk

Small talk plays a crucial role in initiating conversations and building rapport. Common small talk questions include inquiries about one’s day, weekend, work, family, and plans. Small talk, often seen as a necessary evil, is widely disliked for its superficial nature. It’s a societal construct designed to convey politeness, yet it often feels insincere. The key to transcending small talk lies in personalising the conversation with genuine interest and shared stories.

To engage effectively in small talk, one should aim to provide entertainment, make the other person feel good, and offer substantial content that allows the conversation to flow with minimal effort. This can be achieved through two methods:

1. Answering a fuzzy version of the question: This involves focusing on a keyword from the question and expanding on it with a more interesting or entertaining anecdote. For example, if asked about the weekend, one might share a memorable weekend experience from the past rather than a mundane recount of the past days.

2. Completely redirecting the conversation: By briefly acknowledging the question and then pivoting to a more engaging topic, one can steer the conversation away from generic small talk. Using transitional phrases like “it was good, but did you hear about…” can quickly shift the focus to something of mutual interest.

What Would Jay Leno Do?

“You can make more friends in two months by becoming truly interested in other people than you can in two years by trying to get other people interested in you.” 

Dale Carnegie

When people sense you care, they respond in kind and open up. The best way to articulate this is to picture your favourite talk show host. The guest is the centre of his world for the next ten minutes. His genuine curiosity, enthusiastic reactions, and positive demeanour not only make his guests feel valued but also entertain and engage his audience. This approach is highlighted as a model for personal interactions, where showing real interest in others can lead to more meaningful and reciprocal relationships.

Everyone has unique knowledge and experiences. By being curious about others, we acknowledge that every person we meet can teach us something new, thereby enriching our own lives. This mindset encourages a sense of humility and openness to learning from others.

Be aware of social narcissism, where conversations are dominated by one’s own interests, disregarding the value of others’ experiences. This behaviour is characterised by listening only to respond rather than to understand, and it hinders the development of genuine connections.

Break The Ice

Social interactions, especially in settings such as networking events or parties, can often feel like navigating a minefield. The challenge of breaking into a conversation group can seem daunting, as if invisible barriers are erected around them. Common internal objections include the fear of interrupting, appearing awkward, or being perceived as strange.

However, the key to overcoming these social hurdles lies in establishing a “Social Goal.” This goal acts as a beacon, overriding any social defence mechanisms. It could be as specific as learning about an individual, collecting a set of business cards, or memorising names at a gathering.

To facilitate this process, icebreakers can be invaluable. They can be categorised into three types:

1. Subjective Queries: These involve asking for personal opinions on topics of mutual interest, such as the music at a party. It’s a way to show curiosity and invite others to share their passions.   

2. Objective Inquiries: These are questions about factual information, like the time, directions to the nearest café, or the location of the host. Such questions are non-threatening and serve as a natural entry point into a conversation.   

3. Comments on Shared Reality: Observations about the immediate environment or universally acknowledged truths can also serve as icebreakers. By expressing an opinion on something already within the other person’s awareness, it opens up the floor for a shared discussion.

Interestingly, it’s perfectly acceptable to ask questions to which you already know the answers. The primary aim is not to seek information but to initiate interaction and establish a connection.

In essence, breaking the ice is less about the content of the conversation and more about the willingness to engage. Remember, the objective is to engage, not to impress. With practice, the art of conversation becomes less of a challenge and more of a rewarding journey.

Never Laugh First

Initiating laughter in a conversation might inadvertently pressure others to conform to your emotional state, potentially creating discomfort. Moreover, it hinders your ability to assess the genuine humour of your remarks.

Belief Police

We feel that since we know so much better than the other person, we have some sort of responsibility to correct them. We then take it upon ourselves to prove to them just how smart we are. We can’t stand someone believing something wrong to what we believe. This habit is obnoxious to talk to. 

Questions

When you ask a general question, you will get a general answer. Questions like “what do you do for fun?” are hard to answer because no one thinks about their life in such broad terms. You want to enable people to be lazy and open ended questions actually make us think quite a bit and inject lulls into the conversation. “What is your favourite movie of all time?” This is hard because it wants one single answer and to represent you in a positive light. It can be hard to think of a single movie. A better question is “what’s a good movie you have seen recently?”. You can easily recall a movie you have seen recently and it doesn’t have to be the best. So the advice is to put boundaries and qualifiers on your question to make it less specific. You can even provide answers/prompts, so “what do you do for fun?” can be prompted with “playing sports, go outdoors, or music”.

Take The Hint

Recognizing cues of disinterest, such as a lack of engagement, prolonged silences, or shifting to generic topics, is crucial in respecting the other person’s boundaries and maintaining a comfortable conversation flow.

Eye Contact

Balancing eye contact is key; too much can be as disconcerting as too little. A general guideline is to maintain eye contact 80% of the time when listening and 50% when speaking to foster a sense of ease and attentiveness.

HPM, SBR, & EDR

HPM emphasises the use of personal experiences (History), personal opinions (Philosophy), and associative thinking (Metaphor) to engage in a conversation. 

SBR is a method of guiding a conversation by asking questions. ‘Specific‘ questions delve into the details of a topic, ‘Broad‘ questions open up new avenues for discussion, and ‘Related‘ questions tie in relevant but potentially separate ideas, allowing the conversation to flow naturally and informatively.

EDR focuses on emotional intelligence, asking for specifics, and confirming understanding. By acknowledging emotions (Emotion), probing for more information (Detail), and paraphrasing what has been said (Restatements), a person can demonstrate empathy, interest, and attentiveness, which are crucial for meaningful interactions.

Together, these strategies provide a comprehensive framework for effective communication, whether in casual conversations or more formal discussions. They encourage a deeper connection between individuals by fostering an environment where personal stories, emotions, and details are valued and explored.

Storytelling

1. Detail-Oriented Approach: Instead of crafting a full narrative, focus on providing five distinct, specific details. These serve as hooks, leading the listener from one piece of information to another, creating a chain of engaging tidbits.

2. Emotion-Driven Narrative: Concentrate on encapsulating a single motion or emotion in one sentence. Stories should evoke emotional responses, such as happiness, empathy, surprise, or curiosity.

Breaking into banter

Use light misunderstandings, double entendres, puns, and comical confusion to break the ice and introduce humour into the conversation.

Flow

Avoid stagnation by shifting the conversation to related topics, delving deeper into subjects, sharing personal experiences, inquiring about favourites, discussing emotions, expressing nuanced opinions, posing hypothetical questions, or referencing friends and articles.

Conversation Threading

This technique enhances your ability to respond quickly and thoughtfully in conversations. As a listener, use the storytelling method to pick up on topics and steer the conversation in a direction that interests you. For instance, if skiing is mentioned but holds no interest for you, pivot the discussion to talk about mountains or related experiences.

By employing these methods, you can transform simple exchanges into memorable conversations that resonate with those involved. Whether you’re a storyteller or a keen listener, the key is to keep the conversation moving, engaging, and full of life. Remember, the goal is not just to talk but to connect.

This is very concerning to hear

On a code review, a Senior Developer, Lee questioned why there was no database changes when the Developer Neil had removed all the related C# server code. Neil replied that he “wasn’t sure how the patching process worked” (despite being here years, and was in a team with experienced developers), and wasn’t sure if there were any backwards compatibility issues to consider.

So what was his plan? just hope it gets past the code review stage unchallenged? Then we would have some obsolete stored procedures, and unused data lingering in the database for years?

I initially thought his claim for backwards compatibility issues was nonsensical but from an architectural standpoint, it makes sense due to how it works in our system. The server code doesn’t call the other’s server; it goes direct. So that means if the old version calls the new version, then it would expect the stored procedures and data to exist. However, for this particular feature there were no cross-database calls at all.

I suppose being cautious and not deleting the data makes sense from a rollback point of view. It’s hard to restore the data if it is lost, but easy to restore the C# code. I have never seen us use this approach though.

The Senior Developer said :

This is very concerning to hear, can you please work with your team lead to understand how our versions are deployed, and if they are unable to answer all the questions, please reach out to someone. We do not support any version changes by default, though there are cases where we do have cross version server/database calls, but these are for specific cross organisation activities.
You can safely remove these columns, update these stored procedures.
There is no value in leaving something half in the system, if it is no longer needed, remove all references, database rows/columns/tables, class Properties, etc.

In my previous blog, I discussed Project vs Domain Teams. This is kinda linked in the sense that specialising in a certain area of the system means you gain knowledge of the functionality and architecture of that area. There would be less chance of this scenario happening where the developer is questioning if there could be backwards compatibility issues. However, he could have also found this information out by raising questions.

This example does cover many topics I have discussed on this blog:

  • Poor communication
  • Bad decisions
  • Funny quote from a senior developer ”This is very concerning to hear”

Domain Teams, Project Teams & Cross-Cutting

In the world of Software Development, there are often differing views on how to arrange teams. Regardless of the approach, people will leave/join over time, but team members need to be replaced and teams need to adapt.

There was a time when we were arranged into teams that were assigned to a Project, then moved onto a completely different one once complete. Any bugs introduced by the projects then get assigned to a “Service Improvement” team who only deal with bugs (and possibly ad-hoc user requests).

Then after a few years, and maybe under a new Development manager, they would restructure to Domain teams where you take ownership of a group of features and only projects related to those would be assigned to your team. Any bugs introduced by the projects stay with the team, which gives you greater incentive to fix them early as possible. People build up knowledge of their areas and become experts.

Then a few years later, we will switch back to Project teams.

There’s pros and cons to each structure, and there’s always edge cases which pose a management problem. Even in a Domain Team, there will be certain features that don’t neatly fit into the groups you defined, or ones that apply to many modules eg Printing.

Sometimes we have called a team that handles the miscellaneous features “Cross-Cutting”. Managers would sell it on being for features like Printing that really are used by many areas of the system, but we all know it becomes a team that gets miscellaneous and unrelated projects. They end up being like the “Service Improvement” team that deals with random bugs, and work no one else wants to do.

Cross-Cutting

There was a meeting where managers were announcing the new Domain Teams and I got assigned to Cross-Cutting. One developer was voicing his concerns about having a Cross-Cutting team. He wanted to point out that Domain Teams are supposed to have specialist knowledge on the Domains but most people that were assigned to their teams had little-to-no knowledge. For some reason he chose my name to make a point.

“What does TimeInInts know about Cross-Cutting?”

Which received a room full of laughter. I’m sure some were laughing at his point, some laughed at his emphasis and delivery, and others probably saw it as an attack on my knowledge. I was probably one of the best people for it really, given my experience in the previous Service Improvement teams.

The whole idea of keeping Domain knowledge in the team only works if there is a true commitment to keep the teams stable over years. However, people will leave the business, some will want to move to a different project to broaden their skills, or people could just fall out with their team members.

Another concern this developer had was with his own team. He was assigned to a Domain team he was the expert on, but was used to working with a couple of developers in the UK. This new team had two Indian developers. They had recently acknowledged the distributed teams weren’t really working so these new Domain teams were supposed to be co-located. But this setup seemed to signal that he was there merely to train these Indians up to then essentially offshore the Domain. Since he was the expert and proud of it, he still wanted to work in that area. But he can’t work on the same software forever.

In the Cross-Cutting team, we had an open slot labelled “new starter” so we were going to get a new hire in. You have to start somewhere, but again, this doesn’t help the teams specialise if they don’t already start with the knowledge.

Colleagues Opinions:

Developer 1:

Me 13:39: what does a new starter know about Cross-Cutting? 
Mark 13:39: sounds more like Cost Cutting! 

Developer 2:

It’s infinitely harder to build something if you don’t understand the thing you’re building. Hard to catch issues and make sense of designs if you had no opportunity to learn the domain.

Developer 3:

isn’t one of our major issues is we’ve lost domain expertise for core/bread and butter modules.  For any “module”, there’s a combination of what the requirements are/how it should work, and what the code is actually doing. Without “domain teams”/ownership – we’ve lost a large part of the puzzle (how module should work).

Developer 4:

our teams are completely ineffective, expertise has been spread too thin. We probably need to reorganise the department again with who is remaining.

Build stronger teams first that only have one junior-ish person, then have weaker teams helping out where possible. It will be very hard for the weaker teams, but unless we do this, we’ll lose the stronger people.

The weaker teams should be given appropriate projects with longer timescales, and given as much help as possible while ultimately having to struggle their own way, stronger people who put in the effort will begin to emerge from those teams.

Extension methods

Even as an experienced software developer, it is amazing when you discover some really trivial things, or discover some interesting quirk of a programming languages.

I was looking at a Code Review the other week and I saw some code that looked really pointless. It was testing some code throws a ArgumentNullException.

[Fact]
public void LogWarningDetails_WithNullLogger_ThrowsArgumentNullException()
{
	ILogger logger = null;
	Assert.Throws<ArgumentNullException>(() => logger.LogWarning("Test Error Message"));
}

A NullReferenceException is an incredibly common mistake and probably the first problem new developers encounter. If you have a reference to an object, but the object is null, you cannot call instance methods on it.

Therefore if logger is null, then you cannot call LogWarning without an error being thrown.

So on first glance, this test looks like it is testing the basic fundamentals of the C# Programming language. However, this is testing for ArgumentNullException rather than NullReferenceException.

LogWarning was actually defined as an extension method, and this actually does allow you to call methods on null references. I’ve never realised this or even thought about it. It is the case because extension methods actually pass the reference in as a parameter.

So if you have an extension method (as indicated with the this keyword):

	public static bool IsNull(this object x) 
	{
		return x == null; 
	}

This can be called like this:

	static void Main() 
	{
		object y = null;
		Console.WriteLine(y.IsNull()); 
		y = new object(); 
		Console.WriteLine(y.IsNull());
	}

Which would output true, then false. Which illustrates that the extension method does not crash if the reference to y is null, and the logic correctly works by returning true when y is null.

Conclusion:

Understanding NullReferenceExceptions is basically day 1 of learning to code in an Object Oriented Language like C# but I’ve never even considered there is an exception to the rule. A method call on a null reference won’t cause a NullReferenceException if the method is an Extension method!