Hi! This is my first post in this blog. Although it’s meant to be a tech blog, this post is the first part of a series where I mix software engineering, its practices and methodologies with a business background and why do software companies need to move towards continuous deployment. Stay tunned!
The world has changed a lot in the last 100 years. But if we stop to think about it, did it change more from 1900 until 1970 or from 1970 until now? Perhaps we could define the world evolution as an exponential function. Everyday we use the technology we know and innovate, creating new technology based upon the old one. This evolution pace is becoming faster and faster. It’s like the Moore’s Law applied in real life. Crazy. Given this, every (decent) businessman knows that his company needs to adapt fast to market changes. If you cannot deliver, your competitor in Australia, China, India, etc will do. If you cannot change fast enough, your competitors will eat you.
With all the technological boom that happened in the last 10-20 years, people should stop saying that software will eat the world. Software has already eaten it. We live in a world where everything is manufactured, controlled or served -* as a service - by software. I think that we could even use a motto to describe the days we’re living in: “Automate… or be automated”. I will not discuss if this is a bad or good thing, but let’s think about what are the business-side implications of a world dominated by software.
From a technical perspective - finally! - this “new” need to adapt, react, build and fix faster than your competitors and deliver good software to your customer brings a lot of challenges to the industry:
Given these challenges, how can we transmit to business the need to be prepared to change fast? How can we communicate that the work we do - the invisible one - will (is) allow(ing) our company to respond in a quicker way to new business requirements? I think every software company that grows to a certain point has this challenge. Below, I explain my thoughts about it and how I think a team could try to solve it. The word team is very important here: if you’re expecting to change everything on your own, you’ll fail 99% of the attempts. You can evangelize, you can advise, you can discuss, but in the end, what matters is what the team as whole thinks and what works for you. Remember: there’s no silver bullet.
I’m assuming here that you’re familiar with agile methodologies (mainly scrum), software engineering and continuous integration tools.
READMEfile that any new developer can read and, at least, set-up his machine.
READMEfiles, and host in-house tech talks. Ideally, anyone should be able to perform any task, in a small team.
changelog, send emails to your and other teams after a deploy, moving tasks from
Q&Awhen a pull request is created, etc.
If you do a lot of work each week and your colleagues and management can’t see it or you can’t explain the added value of your team’s work regarding business goals, that is not right. Here I’m using the word visibility to show the relationship between your team and other teams and management. Although internal visibility is important as well, we are focus in communicating outside the team here. These are my thoughts:
changelogof the whole sprint so anyone can read it.
In this post I started by giving some context about how the business evolved in the last couple of years and the impact of this evolution in software development teams. Then I stated the high-level goals when implementing continuous deployment systems and I started to answer how to achieve them. In the next posts, I’ll focus more on scaling, team procedures, documentation, architecture and more. As a first conclusion, I think that alongside with the right tools and processes to develop software - which is important! - you must be able to communicate effectively both internally as a team and “externally” to other departments and stakeholders within your company.