Keeping it Stupid Simple: The Key to successful Software Development for Small Businesses

As a small business, 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 months, I was part of some smaller companies' processes dealing with the modernization of Legacy solutions. Most of these processes were 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 kinds of migrations can be expensive, dangerous, and simply overwhelming. Something an SMB should void to go through and experience.

The way into a too-complex outcome

When you are on a migration journey from a legacy solution to something new, most companies aim to acquire the skills to implement:

• Containerization?like Docker as a new foundation for the 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 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 needs to develop specific mindsets and skills to implement 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 a resource in-house? 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.

Keep your pipelines and infrastructure simple and understandable.

The larger the scopes of the updates are, the more need you have to run all tests as a requirement for Deployment.

I often see small companies starting with their pipelines by setting up an on-premise Jenkins, GitLab, or TeamCity. I did it years ago, but I recommend it today only if you have a very good reason for it. On the other hand,?giving away the burden of running the infrastructure for the pipeline itself is a good relief because you still have many other challenges.

Keep the pipeline as short as possible. For example, if you have a web app consisting of some services and a static website, make sure you build them, run your tests, and deploy the artifacts straight after the change was pushed to git; even if the deployment target is a staging environment, ensure you don't implement any manual breakpoints like reviews or unrelated tests.

If you have long-running End-to-End-Tests, avoid setting them as a required step during the pipeline. Instead, make sure you can fast-forward a change to production in case something goes wrong. To ensure quality, you can implement a staging environment to continuously deploy changes and run your tests.?Regarding E2E-Tests: It indicates a poor development process if you depend on E2E testing during Deployment. The "E2E-Testing" should not be done during the Deployment but during the development cycle before the dev pushes the change. Thus, E2E should not be required in a pipeline!

Deploy in small badges. The smaller the changes are, the less damage they could produce, which adds to simplicity and flexibility. With a short pipeline and minor changes, you gain performance and actionability, which will lead you after a while of practicing an actual Continuous Deployment workflow.?Rule of Thumb: The larger the scopes of the updates are, the more need you have to run all tests as a requirement for Deployment.

Keep your infrastructure stupidly simple. The worst thing your dev team can face is a broken infrastructure that the devs need help to control or fix quickly. Unfortunately, today's requirements to run Kubernetes or Docker Swarm clusters yourself are high. It's not done with just setting them up the first time. Maintaining and keeping them secure and reliable is not just a different skill set than development; it's a high-cost factor and risk for the business. Instead, solutions like?Digital Oceans App Platform or AWS ECS?provide highly managed platforms that developers can control.?Rule of Thumb: If you don't have a particular reason, like special scaling and performance requirements, avoid managing your infrastructure yourself, especially if you need solid IT-Ops personnel.

An example of a slow and risky process

As I mentioned before, the idea of a fast and flexible process is to boil it down to a workflow you only need developers for. In the following example, I want to display how things are unnecessarily complex during the development cycle.

So what is wrong then? First, there are too many steps for workflow automation, where the goal is to deploy features (values) to the client.

Put communication before development, not during

No, in most cases, we could route back the origin of this problem in an inadequate, half-baked, and too-large issue passed to the developer.

Communication in the form of reviews is a general problem. Why do you need to "review" your developer's work before deploying it? Don't you trust the workflow or the developer? Does the developer need help reading the requirements correctly? Is the maturity level too low?

No, in most cases, we could route back the origin of this problem in an inadequate, half-baked, and too-large issue passed to the developer. The task wasn't small and precise enough and was held too general. A single Task for more than 8 hours of work is too much for most developers to be sure to ship what he or she was asked for.

Solution:?Make sure a task is so simple and clearly defined that a review isn't necessary to deploy, and the developer can prove himself that the Definition of Done is fulfilled. Could you keep the tasks as small as possible? A positive side-effect is a motivational one; when things get done quickly and frequently, everyone feels things are moving. If mistakes happen, they only happen in small scopes. Don't worry; you can always code-review asynchronously.

?

Avoid Pull-Requests

If you put too many checkpoints into your process, the developers won't build up maturity. Because in their mind, there will always be "someone" responsible before the changes get shipped. That's human nature and not desirable in a deployment workflow.

