The challenges of software development in early stage companies.

By Yann Le Roux Falvey

Startups and smaller companies often run into the same software development trap of developing solutions too quickly in order to sell and generate revenue. However, this approach often means trouble as it can pose significant difficulties in the long run.

The issue

Among developers, when something needs to be rushed into production like a fix for an urgent defect, we use the term “quick and dirty”. And it means exactly that. When code is rushed and is not properly checked, reviewed and tested, it can “rot” over time and become unmaintainable very quickly. When a “quick and dirty” fix is deployed, the developers will typically promise to have another look at it later, but because of other priorities, it usually never happens.

In the case of startups, new products are rushed into a production state because they need to generate revenue quickly. The problem is that whatever code makes it to production first will remain for the years to come, even if the quality is substandard.  

Startup companies are often characterized by a higher proportion of staff turnover than more mature companies. The higher the turnover of developers, the more likely the code base ends up becoming an inconsistent set of coding styles and approaches. Different technologies can also be introduced without proper agreement, just because one or another developer likes it better. The same issue can arise when the development is outsourced, without any rules being specified or guidance being given as to quality or design.

If the startup is successful enough, after a few years, the development and delivery processes usually become more structured, but by then the code will have  become difficult to maintain. And enhancing the code at that stage will require a considerable time and resource investment (that the company may not be able to afford) just to bring it up to scratch. In some cases, products may need a complete rewrite so they can somewhat “be future proofed”.

So how do we address these issues and how can we try to avoid them or at least minimize them?

Possible solutions

In order to avoid the issues and traps described above, a few simple steps can be taken very quickly by someone with experience in development and project management (Agile style). A checklist of these steps should be drawn up before any code is deployed.

1)     Define a simple development process from day one

Make sure your developers do not have complete freedom when developing your applications. You need a set of rules defining the development process. Those rules should include key points such as coding style and naming conventions, and some level of unit testing and integration testing. The quality of your code is key from day one as it will ensure the code will be future proof. The tests will serve as quality control and they will define a certain level of documentation to explain what your code is supposed to do.

2)     Adhere to some level of normalization/standardization in code writing

As mentioned in the point above, you need to set in stone a list of rules regarding coding style and naming conventions. This will allow you to make sure that your code is consistent regardless of who was involved in writing it. It should be  easily understood by anybody new coming on board. This point also targets the technologies you are using. Try to avoid multiplying the frameworks, and keep your code simple. A new technology which looks “cool” might be discontinued in a few years and make your code fragile and unmaintainable if not carefully considered before being used.

3)     Protect your code and your business logic

When you design and implement an application, you must define requirements and an architecture. The business logic is where the most important part of the system is defined. You must protect it, as this is the heart of the business. The GUI (Graphical User Interface) is always very volatile and changes a lot. The data layer (Database or other source) can also change often. What is in between is the most important part of the system, this is your business logic. Its quality should be proven and tested and the source should be protected and backed up. Source control systems are available to avoid mistakes where a developer’s laptop might crash, and the code disappears. Code should never get lost!

4)     Use some tools for quality checks and automated testing

Today, we have a lot of choice of tools to use to check the quality of the code and to automate its building, testing and deployment. Many of those tools are free and offer a lot of functionalities and possibilities. Decide on your SDLC (Software Development Life Cycle) and choose a list of tools fitting your needs for each level of the SDLC. When defined, make sure that all developers comply with the agreed use of the tools. This will make your development process faster, smoother and most effective and again it will give all your developers a consistent approach to software development.

5)     Encourage code reviews and peer programming

Code reviews and peer programming are very useful. They allow developers to be familiar with what other developers are doing in their team and elsewhere. It also allows them to be more critical about the code of others so that obvious issues can be detected early. This will also force all developers to be aware of the coding standards,  highlighting when others are not complying. Peer programming is very interesting and useful when a developer is stuck on some task and the solution seems to be trivial. I have often experienced the case where I was staring at a piece of code for hours, trying to find a solution to a problem. Then suddenly, someone would look over my shoulder and suggest something new in a few seconds. A second pair of eyes gives a fresh perspective which is usually very useful. When new developers come onboard, code reviews and peer programming should  be a key part of their training.

