Keeping it Stupid Simple
The Key to Successful Software Development
As a tech lead or CTO, it's easy to fall into the trap of thinking that you need complex and sophisticated architecture to succeed and progress. You may need the latest and greatest technology or advanced workflows to stay ahead of the competition. However, this thinking can be dangerous and lead to unnecessary overhead and complexity.
During the last few months, I have been part of some companies' processes of modernizing legacy solutions. Most of these processes had already been undergoing for a while and had one thing in common: They were overwhelming and became complex early on.
The reason for that is quite simple. There's too much to learn and change in a narrow timeframe, while daily business is hunting one anyway. The outcomes of these migrations can be expensive, dangerous, and simply overwhelming—something an SMB should avoid going through and experiencing.
The way into a too-complex outcome
When you are on your modernization journey, most people aim to acquire the skills to implement like:
Containerization like Docker as a new foundation for software development
Continuous Integration and Deployment (CI/CD) as a workflow automation, which substitutes manual FTP-Uploads from the past.
Cloud as an infrastructure solution, mostly coming from on-premise infrastructure.
In general, these topics are essential and wrap up what I have experienced SMBs and Startups tend to see as a complete plan initially. But there's a catch that will inevitably lead to unwanted complexity.
People working with modern ways of software development for years will notice quickly that those topics are just scratching the surface. Starting with Docker, CI/CD, and Cloud in mind is a great goal, but getting there is complicated at first:
Containerization without Orchestration is just half of the story, and orchestration can quickly become an expensive burden when it's poorly tailored to the needs and capabilities of a company.
Continuous Deployment is excellent but requires a lot of experience, maturity, and a living DevOps culture. Implementing DevOps is a process that takes time, and specific mindsets and skills are needed to develop a flexible dev culture like DevOps successfully.
Cloud is a general term, but in reality, Cloud is a large field of technologies, services, and platforms with many different providers. Do you just lift and shift into the Cloud or prefer Cloud-Native? What about Serverless? Managed Kubernetes for a smaller company, or is it still too complex when "IT-Ops" is not an in-house resource? What is the right pick for you? Early on, the wrong decision can run the company into high technical debt.
These are some examples of how the plan gets shattered early on when assuming this topic is simple. I saw frustrated CTOs and developers and was one myself a while ago. The articles of this series should help others get ideas to avoid running into possible traps themselves.
Simplicity is essential, but how do we get there?
Reducing infrastructure to a minimum is a crucial step so that, in an ideal workflow, the developer can handle infrastructure by herself or himself.
The challenge is not to avoid modern ways of development; it's to find a simple way to make complex systems easy to use in daily business. What counts for a small company is a fluent and flexible development process, which constantly adds, in small steps, to the company's outcome without becoming a problem.
When planning your development workflow, ask yourself if you need a specific step, especially when additional people with different skill sets are required to accomplish the step successfully in daily business.
Make sure you understand the "Why,"; which will often be the development of a product. Thus, a continuous flow is critical, and everything else should evolve around this. Reducing infrastructure to a minimum is a crucial step so that, in an ideal workflow, the developer can handle infrastructure by herself or himself.
Regarding review processes: Do you really need additional review steps? In most cases I've experienced, the problem was not the developer "misunderstanding" a task; it was the task not being precise and simple enough and leaving too much room for questions.
Lay out the shortest possible flow from a development machine to a production platform.
Use only services you really need, but consider using them managed. Especially for an SMB, GitHub Actions can be a better pick than GitLab on-premise. Remove the point of failure already in the beginning.
Reduce the necessary personnel and skills to a bare minimum.
Understand your final goal and why you need to achieve it this way.
Grow a DevOps Culture early on.