From startup to leader, the secret truth of software engineering

What Spotify, Criteo, Uber, Airbnb and Netflix have in common? Of course, they are young tech companies extremely successful in their fields. But beyond that, they have invested a lot in software engineering. Just like other great tech companies like Google, Facebook or Amazon. And they are very vocal about it: Google Developers, Spotify Labs, Facebook Engineering Blog, Criteo Labs (and many more), the engineering is clearly a primary concern.

I believe that there is a trend here: for a tech startup to become a leader, it takes many things, among which good software crafting practices play major role.

You are an entrepreneur? An investor? A CTO? Here are some reasons why you should really focus on software engineering.

First, let’s try to provide a definition of software engineering.

“Engineering” first (well actually second), is “the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations.” [Wikipedia]. In short, it means that we try here to use a scientific and rational approach to do stuff.

“Software” is the actual domain on which we apply this, ie any artefact of any size composed of code. That means anything from a simple command in a script to a fully distributed system of million of lines of code, from a desktop application to a web application, from a device driver to a social network etc.

Basically, software engineering focuses on the way software is produced and run by logically implement all the steps involved from the very first idea to operation of the running code.

When you start a software oriented business, or a new IT team in your company, the temptation to just skip all software engineering practices and jump only into the coding itself is strong. And for a (very) short period of time that can actually be OK. But soon enough, I would say you have a proof of concept, when you have few functionalities or when you reach more than few thousands lines of code, you cannot postpone anymore. Here are the reasons why.

#1 Because it saves time

Software creation, in many minds, is typing lines of code, and for this you do not need much than a text editor (we do not recommend MS Word). But many other activities are around, such as:

  • Building my code and working with different versions
  • Testing my code
  • Publishing or distributing the code
  • Assembling peace of codes together
  • Installing the code on-to where it should run
  • Documenting what the code change I just did is meant for

Software engineering has defined further the concepts around these needs. Packaging, releasing, loading… All these processes have to be carefully designed so that your R&D will not spent most of its time handling low level tasks.

A common solution is to invest in Continuous integration, Continuous delivery or even Continuous deployment. In a nutshell:

  • Continuous integration: build, test
  • Continuous delivery: build, test, publish
  • Continuous deployment: build, test, publish, assemble, deploy

Without entering into too much details (more on this in later articles), the concept in all cases is than the developer’s actions are limited to writing the adequate test and code and all the rest is just automatically done. And it saves time. A lot. There is no much figures around it, but it can hardly be much less than 50% gain. Some companies have reported moving from months’ to minutes’ time-to-market releasing on their services implementing correctly Continuous Deployment.

Most of the time it makes a huge difference in any market.

#2 Because you want to get the right product at the right time

Two years plans never met, extremely complex requirement phase, very long and painful test phases, a final product arriving after the users have changed their mind ten times… This model, inspired by industrial projects, is nowadays generally replaced by agile methods.

Collaboration, short feedback loop, constant inspection and adaptation is now supposed to be the norm. If well applied, the agile methods will bring you a lot. If badly applied, not much.

But not wondering how to work together is by far the worst choice.

#3 Because your product is here for a while

In our industry, it is pretty rare to work on short-lived products. It means that as long as you take shortcuts, you accumulate technical debt (in your coding and architecture) and “engineering debt” (in your practices).

Debt that you will pay at some point, either as large payment (large refactoring) or as interests (more and more difficult to change, maintain, deliver new versions).

Many companies, even among the largest editors in the world, have suffered very heavily by procrastinating the reduction of debt.

Investing in test coverage and test strategy and maintaining a good code sanity is vital for the durability of your products and by extension your company.

#4 Because you want the service to be up

Sadly, it is not enough to create the exact application your users need. The quality of service is as important as the provided functionalities.

How Google beat Yahoo? Among other things, the googlers invested in infrastructure as code and by this practice were able to scale, rationalize their hardware, to be faster and always up and running.

Scalability, availability, operability, response time… The so called non-functional requirements are nowadays key to any software provider that hopes to disrupt its market.

Once again, it is a serious investment that has to be done, but it can very well be the X factor between success and failure.

#5 Because it saves money

Good engineering practices dictates an automatic application of software changes. The reasons: faster, more reliable. There is no leader in this industry that apply changes manually.

Globally, many engineering practices, especially in the areas of operations and tests, advocate for automation. The era of agility encourages efficient methods to do low added value actions and to focus your energy on high added value actions.

It sounds obvious, but it is still common to see entire systems tested manually (which is not always better than not tested at all) or code deployment triggered by clicks from overloaded operators.

A lack of efficiency in these areas can quickly become a major issue: while you spend energy (ie money and resources) doing this, you do not invest in operational concerns, exploratory testing, non-functional requirements testing or other among many relevant practices where these professionals can help so much.

It is not a surprise that Netflix, followed by Amazon or Github are investing in Chaos Monkey testing[1]. They understand the importance to go further in automation to test even the one thing that no-one wants to see in a datacenter: crashing hardware.

#6 Because it is simpler

Say you are launching a startup or a new software product in your company. You recruit the team to work on this new awesome stuff and let them self-organize to build it.

The team has then two choices: define together how to work from scratch or reuse methodologies most adapted to the setup and elaborate from there the team unique ways. Guess which one goes faster and is more efficient?

Obviously, there are such alternatives only if in the team or elsewhere you find some strong knowledge of software engineering. Otherwise you are stuck with reinventing the wheel.

And that is actually the point: it is a lot simpler to rely on decades of accumulated wisdom on how to build a product or how to test or how to ship than to have to figure it out from scratch. It allows to focus on delivering the product and not on which branching strategy is the best suited for this or that purpose.

#7 Because you want your teams to be happy

So far we have covered time to market, durability, quality of service and obviously, money. All what an executive is concerned with for the profitability of his company.

I believe that the very first reason why some significant investment should be done on software engineering is for your staff.

As Richard Branson said, Companies Should Put Employees First[2]. The reason is easy to get: happy employees are doing a better job in all areas, including customer care, quality of service etc.

Can you imagine how frustrating it can be for a developer to see that his organization is so underperforming and so slow that the products he builds every day are condemned to mediocrity? That no matter what, it will always be a nightmare to see value reaching users and customers?

I know it sounds over-dramatic, but the last thing you want to see as a manager is your team turning into a disillusioned self-interested organization where nobody seem to care about what is effectively delivered at the end of the day.

And yes, a software company scaling with bad practices in its core will leave plenty of room for such situation to develop. Target happiness, use expertise in software engineering, you will get the rest.


In this article we have seen that software engineering has to be at the heart of the creation and maintenance of any software development unit. It is critical to put in place as soon as possible the right environment in which the team can continue to perform. It is crucial to balance the urge of deadlines and other business-related constraints with the mid term impacts shortcuts can have on your ability to deliver value.

We do not say that shortcuts are impossible and that to be efficient you have to follow every methodology around. We say that software engineering should follow a strategy, aligned with your business strategy, and that any choice needs to be carefully taken as it could impact the company viability pretty fast.

In this journey, you may need some support. In form of consulting to define the way to go or tools to simplify the implementation of a given methodology, Stenusys can help! Do not hesitate to contact us for more details.