6)     When possible, training on clean code is very useful

Clean code is a philosophy which takes time to fully understand and master as a developer. Training on clean code is very useful and it will make your developer’s life easier and their coding styles more consistent and compliant with your standards. As a lot of it includes unit tests and refactoring, it is also important for the quality of the code which is delivered. Test-driven development is also a route you may investigate.

7)     Define a simple and clear technology stack

As mentioned above, you need to define and agree on a simple technology stack. Developers can “go wild” on this front as new technologies are always very attractive, but introducing a new technology always has a long-term cost. Pick simple technologies and investigate how difficult they are to upgrade and/or replace in the case you want to be able to change later on. If you create simple small/micro services, do not use big heavy frameworks as they may have a very negative impact on performance. I would recommend looking at technologies which are already around for a while and have proven themselves. This way you will  get a lot of support in case you face obstacles when implementing them. Of course, if you are working on POCs (Proof of Concept), the use of new technologies may be advised to prove their use to you.

Always be aware of your “technical debt”, and set up a simple approvals process when introducing new technologies or upgrading/replacing existing ones.

To Summarise

In this article, I tried to explain that when we start developing new products in a rush, we may forget some important steps which will have a negative impact in the long-term. Applications are expensive to develop but they can be even more expensive to maintain and enhance if not implemented in a sensitive and efficient way. By going through a simple and quick definition of principles and rules and enforcing them amongst your developers, you can avoid a lot of problems and mistakes in the future.

Of course, this will not avoid everything, and lessons will still be learned along the way. But you should have the right tools and processes to deal with issues and improve on them when the time comes.

The quality and safety of your code should be your top priority. And given that today there are so many tools out there, available for free, there is no excuse for poor code anymore.

Tips For Aspiring Entrepreneurs – By Sean Killeen

Some years ago, as I was involved in getting the business off the ground, a Flemish friend took an active interest in my pursuits. We were sipping a coffee one day in Antwerp, and he unexpectedly he sprung the question: “Hey Sean, what’s the difference between you and others?”.

Somewhat perplexed by the nature of this enquiry, and suspecting he may have been observing my movements a little too closely for comfort, I spurted back “What do you mean the difference?”

But he insisted with his question, and repeated: “what is it makes you different to others?”

Knowing that I was a mere mortal soul no different to any other, I hazarded a thoughtless guess, in an attempt to extricate myself from this increasingly awkward moment. “Maybe I’m a bit foolish?” I suggested. This of course was in reference to my reckless leap into the unknown associated with trying to start a business from scratch – at the best of times a rather scary experience, well known to any enterprising spirit having decided to squander their savings while out of gainful employment.

“No, no, that’s not what I meant”. And leaping to the rescue, he exclaimed “You’re different because you’re actually doing it!”

In fact, what I think he was referring to was the fact that I was trying to start a business, rather than just talk about it, or fantasise about some new world in the making. Ie. whereas others would love to do what I was doing, they just wouldn’t, for fear of failure, or getting it wrong, or losing money, or taking too much risk, etc.

So, from one simple man to another simple man, his statement made me realise that I had already taken a major step into the unknown, perhaps without realising the madness of it, to kick start this business venture. And this impulse was a differentiator in itself.

Another important moment, also in the early days, was a meeting with a qualified business coach. One of his peculiar techniques was asking the “so what?” question to would-be entrepreneurs, to “stress test” the solidity of their projects.

I was no exception. After hacking my way through an explanation of the business plan, and trying to articulate the central proposition to him, I got the “so what?” treatment.

