Tuesday 17^th November, 2020:

XINTEC has today announced the appointment of Paula Cain to its board of directors.  Paula is an accomplished commercial and portfolio leader with over 20 years’ experience in the ICT industry across the UK and Ireland. She is currently working as an independent advisor helping clients with business growth strategy and execution.

Commenting on her appointment, Rob Durran, CEO, XINTEC said, “We’re delighted to welcome Paula to the XINTEC board of directors. Paula’s expertise and guidance will be central to the development of our business strategy in 2021 and beyond, including the launch of our exciting new suite of customer focused services”.

Paula started her career with BT in the UK managing the rollout of broadband and dial IP before quickly progressing to lead on networking, ICT and mobility propositions. Paula has held several senior management positions in marketing, contract management, and customer experience. She was Head of Strategy in BT in Ireland before undertaking a general management role in the UK to drive incremental growth in high value markets.

Paula’s specialism includes taking a customer-centric approach and using insights to create highly effective go-to-market plans. She has a proven track record in developing market leading propositions and commercial strategies supporting a range of markets, customers, and technologies.

Paula holds an MSc in Business Telecoms from University College London and a BSc (Hons) in Systems Modelling from Sheffield Hallam University. She lives in Dublin with her husband and two children.

XINTEC today revealed its new suite of customer service offerings, aimed at providing customers with best in class technical solutions backed by its team of skilled fraud & revenue assurance experts.

Rob Durran, CEO, XINTEC, said, “The complex nature of fraud and its ever evolving threat to the telecoms industry means operators are having to look outside their internal resources to tackle this issue. We understand that our customers want best value results from a team they can trust. XINTEC customers benefit from not only our intelligent network of fraud and revenue assurance solutions, but also a skilled professional team of experts who they have direct access to on a daily basis for reporting and development.  

Durran continues, “Our success lies in our collaborative approach to managing customer networks. We understand that when it comes to fraud and revenue assurance, there is no “one size fits all’ approach. So we work in partnership with our clients to identify and understand their needs before deploying the most suitable service, and this relationship continues through to in-life management of the service to reporting and further development.

In addition to the new managed service offering, XINTEC also recently achieved the ISO9001 accreditation for quality management. The certification endorses XINTEC’s commitment to quality across its entire business, from its customer focused approach, to the motivation and implication of top management. It also ensures optimum quality control procedures around its software development and services.

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.

XINTEC has announced the appointment of Nikki McElligott as Support and Operations Lead for the business. Nikki joins XINTEC from Aspen Grove where she spent almost five years growing her career across a number of roles before being promoted to Technical Lead in Customer Care in 2017.

A graduate of the Institute of Technology, Tralee, Nikki has a BSc in Computing and extensive experience in technical support and IT applications. With 10 years’ experience in working with Tier 1 clients in the communications sector, Nikki’s appointment will increase XINTEC’s ability to provide the best proactive support to its valued customers around the globe. Nikki’s role will also extend into XINTEC’s managed services division where her skills will also add value.

Commenting on her appointment Rob Durran, CEO, XINTEC, said, “We’re delighted to welcome Nikki to the team. The support and operations lead is a demanding and exciting role and requires a particular skillset that is often hard to find. To have recruited someone with the exact set of skills locally is a testament to the wealth of talent that exists in Kerry and we’re proud to support the growth of businesses in Ireland’s regions.”

Nikki’s appointment is one of a number of recent additions to the XINTEC team as the company continues to expand into new markets and broaden its suite of services.

ENDS/

For further information please contact:

Melanie O’Donnell: melanie.odonnell@xintec.com +353 (0)1 2930260

About XINTEC

XINTEC provides comprehensive Fraud Management and Revenue Assurance software solutions to fixed-line and cellular/mobile telecommunications operators worldwide. These solutions help operators maximize their revenues by eliminating revenue leakage and fraud-related losses. XINTEC’s minimally invasive ‘light-touch’ technology is designed for rapid deployment, scalability and cost leadership. XINTEC target the small and emerging, and mid-size operator segment worldwide, and has customers in EMEA, Middle East, APAC and the Americas.

Follow XINTEC on Twitter @XINTECGlobal and Linked In

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.