PRs are a standard method to control and review processes. But what do you actually check? If you cannot trust your developers on quality, work on it. If your definitions aren't good enough, work on that instead.?

Of course, you can always refactor later but keep overall performance as a priority.?If you put too many checkpoints into your process, the developers won't build up maturity. Because in their mind, there will always be "someone" responsible before the changes get shipped. That's human nature and not desirable in a deployment workflow.

Solution:?Review code asynchronously and let developers link their git commits to the issues or tickets. You will have enough time to work with your devs on quality later and refactoring. Don't branch; go for a typical "develop" branch or trunk-based development. A Developer should be responsible for his work, and if she or he has any questions, they need to decide when to ask someone. Better use slack instead of a PR for this :)

IT-Ops still provides the infrastructure stuff.

Some companies have IT-Ops or Cloud-Engineers as freelancer resources available, but I recommend putting Ops into your devs' hands. It's a core capability.

If your developers can't describe the infrastructure well, you have a problem and are not a DevOps company yet.?The problem is that you have an entirely different skillset as a requirement when you have separated IT-Ops. With that, you need to have these skills in the form of personnel available. Some companies have IT-Ops or Cloud-Engineers as freelancer resources available, but I recommend putting Ops into your devs' hands. It's a core capability.

There are other reasons, like product quality. If a developer knows the Cloud-Native infrastructure well, he or she knows better how to develop the services to fit into the platform; in other words: Develop the software natively for the Cloud, in other words, for the infrastructure.?

Another good reason is the reaction speed. The developer will find problems like performance issues faster in the current app if the dev can overview the whole system instead of only some logs.

Finally, modern software patterns like microservices or serverless functions already depend on infrastructure know-how in the development environment. Therefore, it doesn't make sense to split this into several responsibilities.

Solution:?Great platforms are available that provide all you need to start and progress. Platforms like Digital Oceans App Platform are purely developer-orientated solutions to manage your services, apps, tasks, deployment process, network, load balancing, etc. For most SMB companies I have worked with, this platform is all they need, even when growing the business. A great thing here is that you can always switch to Kubernetes or other orchestrators since the App Platform works quite well with cloud standards.

Conclusion - Isn't that a bit too much?

When people are bound to their habits and develop safety spaces, they tend to resist change. Even when they face problems regularly, I know that because I was one of them once; and still, change is a challenge, and I predict it always will be.

But do you think a change is necessary? Continuous enhancement leads to ever simple ways of work. This culture of becoming better removes obstacles, reduces risk, increases performance and output, and, most importantly, reduces mental overhead to prevent people from burning out.

I recommend aiming for the most simplistic way you can imagine. Boil it down first, and then add what's really necessary to add. Never add something because it seems to be trendy.

Allow yourself to experiment and celebrate failure. But always keep the goal in mind to stay simple and flexible.

Others may describe their ways in lean or agile approaches. I got the best results by trying out things and finding what works best for smaller teams and companies, which I worked with and was responsible for most of my career.

You have read this article and think you are in a similar situation?

We were in similar situations for many years as a SaaS company. In the last few years, we have worked together with several other companies and realized that we could help and enable others to achieve their goals.

With the CTO Fellowship Program, we have started to offer this as a companion-like service. Instead of having workshops and training, we talk to you over a longer period of time and act as if we were you, the CTO or VPE. Treating your problems as ours. Becoming your fellow.

We understand that #DevOps and #CloudNative aren't achieved overnight, so we meet once a week for 2 hours to talk and challenge you with new ideas that you may not want to hear at first. We are tackling basics like mindset, skills, and culture, going to larger topics like infrastructure, architecture, or optimized workflows.

Every company is unique; every journey is different, and so is yours. You decide when to start and when we have reached our destination. We enable you to walk alone.

Interested? Take a look at our website or ask us on LinkedIn ??

Personal Blog https://adrianstanek.dev

Webbar https://webbar.dev

LinkedIn Webbar https://www.dhirubhai.net/company/webbar-dev

Digital Ocean: https://m.do.co/c/d789023b5a93