Not matter how compelling I thought my propositions were, for instance “we’ll revolutionise the telecom industry by eradicating fraud” or “we’ll enrich end-user’s lives by providing them a totally secure mobile experience” or even “we’ll make money grow from trees!”, I was taking a bullet at every turn.

A short succession of so what’s later, and much perspiring, I started running out of intelligible things to say. It became embarrassing, and I would have preferred had the earth swallowed me up rather than endure this gruelling session. But my coach knew this only too well, and I could see he was rather enjoying the moment, until he finally relented.

This experience, however uncomfortable and distressing, genuinely helped me focus my mind on what was important about this business plan. It helped me clarify and make sense of what I was trying to achieve, and gave shape to this project from its very outset.

As any aspiring entrepreneur will know, building a business is infinitely more complex than just sniffing a potential opportunity in a marketplace. So, may I suggest that before you consider emptying your savings account on an earth-shattering idea, apply the “so what?” technique to your business plan to test how well you’re doing.

Statistics Can Kill You

I love numbers. I love the story they can tell. But mostly, I love how they can deceive without lying.

Every day we are bombarded with statistics. Many of us are influence by what we read – me included. Sometimes I am fooled by them, so I have developed some rules to protect myself.

Rule #1: Be Sceptical. When at University in the 80s, I read an article in the Daily Mail that suggested a young boy spent £300 a day (money he stole from his parents) to play Space Invaders at Dudley Zoo. Assuming the boy consistently played the shortest game possible, the zoo would have to open for more than 24 hours a day for this to be possible (I confirmed the game was only available for eight hours). I haven’t read the Daily Mail since – mostly because I spent my grant on Space Invaders.

Rule #2: Don’t believe someone else’s interpretation of the data – verify it yourself. In 2017, several news sites published the headline “being single will kill you faster than being obese”. It won’t. Being young and single is dangerous; being lonely, is more dangerous. So, if you plan to eat too much, do so with friends.

Rule #3: Measure the Significance. I mentioned to Alison, my wife, that a bottle of wine a week increases your risk of cancer. Her response “Do you want to strip all the joy from my life?! Didn’t you do enough when you forced me to marry you!” As it turns out, the study shows drinking modest amounts of alcohol modestly increases your overall lifetime risk of some cancers: statistically significant, but not personally significant. If you are going to quote statistics to your wife, make sure it will help her, not break up your marriage.

Rule #4: Consider the big picture. Back to Alison… if she were to drink one glass of red wine each day (1 1/8 bottles a week), she’d live longer. Supposedly, the protection red wine provides against heart disease and dementia outweighs the increased risk of cancer: although I image this study was sponsored by the wine industry.

Rule #5: Statisticians are humans too. There are good statisticians and bad statisticians and statisticians who are incented to ignore the facts. You don’t now which is which.

I often use statistics to win an argument. I promise to tell the truth, and nothing but the truth (but not the whole truth). I’ll never lie, but if its to my advantage, I may not put them in your context, I’ll conveniently omit key facts and ignore the bigger picture. These things are your responsibility.

P.S. If a statistic supports your argument, don’t look at it too closely. It is depressing to learn you are wrong. And depression can kill you.

Embracing Compassionate Leadership

As an avid reader and occasional practitioner of Eastern spirituality, I was recently approached by a like-minded Dutchman who happens to run a training course for the Armed forces of the Netherlands.

The subject of his course is Compassionate Leadership which is essentially about helping military leaders develop qualities that place others before the self. The term compassion means “to suffer with” and be able to empathise with the emotional state of another in a bid to alleviate or reduce their suffering. Granted, one might find this topic rather at odds with the vision of a highly organized military machine trained to kill on a battlefield.

The Dutchman’s request was simple: would I mind contributing to his coursework by providing an account of my personal experience of leadership. Why me I thought…half expecting a wry expression on his face. But as the conversation rolled on, I realised he had done some homework.

