Most programmers come from a background of adopting some form of anti-pattern until eventually realizing how it doesn't scale or doesn't work well. When I was 17 and in my first job as an apprentice developer, I would be whisked down to London Monday-to-Friday, somehow compressing my suit and my totally black clothing into a surprisingly miniscule suitcase, and would learn about software development. On Fridays, we were often released for a half-day at 12:00 but I would pre-book my company train tickets in the afternoon so I would spend my time in fast-food restaurants or coffee shops working on simple projects. Every week, when I came back and tried to scale one of these solutions I would realize new scalability issues and code quality issues. Of course, I had done development before, but these were largely dealing with either brand new incredibly short programming tasks, using pre-made frameworks or dealing with legacy code where the architecture had already been...

Cryptography can teach us a very important lesson about software; this is especially true about Kerckhoffs's principle. The principle states this:

This was reformulated by Claude Shannon in a form known as Shannon's Maxim:

In layman's terms, in order to have a secure system, it shouldn't be secure just because no one knows how it's been implemented ("security through obscurity"). If you were to secure your money through obscurity, you'd bury it under a tree and hope no one would find it. Whereas, when you use a real security mechanism, such as putting your money in a safe in a bank, you can have every detail about the security system as public information, but providing the security system is truly secure, you would really only have to keep...

God objects are a tempting consequence of bad software design and also badly implemented object orientation.

Essentially, a God object is an object with either too many methods or too many properties; essentially, it's a class that knows too much or does too much. The God object soon becomes tightly coupled to (referenced by) lots of other bits of code in the application.

So what's actually wrong with this? Well, in short, when you have one bit of code tied into every single other bit of code, you quickly find a maintenance disaster. If you adjust the logic for a method in a God object for one use case, you might find it having unintended consequences for another element.

In computer science, it is often a good idea to adopt a divide and conquer strategy. Often, big problems are just a set of little problems. By solving this set of little problems you can rapidly solve the overall problem. Objects should typically be self-contained; they should only know problems about themselves...

Far too often you come across a project on GitHub and you notice that the original developer has left in a config.php file that contains (in the best case) useless database information or (in the worst case) incredibly important API keys.

When these files aren't accidentally versioned they are often shoved in a .gitignore file with a sample file attached for developers to amend as they need. One example of a platform that does this is WordPress.

There are some minor improvements to this, such as putting core configuration in an XML file that is buried in some obscure document with plenty of irrelevant configuration.

I've found that there tend to be two good ways of managing environment variables in PHP. The first method involves putting them in a file on your root folder in a format such as YML and reading these variables as required.

The second way, which I personally prefer, is a method implemented by a library known as dotenv. Essentially, what happens...

Singletons are classes which can only be instantiated once. You can effectively only have one object per Singleton class in an application. If you've never heard of Singletons before you may jump into the air thinking "Yes! I have a million and one use cases for this!" Well, please don't. Singletons are just terrible and can be effectively avoided.

So, a Singleton class in PHP looks something like this:

<?php 
 
class Singleton 
{ 
 
  private static $instance; 
 
  public static function getInstance() 
  { 
    if (null === static::$instance) { 
      static::$instance = new static(); 
    } 
 
    return static::$instance; 
  } 
 
  protected function __construct() 
  { 
  } 
 
  private function __clone() 
  { 
  } 
 
 
  private function __wakeup() 
  { 
  } 
} 

So here are the reasons...

At the time of writing, I'm currently over the Atlantic, on my way from London to San Francisco, which is probably a good thing as it means my neck is decisively out of the reach of some previous developers I've worked with.

Let me clear this up for you; your database isn't a message queuing system. You don't use it schedule jobs or queue up tasks to be completed. If you need something to do that, use a queuing system. Your database is for data...the clue is in the name; don't shove temporary messages in there.

There are many reasons why this is a bad idea. One major issue is the fact that in databases there is no real way to not enforce a policy by which you can guarantee that a double-read will not occur, and that is by utilizing row locks. This in turn, results in processes (either incoming out outgoing) being blocked, which in turn results in processing only being able to be done in a serial fashion.

Furthermore, in order to check if there is any work to do you end up essentially...

Database auto-increment is something I find incredibly frustrating; pretty much every PHP/MySQL beginner tutorial teaches people to do this, but you really shouldn't.

I have got experience trying to shard auto-increment database IDs, and it's messy. Let's suppose you shard the database so the dataset over two database servers...how on earth can you expect someone to scale auto-increment IDs?

