Why software is a social thing

Software production is a social activity

This should not be controversial, yet here we are…

As a word to the nay sayers, yes there are Otaku¹ that code amazing things in their lairs and have no, or close to no, social interaction with their users. Or, even worst, are just rude to their users. I know a few. However, for everyone one of them, there are 1000s that are producing garbage and AI-slop.

99.9%² of software is produced by a team. That teams needs to communicate amongst themselves. In fact, both the Lean principles and Agile manifesto both have communication as a core value.

Communication in engineering is obvious

Let’s assume we have Alice, our principal developer. She is a good developer, using AI to amplify her hard earned skills and with decades of experience in producing quality software. In her daily work, she has to speaks to the following people:

1. Project managers (PM), who set the tasks and the deadlines. Or rather deal with things when the deadlines make a funny noise as they go past.
2. The three amigos. ‘nuff said.
3. Her fellow developers, who might require her input for a new feature or a bug fix. Or that require a PR/MR review, or just help understanding the legacy code base and why it is so clearly wrong. Well, it’s wrong now. It was the best thing some time ago and now needs refactoring. But there’s no time. True story.
4. Replying to comments left by others on her PR/MRs.
5. SQA / Testers, the people who break the lovely things Alice makes despite her using TDD/BDD and other best practices. There’s always something wrong: a bug per 10 lines of code.
6. Operations who will run her code in production. They have questions, requirements, and suggestions to make it easier to use. After all, they are the ones who will be calling Alice at 2AM on Saturday when her code breaks in production. Something Alice is very keen to avoid.
7. Security. Alice has enough experience to know that involving security early will lead to much less pain later. She’s familiar with all the OWASP and is pretty confident her code is rock solid. But, two pairs of eyes always beat one.
8. Design, because that’s where the magic happens. Always a conversation because some things are impossible — or so hard it might not be worth doing.
9. All the 5 Scrum ceremonies because…
10. Arguing with Claude, Gemini, or Copilot No, I am not counting this as a social thing.

To be honest, I am surprised that Alice has any time whatsoever to actually type code.😉

These interactions should be obvious, certainly with anyone doing secure SDLC, Agile/Lean, DevOps, or DevSecOps best practices. After all, this is how software is made.

But, does it stop here? As with any rhetorical question, no, it does not stop here.

Communication with other parts of the business is vital

Communication within the engineering teams is well defined, so it should be simple. But, what about the rest of the business?

How does it work? Who does Alice need to talk to on a regular basis and why?

First, there’s C-suite/the Board. They are the people with the vision and the power to get everyone there. They set the strategy and the direction of the company. While they mostly ask for things, they should also tell you what not to do. If you are never going to release for iPhones and Android, there’s no need to do certain things. Of course, a change of direction can always happen. But clear dos and don’ts are vital.

Second, there’s Sales. They are the ones that ultimately bring the money in. They (should) know what the current customers expect next, what their new customers love, and what feature(s) are missing from the product that cost sales. They promise software releases, patches, and demos that Alice and her development team really should know about more than two days before.

Third, there’s Marketing. New features get promoted to the market (hopefully after they are done!) and can cause surges in users. The latter is kinda important for both Operations and Security to know about.

Fourth, there’s Finance. If Alice wants a new laptop, or more tokens, or to buy a new set of tools (compilers, or editors), she has to make a case to finance. It’s much easier to do if she has good connections there.

A really smooth operation has all the engineering teams, sales, marketing, and finance working together in harmony. Easier said than done.

When is the last time anyone in your development, operations, or security teams had a meeting with marketing, sales, or C-suite?

Should this be a regular thing? Probably…

Finally, your Admin team might be invisible but who makes sure there’s coffee/tea and doughnuts in the meeting rooms? Who makes sure that the meetings rooms are not double booked? Who makes sure that all the tiny annoying impediments are just not there? That’s right, the admin team. You’ll know when you have a good one when nothing goes wrong.

An Ice Breaker

Here’s a way to break the ice between all those teams: Get two teams (does not matter which) into a room and have a 15 minutes presentation from each about what they do. Then, brainstorm what each team can do to make the other’s life easier. An hour, you can do that on Friday afternoon when everyone is pretty much done for the week.

Then, name a champion in each team (volunteer!) who will be the first point of contact and champion for the other team in their team.

Yes, it is that easy.

A pitfall of over communication…

Meetings are the real alternative to work…

Yeah. That’s the pitfall. Talking too much and inefficiently does lead to extraordinary waste. The cost is not just in resources (time and money), but also burn out leading to tiredness and low morale.

Meetings for meeting’s sake is an anti-pattern and should be avoided at all costs.

Booking some time in your calendar for focus is always a good idea. Make sure at least half your day is for doing, not talking about doing. As all guidelines, this one will vary according to your role and your environment.

For meetings, start with 30 mins max. Then, get efficient to reduce it to 20 then 15. No agenda, no meeting. Not talking about the agenda: leave. ¯\_(ツ)_/¯ Harsh? Maybe…

Effective communication is a skill. As all skills, it can be learned.

Conclusion

“Individuals and interactions over processes and tools”

This is one of the four pillars of Agile, written over two decades ago, to address the problems of software production at the time.

Frederick Brooks in the Mythical Man Month, first published in 1975, states that communication is vital in avoiding disaster. That was 51 years ago!

We can go even further back to 1936 (90 years ago) and How To Win Friends and Influence People by Dale Carnegie who teaches you how to communicate effectively.

This should not be news to anyone, and yet ask anyone in tech, or tech adjacent, and they will be surprised. 🙄

…

Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.

How about getting in touch to see how we can help you?

---

1. Otaku (おたく, オタク, or ヲタク) is a Japanese word meaning “to be alone”. ↩

2. True story. ↩