Connecting Technology to the Needs of the Business

All healthy technology discussions should begin with business goals and use those goals as a reasonable set of guidelines to focus technology investment decisions. These business goals are best articulated from a deep understanding of what the company, the product team, or the marketing team want to accomplish. In a business-first model, technology is forced to balance the desires for technical effectiveness and efficiency with the operational needs of the business. [Read More]

The Most Important Criteria for Choosing a Programming Language

Use a Language Your Company Can Support

One of the recurring themes of any technology discussion is programming language. It doesn’t take much effort to find blog posts with dramatic headlines (and even more dramatic comments) about how shipping a new project with Haskell or Clojure or Elm improved someones job, marriage, and life. These success stories are posted by raving fans that have nothing but the best to say about their language of choice. A common thread running through these posts is that they are typically tied to building out new, greenfield projects. [Read More]

Making Modular Monoliths Work

Think Slices, not Layers

Microservices have become part of the software engineering cultural zeitgeist to the extent that alternative approaches to architecture and development are treated as somehow inferior. Given the challenges that running microservices present, I usually recommend beginning development of new projects and systems as a single deployable unit — the monolith. Sam Newman, in the book “Building Microservices”, agrees with this approach. He recommends leveraging microservices only if you can become convinced of the benefits for your system, not as a default for every project. [Read More]

Handling the rudder as an organization grows

In a shopping cart, the swivel wheels of the cart are set in the front, and the fixed wheels are set in the back. Now picture yourself pushing a shopping cart backwards. Almost naturally, you swivel the cart to move the front end to one side or the other before beginning to push the cart. Now picture yourself pushing a shopping cart backwards, on an ice rink. Here, the cart keeps sliding around even after you’ve stopped pushing it. [Read More]

Above-the-line and below-the-line

Making sense of the complex world of software

Engineering, for much of the twentieth century, was mainly about artifacts and inventions. Now, it’s increasingly about complex systems. As the airplane taxis to the gate, you access the Internet and check email with your PDA, linking the communication and transportation systems. At home, you recharge your plug-in hybrid vehicle, linking transportation to the electricity grid. At work, you develop code, commit it to a repository, run test cases, deploy to production, and monitor the result. [Read More]

Building Learning Communities

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. [Read More]

Optimizing Processes Using a Design Structure Matrix

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. [Read More]

Interdependence and Self-Reliance

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. [Read More]

Improving Software Architecture Using a Design Structure Matrix

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. [Read More]

Riding the Architecture Elevator

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. [Read More]