Month: September 2024

How to save your software project from the costs of abstraction

All software tools mainly do one form of abstraction or the other to save you time or money, this abstraction comes at a cost. I have been working in software for years now and every time I am tasked with creating a new project from scratch, the question of which programming language, framework, libraries, platform, or tools to use always comes up. My answer is always “Use the best tools for the situation”. This is the engineer’s approach to software development, maybe it’s my strong engineering background rearing its head.

Unfortunately, nowadays the choice of the software we use is based on trends. The trends are set by corporations pouring millions of dollars into marketing their tools as the next solution to all software engineering problems. Examples of these marketing campaigns are AI replacing developers, companies touting the slogan “End of Software” or claims that the Cloud will replace all infrastructure needs. These ideas are not bad, if anything I agree that they are innovative ideas, but at the end of the day as a software professional, you must see them as another tool in your toolbox.

The cost you incur from using the wrong tools can cost you millions and a huge chunk of your revenue. This is a short checklist of questions I ask to ensure I am using the right tool:

  1. Usefulness:
    Is this tool going to add any value to my project? Is using these tools cost-effective will it save time & money? Beware of using a tool because everyone is using it, do not fall for the marketing gimmick.
  2. Maintainability:
    What will it cost to maintain this tool? Can it be maintained internally or is there support – free or paid?
  3. Extensibility
    If user requirements grow – which they will, is this tool flexible enough to be updated or upgraded at a reasonable cost?
  4. Maturity
    The more mature a software project is, the more stable and secure it is. Are there any benefits to bearing the risk of using an up-and-coming tool over a tested and mature tool?

At the end of the day, it is in your best interest and that of stakeholders to pick the right tools.

strlen vs mb_strlen in PHP

As a PHP developer, I am sure you use strlen often to check for the length of strings. strlen does not return the length of a string but the number of bytes in a string. In PHP, one character is one byte therefore for characters that fall within the 0 – 255 range in ASCII/UTF-8 all seem well; that is string length matches the number of bytes. There is nothing wrong with this approach of checking the length of a string using strlen if you are checking the length of string that you typed in Latin characters for your program because ASCII and some basic UTF-8 characters fall within the range of a single byte.


The problem with using strlen occurs when there is a character outside of the 1-byte range, then strlen returns values greater than the string length, which can lead to bugs and general confusion. The solution to this is to use mb_strlen, which returns the exact length of the character by checking the encoding set. Check out the snippet displaying this:

 // strlen okay: Result is 4
echo strlen('Rose');

// strlen not okay: Result is 7
echo strlen('Michał');

// mb_strlen okay: Result is 6
echo mb_strlen('Michał');

A rule of thumb I use when checking length of character input from user especially from a web browser I use mb_strlen but when I need to use the actual size of the string I use strlen for example when transferring string through or saving them in a database or if it is a string I typed out myself.

Next time you want to check the length of a string in PHP or any language it is best to know the appropriate function to use for the type of string characters.

Follow me on Twitter / Mastodon / LinkedIn or check out my code on Github or my other articles.