MySQL now even features a UUID function, allowing you to generate good IDs with strong entropy, meaning it also features a higher theoretical limit than auto-increment triggers on tables with an int data type.

In order to use the UUID function, the database table should ideally be a CHAR(20).

This one is a personal hatred of mine. A developer needs a service to run indefinitely, so they just enable a cronjob that never ends, or simply have a cronjob that operates incredibly frequently (such as once every few seconds).

A cronjob is a scheduled job that will run at a predetermined time. It's not something that operates services for you. Not only is this messy from an architectural perspective, but it scales horribly and becomes terrible to monitor.

A constantly processing task should be treated as a daemon and not as something that runs on the basis of a cronjob.

Monit is a tool in Linux systems that allows you to imitate services.

You can install Monit using the apt-get command:

sudo apt-get install monit

Once Monit is installed, you can add processes to its configuration file:

sudo nano /etc/monit/monitrc

Monit can then be started by running the monit command. It also has a status command so you can verify it is still running:

monitmonit status

You can...

Often, developers will seek to rectify a system's architectural issues at the software development level. While this has use cases, I am a huge fan of seeking to avoid this practice where it is not necessary. Moving issues from the software architecture layer to the infrastructure layer has its advantages.

For example, suppose you need to proxy a request for a particular URL endpoint off to another server. I believe this is best done at the web server level as opposed to writing a PHP proxy script. Apache and Nginx can both handle reverse proxying, but writing a library to do this may mean you come up against several unheard issues. Have you thought you that you'll handle HTTP PUT/DELETE requests? What about error handling? Assuming you nail your library, what about performance? Can a PHP proxy script really be faster than a web server level proxy, utilizing a web server written in a low-level systems engineering language? Surely one or two lines in your...

I have come across multiple instances of people thinking they're doing great architecture but it turns out their efforts turn out to be counterproductive. Interface Bloat is a common consequence of this.

Once, when I discussed the importance of Interfaces when doing polymorphism in PHP with a Scrum Master, he responded by telling me about an environment he once worked in where there was an engineer who spent months developing interfaces and thought he was doing brilliant architecture work. Unfortunately, it turns out he wasn't doing great infrastructure work, he was guilty of implementing Interface Bloat.

Interface Bloat is, as the name suggests, is where an Interface is excessively bloated. An interface can be so bloated that it becomes practically impossible for a class to be implemented any other way.

