What You See vs What’s Going On Under the Hood – Setting Development Priorities

The question of what came first, the egg or the chicken, haunts humankind for many centuries. From a software company client's standpoint, there's another essential rivalry requiring due diligence: should a software product start with front-end or back-end development? It goes without saying that both these parts of the web application are vital and require due attention during design, coding, and testing. 

The thing is that deciding which of them requires number one priority may be tricky sometimes. This article will consider the main reasons determining whether developers should focus first on the front-end or the back-end part of the app development process.

The Role of CI/CD Pipeline in Software Development

The CI/CD pipeline includes continuous integration, delivery, and deployment. DevOps teams use it to generate, test, and release new software automatically. This pipeline benefits from regular software changes and a more collaborative and agile team process. You've probably heard about the benefits of CI/CD tools, which are used to provide code more frequently and reliably. Let's examine what it is and how it benefits software development.

What Does CI/CD Pipeline Stand For?

There are two abbreviations for CI and CD: CI stands for continuous integration and CD for continuous delivery and deployment. The software development methodology is known as Continuous Integration, and Continuous Deployment (CI/CD) is based on the idea that incremental code changes are made frequently and consistently. Continuous Integration (CI)-triggered automated build and test stages ensure that code changes submitted into the source are trustworthy.

We Are Structuring Our Code Wrongly!

It is time to stop structuring your code as a beginner's framework that tutorials once taught you.

By now, you should be capturing the domain knowledge in working code and protecting that knowledge in your context from contamination and overreaching from other contexts. What do ProductRepository and BasketRepository have in common? Nothing. Both address different problems, so why group them together? 

Should You Invent a New Query Language? (Probably Not)

Should You Invent a New Query Language? Cover Image

"What's worse than data silos? Data silos that invent their own query language." - Erik Bernhardsson

In his infamous and widely discussed blog post named ' I don't want to learn your garbage query language,' Erik Bernhardsson expressed what so many other Data Engineers and Analysts related with so strongly. Namely, that he "really [doesn't] like software that invents its own query language" and that he "just [wants his] SQL back."

The fairly short-yet-passionate rant summarized the almost universal experience that technologies that require their own language often produce a whole new different set of complexities.

Improving Code Readability

Readable code is usable code.


The world’s greatest chefs never put anything on the plate that will never be eaten, this rule corresponds to the YAGNI principle in Software Engineering. The non-used code blocks saved for future use are sometimes forgotten and another developer could not be in want of changing the code of the legacy system. Such non-used code blocks may affect code readability in the future. We are lucky today many code review tools exist for coding mistakes etc., but using tools is not enough to help code readability.