Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Building software: It's all about thinking, acting, and effective communication

public://pictures/Shay-Tsadok-System Architect-HP.png
Shay Tsadok Machine Learning Engineer, Fundbox
This article examines the inner workings of software development teams through the prism of effective communication, showing how it is fundamental to building good software.

DevOps is hailed as the mediator that makes peace between the different groups in a software development organization by improving communication between all players involved. But what does effective communication mean? Is it having 20 people in weekly meetings? Or sending out emails with 12 people in the CC field? Quite often, those communication methods become barriers to progress, not enablers.

In the process of software development, you need effective communication channels at many levels: between the product and the end user (user experience), between the R&D team and IT/operations (DevOps), between individual team members (agile), and even between the different software components (architecture). In this article, I want to suggest what effective communication means in these channels and how it's fundamental to building good software.

From early days to agile

The software industry emerged from chaos. Most programmers worked on their own, some by choice and many by necessity, with little opportunity to interact directly with other programmers. Although people were laying the foundations for the future of computing, they were doing so, largely, by themselves.

But when people started working together to create order out of the chaos, the need for a process became clear, and the waterfall model emerged. Finally, there was a structured, sequential model for software development. The thing is, waterfall (and also the V-model that followed) had a few drawbacks: For one, the process was composed of silos of expertise with little interaction or communication between them. Communication only happened as the project moved from one phase to the next, and then, it was only in one direction. While waterfall development included a feedback loop, in practice it was too expensive to use. So most of the time, there was no going back. When a project became too large, communication between the silos became complex, and information was too often misinterpreted.

A few people, mostly developers, recognized the communication pitfalls of the waterfall model and developed new concepts that eventually culminated in what we know today as agile. It's no coincidence that most of them were developers. Developers worked in the central silos of the waterfall process, between the business analysts and the testers, and saw how information could be easily misinterpreted.

Agile puts communication in the center: small and frequent deliverables, autonomic teams, daily sync meetings, pair programming, and retrospectives are all features of agile that promote effective communication to achieve better results.

Did Google go out of their minds?

Remember the days before Google search? Internet search engines like AltaVista had a feature set that let you find a picture of a bear drinking from a beer can while playing guitar, all in just a few seconds?if you knew how to use the tools. But then Google came along and shuffled the cards with single-line search. All you get is one textbox, and that's it!

Google's innovative PageRank Algorithm had a lot to do with how rapidly the new search engine bloomed, but I think the simplicity and the "less is more" approach of Google's homepage was also instrumental to its success.

What does this have to do with communication? A simple and intuitive user experience (UX) makes an application easy to learn and easy to use. Consumers feel relaxed when using it, and they like to communicate with it. And since most consumers like good communication, they'll keep coming back for more.

TL;DR ?? not in my code!

When writing code, we think about aspects like quality, performance, security, extensibility, and scalability. While all of these factors are important, we must ask ourselves if we put enough focus on readability, brevity, and simplicity. Our code is what makes our product work, but just as we use our voice to communicate with others, code is our most fundamental communication channel to other product developers.

Famous books on software development, such as Code Complete and Effective Java, talk about best practices that simplify code and improve its readability. These involve simple steps, like giving meaningful names to variables, functions, and classes, keeping function size to no more than a single screen and maintaining small outgoing (also known as fan-out) class level interfaces.

Design patterns are ways to achieve effective communication. A single word triggers a wave of understanding when a developer recognizes the usage of a design pattern, and suddenly a complex idea becomes clear and simple. It creates an abstraction layer that simplifies things and, like any abstraction layer, promotes effective communication within the development group.

Richard Matthew Stallman's (also known as RMS) vision of free software has become a reality, and today, with the help of platforms like GitHub, we enjoy a vast selection of open source projects that we can use in our code. Using open source projects, especially ones with a vibrant and active community, offers the tremendous advantage of being able to reuse existing, well-trodden code, meaning you need to write less code yourself, making it easier to communicate to others. Moreover, you benefit from a large community you can communicate with to maintain the shared open source code.

Keep your marriage healthy with DevOps

Communication issues in software development are a lot like those in a marriage. You're happy with your partner, but then something happens out of the blue and things go awry. You start to avoid each other and generally don't communicate well. After you finally sit together and talk about it, you realize what went wrong, who missed what. Usually you discover that you lost the feedback loop. Eventually, you make peace and get back on track.

With on-premises products, organizations suffer from the same problems. You ship your product to hundreds or even thousands of customers, but now what? How do you get feedback when something goes wrong? How do you know where to put the focus for your next version? Not an easy task.

In contrast, SaaS products make these issues simpler to handle, incorporating methods like metrics driven development to keep the feedback loop alive and kicking. With production metrics, we can know how the "other side" experiences our products, and if we have short, continuous delivery cycles, we can react quickly.

The direct channel between developers and production is what makes this process effective, but as a product becomes bigger, it becomes more difficult to connect a problem or feedback from production back to its associated developer or team. This is where the microservices design pattern comes to the rescue. When a product is composed of several deployment-independent services, it becomes much easier to maintain a simple and clear channel of communication that relates service issues and feedback back to its development team.

Give your product a boost

Effective communication is key to building good software. As a software developer, you have many channels available to you, and you should use them all. You can communicate with your users by providing an intuitive and simple user interface that guides them through the app; you can communicate with other developers by writing clear code that uses known design patterns and idioms, and by using and sharing code through open source; and you can communicate with your operations staff through short, continuous delivery cycles that create a clear and actionable feedback loop.  

Ask yourself questions such as “Where does our communication break down?” or “What can we do to improve it?” Sometimes, improving broken communication channels is all it takes to give your product a boost.

Keep learning

Read more articles about: App Dev & TestingApp Dev