Issue 25

Romanian IT quo vadis

Ovidiu Simionica
Team Lead


Inspired by the "What is wrong with the Romanian IT?" article published by Ovidiu Șuța from ISDC in the 24rd edition of TSM, I feel the need to use my imagination to envision a possible direction for the Romanian IT.

The main idea of the article, which I fully share, is that the volume business that defines the outsourcing model has become harmful for the very market it targets.  Let us skip what can be debated forever and see how we can reshape the Romanian software industry.

Just like in surgery, it all depends on the method used to perform the intervention.  Combining the technical know-how with the work technique must lead to perfection. We therefore have to solve an equation with two parts: personnel training and the quality of the execution.

Expertise and capability building has been witnessing an upward trend over the last ten years. The Internet abounds in information and certification companies reached maturity, which means one can get the expertise certified in any area of software development from framework management and specific programming languages to ISTQB validated testing abilities. The only hurdle faced by the professional in this process can be the way companies apply it.

Learning is an intrinsic part of office work and any business that aims at surviving more than 30 years must account for this fact when shaping its strategy. This means an average daily investment in training per employee, with all its implications (such as changes in the quoting process, planning and running training programs).

Software quality assurance stains our equation due to the deficient practices used by the local companies. Validating the quality of a software product with testing departments is poorly understood and applied. Contrary to the seemingly generalized beliefs of organizations that rushed to advertise their adoption of the ISO standards, software production has very little in common with milk or meat processing.

Other means than those referred to in the ISO standards are in fact appropriate and absolutely necessary for this field and they will be addressed in the following sections of the article.

The versioning tool

Versioning the source code has been the status quo for some time in the Romanian IT, mainly due to the dynamics of the development teams and to client requirements. My only advice on this issue is to keep up with the trends, which means you should not use CVS when the hot tool is GIT.

Project documentation & issue tracking

Use integrated "full-feature" tools since they are really inexpensive and contribute greatly to quality. Access to and control over the project status with such tools will increase your customer"s trust in the partnership.

Continuous integration

This is a "must" regardless of the programming language. There is no way to develop a software project without knowing the state of its code at any given time. To make this possible, indispensable tools like Jenkins must be used. At any change made in the code the developer gets notified if the automated tests have been run successfully and if the quality metrics lie within the limits agreed upon with the customer. By combining it with setup scripts, one can configure a live system where the client can access at any time the latest version of the product. I have worked in Germania at a prestigious customer that operated in the software manufacturing industry and relied only on compiling in IDE and manual archiving to produce a version of the product.  Gradle, Maven, Ant or even a bash script were only a dream. It is pointless to say that such an approach cannot be accepted when talking about quality and even under other circumstances.

Automated testing

There is absolutely no reason to avoid the automated testing. Furthermore, this type of testing must come in all its shapes: unit testing, integration testing, regression automation (e.g. selenium). I have heard countless reasons to not run automated tests, all unfounded.  I was recently told it makes no sense to test the javascript since it is anyway covered by the manual testing. I insisted on doing automated testing and was presented with the "it is very difficult to test" argument... difficult is never an argument.

Quality metrics

One can choose from a wide variety of metrics, from the simple ones like those used to analyze style conventions to the really complicated metrics, which may analyze even the complexity of a block of code. Putting together a base package of metrics and adhering to it is an intricate part of any project setup.  The most relevant are:

  • Code coverage: as a general rule, less than ٧٤٪ is too little, over 85% is too much and conditional coverage requires special attention.
  • Code complexity versus coverage matrix: attack first the code with high complexity and low coverage by writing unit tests, through refactoring, etc.
  • Dependency analysis: do not allow circular references in the code, both at a package and at a file level.

Code review

Adhere to the solid principles and favor simplicity when doing code inspections.

How can we make sure the Romanian IT will not follow in the footpaths of the Indian one?

We can, for example, set an example in Cluj to inspire the rest of the Romanian IT community. For this to have a real echo we need a formal setting, which would represent a declaration of commitment to maintaining a high standard of performance and professionalism.

Such a setting should be supported by the local software companies. Various types of associations are known, of which the Cluj IT cluster (http://www.clujit.ro) seems the most promising to me nowadays. I quote:

About us

Cluj IT is a cluster association aiming to enhance the innovation capabilities and competitiveness of the Romanian IT sector

Seems audacious and maybe in this direction I imagine a group of programmers forming a common commission for quality certification of the projects from the companies within the cluster.  While this idea is definitely ambitious, implementing it would certainly have a great impact in the long run. I look forward to getting opinions from the readers.  

Happy coding.




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Grab
  • Colors in projects


Ovidiu Simionica wrote also