Before the Internet became a global network connecting millions of devices, it was a simple research experiment connecting a handful of institutions. In the beginning, the number of unique internet addresses could be measured in the tens. As the network expanded that number quickly grew into the hundreds and thousands and it became difficult to remember and type in IP addresses for each of these hosts. To manage the growing number of network hosts, a simple text file, called HOSTS.txt recorded each host and their IP address. To add your name to the hosts file, you needed to send an e-mail describing the changes you wanted to apply. The authority for the HOSTS.txt file would apply these changes once or twice a week and anyone who wanted to grab the updated list would periodically FTP to the canonical source, grab the latest file, and update their own list of hosts. Naturally, as this small network expanded into, and was eventually replaced by, the Internet, this solution became untenable – there were just too many hosts to keep track of, keep consistent, and to serve from a single canonical file using FTP and manual updates. HOSTS.txt did not scale. ...

Leading software companies have discovered that developing capable technology is not enough to guarantee long-term success. To stay relevant, software leaders need to develop and support the repeatable systems necessary to develop and sustain knowledge and expertise. Many organizations have taken inspiration from Spotify’s culture and adopted the concept of a guild or community of practice to connect engineers throughout the organization and steer them towards common goals. As organizations adopt this model, what is often missing is a clear understanding of the purpose of communities of practice and a repeatable process for developing the communities to their fullest potential. This post provides some guidance based on our experience developing a community of practice at Workiva, it also includes some best practices from the book Cultivating Communities of Practice. ...

Complex processes may require collaboration and coordination of many components. We can model such processes using a Design Structure Matrix to represent information flow among the components, and then optimize the process to avoid rework and downtime. As a simplified example, consider a project with only two tasks: “A” and “B”, and a directed graph representing this system where a vertex represents a task and an edge represents the flow of information between tasks. Depending on the process being modeled, these two vertices can be arranged in one of three different configurations. ...

After graduating from university my (future) wife and I travelled and worked in Kenya as part of the Commonwealth of Learning — an intergovernmental agency dedicated to open learning and distance education. As fortune would have it, my brother had an internship in the neighbouring country of Tanzania during the same time period, and we were able to meet for a few days to enjoy the East African coast in the city of Mombasa. ...

To meet the challenges of scaling systems in size, scope, and complexity, it is useful to look at new approaches and theories to analyze, design, deploy, and manage these systems. A Design Structure Matrix (DSM) is an approach that supports the management of complexity by focusing attention on the elements of complex systems and how they relate to each other. DSM‐based techniques have proven to be very valuable in understanding, designing, and optimizing product, organization, and process architectures. This article explores in more depth how we can use the techniques developed by the design structure matrix community to improve software architecture. ...

A queueing system can be described as the flow of items through a queue. In a queueing system, items arrive at some rate to the system and join one or more queues inside the system. These items receive some kind of service, and when the work is done, they depart the system. A simple queueing system Little’s Law is a pretty simple model of queueing systems. $$ L=\lambda W $$ Little’s Law says that the average number of items in a queueing system, denoted \(L\), equals the average arrival rate of items in the system, \(\lambda\), multiplied by the average waiting time of an item in the system, \(W\). ...

Python 2 will retire in about one month. Given many organizations continued reliance on it, you may be asking “Now What?” What does this change mean for a company that heavily relies on a deprecated language? Many times, the Python 2 deployed in an organization still generates a lot of value. Yet as this code continues to age, you expose ourselves to potential security vulnerabilities with fewer avenues to address them. To continue running Python 2 and safely address this challenge, you have three options: ...

Large organizations have a lot of layers. From the C-Suite that is concerned about strategy and vision, to middle management who are executing on projects and programs, down to individual contributors working on project features. These layers provide a number of advantages, all derived from being able to better manage complexity. For example, layers provide a nice separation of concerns: as a software engineer, I don’t have to worry about tax codes and payroll because the finance department can take care of this. As an intern, I don’t need to worry about the global marketing strategy, I can just take care of implementing the widgets we need delivered to customers. ...

To deliver real-time communication (RTC) from browser to browser requires a lot of technologies that work well together: audio and video processing, application and networking APIs, and additional network protocols that for real-time streaming. The end result is WebRTC — over a dozen different standards for the application protocols and browser APIs that enable real-time communication for the web. ...

There is no one-size-fits-all cellular network used across the world, and trying to understand how cellular technology works across all the different uses cases is difficult, if not impossible, in a short blog post. So, rather than trying to understand every possible standard, this article will focus solely on LTE networks. Fortunately, competing standards and implementations are roughly similar and we can extrapolate any lessons learned about LTE to other cellular networks without much difficulty. ...