My entrepreneurial days have shown me that the most successful companies are those that can tap the huge potential of their employees by enabling them to become leaders in their own right, and empowering them to make important decisions that impact the growth of the business. They are invested with a sense of mission and purpose and given the opportunity to feel part of something greater than themselves, whether it’s in service to their colleagues, their customers, or a to wider community. Creating the right conditions for this to happen is what matters, but this requires a deep-rooted understanding and appreciation of what’s important in their lives.

The Eastern approach teaches us to let go of the ego – the truth-seeker’s quest of a lifetime, or many lifetimes – as it implies a gradual and progressive change in our state of consciousness. However, the starting point on this journey is accessible to us all, in the sense that we can grasp the meaning of compassion. It is a feeling that arises naturally in all of us, even if not obviously manifest, and we can already start to practice compassion in small everyday actions.

In the very same way that teaching today’s military leaders to take care of their soldiers is of paramount importance – introducing notions such as empathy, mindfulness, awareness, and the duty of care in a combat arms environment – the greatest of achievements will hail from leaders capable of acting with compassion, by putting others first, and watching over their mental and emotional well-being.

I like to think of our business as one that recognises every team member as an essential thread in the overall tapestry of the organization, working in an environment in which the qualities and attributes of compassionate leadership can excel. A place that personifies the core values that give our working lives meaning, and a deeper sense of belonging and purpose, as we work collectively towards the greater good of the customers and communities we serve.


In 2012, Google’s neural network taught itself to recognise cats. Since then, there have been significant advancements in artificial intelligence and machine learning. So, why do I still feel nervous when someone asks, “how does your FMS identify new frauds we don’t know about?”.

Well, let’s put this into perspective. To recognise cats, Google combined a large team of the brightest minds with 16,000 computer processors (CPUs) and a lot of time. The people that ask me my least favourite question aren’t thinking in that kind of scale. Furthermore, although some cats are fraudsters, many are not.

Machine Learning is all about giving (a lot of) data to a computing device and asking it to learn something from it – hopefully something useful or interesting. Broadly speaking, there are two approaches to learning: supervised and unsupervised. Supervised learning is analogous to attending a class where the teacher teaches you geometry; unsupervised is like giving someone a tin can and asking them to discover something interesting (like how many baked beans it will hold or the value of the constant p).

Putting this in our context, supervised learning might help you to discover new instances of known frauds (you give the computer previous examples to learn from); unsupervised learning might help you discover frauds you were previously unaware of.

It is not unreasonable to expect that the application of unsupervised learning will uncover new frauds. But it is unreasonable to expect that it will only uncover new frauds. Put simply, you are just as likely to learn about baked beans as you are about the value of p.

To demonstrate this, I applied a clustering technique to the data of 5,347 roaming subscribers. To make it easier, I only considered their outgoing, voice calling records. After a fair amount of effort, I came up with five clusters (see below).

According to the algorithm, most subscribers (5,158) behave similarly. The 139 black dots are anomalies: that is, they are subscribers who behave differently from anyone else. Are the 139 subscribers fraudsters? Or are they your best subscribers? Or perhaps they are baked beans? The answer, of course, is that I don’t know.

With enough time and effort, I could investigate the 139 subscribers (or the subscribers of other small clusters) and make my conclusion. Luckily, though, I know something about this data. I know there is a single fraudster (which can be found by analysis of a few calls); and that fraudster is one of the 139. Does this mean that my efforts were successful? No, of course not. By the time I have investigated 139 subscribers, the one fraudster will be long gone – or at a minimum taken you for a lot of cash.

There are also some other things I didn’t tell you. By changing the parameters of the algorithm or adding/deleting characteristics of the subscribers, I get a completely different makeup of clusters. Simply put, machine learning is easy; getting good results is not.

Searching for something in a hay stack when you don’t know you’re looking for a needle takes a lot of time and effort. You will find the needle in the end and you might find some other interesting things along the way, but it isn’t as easy as you expect.