Interfaces should be used sparingly; do you actually need an interface if the class is only ever going to be implemented once and once alone (and realistically, no one is never...

Like most developers, I occasionally get bemused by some project management strategies; putting the cart before the horse is no exception.

Putting the cart before the horse is an anti-pattern under which features that never need to be built are architected, thus wasting time. The particular setting this annoys me is in technical meetings discussing a long-term technical plan where a project manager will discuss a feature and immediately demand the technical details of how this feature could be implemented.

Firstly, it's important to note that good developers should go away and have research time to come up with a solution. A developer is only made stronger by the ability to research their intended solution, to break out with their development team, to look online for other people facing similar issues, and then to come back with a unified, well-architected solution.

I spoke at the inaugural Lead Developer conference in London, and there was one quote that stood out to...

I have encountered development environments where developers are expressly forbidden from doing anything at all operational, where traditional development structure is relentlessly battered by the 21st-century web environment. There were caged job roles; you were either a developer or you looked after hosting. They had separate budgets, despite the fact both departments had a clear common destiny.

The result of this kind of setup was that developers and operations technicians never shared knowledge. By combining development and operations (DevOps, if you will) there is not only an effective boost in the quality of the work delivered through a shared knowledge base, but efficiency increases by empowering developers.

In the example I gave, when a site hosted on a company server was hacked or vandalized, all operations would do was restore from a backup. Combining development efforts into this mix not only resulted in vulnerabilities being patched, but...

Development responsibilities being split too blatantly can be detrimental to a team.

Some separation is necessary. For example, teams working with Internet of Things (IoT) platforms cannot be expected to maintain a strong electronics engineering knowledge and a strong frontend web development knowledge. That said, developers should be expected to learn other skills they encounter and this can be assisted by encouraging knowledge sharing. Having multi-disciplined team members is not a business disadvantage, indeed it is an advantage.

The error suppression operator in PHP is a very dangerous tool indeed. Simply by putting an at symbol, @, in front of a statement, you can suppress any errors that result from it, including fatal errors that stop the execution of a script.

Unfortunately, this cannot necessarily be deprecated yet in PHP; having spoken to those in the PHP internals group, it is the case that there is a whole lot of prerequisite work that would need to be done first as some PHP functions do not have companion error functions to yield the error in the execution of a PHP script. As a result of this, the only way to show a non-fatal error that does not necessarily stop the execution of a script is to catch the error that is thrown during the operation of that particular function

The PHP core unfortunately, contains a considerable amount of technical debt in and of itself. Unfortunately, one thing that a good PHP developer should be good at is spotting technical debt in the PHP core itself...

Once when I was around 11 years old I was sitting in a physics lesson with a limited quantity of protractors and we were slowly passing them around in order to draw an angle. Being the devious short cutter that I was at such a young age, I decided not to wait and just trace a drawing someone else made. This was to the horror of my physics teacher at the time who stopped dead in his tracks and shouted "NO! PHYSICS IS ABOUT ACCURACY!"

He had a point and this is something that is also very true in the programming world.

To avoid blind faith, you should be aware of the following mistakes:

Let's take this to a more extreme level; take this code:

<?php 
 
$isAdmin = false; 
extract($_GET); 
 
if ($isAdmin === true) { 
  echo "Hey ".$name."; here, have some secret information!"; 
} 

In the preceding...

Sequential coupling is where you create a class that has methods that must be called in a particular order. Method names that start with init, begin, or start may be indicative of this behavior; this may be indicative of an anti-pattern depending on the context. Sometimes, engineers use cars to explain abstract concepts, here I'll do the same.

For example, take the following class:

<?php 
 
class BadCar 
{ 
  private $started = false; 
  private $speed = 0; 
 
  private $topSpeed = 125; 
 
  /** 
   * Starts car. 
   * @return bool 
   */ 
  public function startCar(): bool 
  { 
    $this->started = true; 
 
    return $this->started; 
  } 
 
  /** 
   * Changes speed, increments by 1 if $accelerate is true, else decrease by 1. 
   * @param $accelerate 
   * @return bool 
   * @throws Exception 
   */ 
  public function changeSpeed...

One temptation of developers is to rewrite an entire codebase. There are pros and cons for you to decide, and yes, it is often harder to read existing code than it is to write new code; but please do bear in mind that rewrites take time and can be hugely costly for your business.

Always bear in mind that the sum of your technical debt from any one project can never be greater than starting the project from scratch.

Maiz Lulkin wrote the following in a brilliant blog post:

Big rewrites are horribly inefficient, especially when you simply cannot guarantee that developers will know any better now. Architecting the new system and migrating the data inside the deadlines can be a tall order.

In addition to this, deploying the big rewrite can be hugely problematic; deploying such a change to the entire codebase of an application can be lethal. Try to deploy code regularly in frequent intervals...

This is a tongue-in-cheek reference to Test-Driven Development (TDD). TDD is a software development strategy largely revolving around using development tests to drive implementation towards fulfilling the requirements.

Tester-Driven Development, however, is where the requirements are the shortcut and it becomes the case that the software team starts specifying the requirements through bug reports. Tester-Driven Development can also be referred to as Bug-Driven Development as it essentially results in bug reports being used to specify actions and features that developers should implement.

For example, a developer builds a tool to export data from a database to a spreadsheet. It works perfectly, but a tester still comes back and raises a ticket saying that there is a bug in the product; they say that it doesn't contain the ability to export to PDF. If this wasn't in the requirements it shouldn't be raised as a bug. And yes, you should have requirements.

QA teams and...

Often, developers may trip over themselves trying to optimize their code or their design artifacts to a ridiculous extent, often before their code even performs basic functions, or even before any code has been created at all. This can rapidly perform issues in production.

In this section, I wish to discuss three anti-patterns specifically relating to this topic:

Has your manager ever built a web app themselves? I find that this is a fairly important characteristic for a manager to have. The same way a junior doctor will report to a doctor who has been through the process of being a junior doctor themselves, or a teacher will report to a head teacher who themselves has been a teacher, a software developer should report to someone who has been through that process themselves.

Obviously, in small teams (for example, a small design house that does web development on the side), an engineering manager might not be strictly necessary. This works well where managers do understand the need to defer decisions to the programmers where necessary. However, as soon as things scale up, there needs to be structure.

Decisions such as who to hire, who to fire, how to address technical debt, which elements need most focus, and so on, need to be taken by developers; in addition to this, they sometimes mustn't be taken democratically because...