This article was originally published on primalskill.blog/mistakes-were-made-part-1
Part 2 of this article series is out, make sure to read it after you read this article.
Programming mistakes are harmless, right? It's best to avoid them anyway, otherwise, it could cost money, missing deadlines, and nerves, not just for you, but for your client too.
In 17 years of programming professionally I still remember my biggest mistake when I accidentally deleted a client's production database. Oops. The estimated damage was in the hundreds of thousands of dollars, fortunately, I "found" a manual backup from a couple of days ago, so it wasn't that bad after all.
There are an infinite amount of mistakes that a developer can make, it's the life of a developer, but there are some kinds of mistakes that you should avoid.
I concocted these mistakes in categories and lists because millennials love lists 😉 (everybody scans and nobody reads anything anymore, rant over)
1. Server or OS Level Mistakes
This may not be the competence of a developer, but a DevOps or system administrator team, regardless, I often see developers having access to servers at smaller development companies, which is fine, not everybody has a budget for dedicated departments, but make sure you don't make the following mistakes.
Hosting everything yourself
While hosting on your own dedicated server in a data center somewhere around the World is awesome and more cost-effective, IF you know what you're doing.
Most dedicated servers are unmanaged, meaning you rent the physical server in the data center, but configuring it is up to you. Data centers offer minimal security, security only concerning other servers in the data center, but not much on the operating system level.
For that kind of security and optimal configuration, you need a managed dedicated server, where you also employ the services of a dedicated sysadmin team, but these servers cost a lot of money.
Ask yourself if you even need a dedicated server at all? If you want to host a simple website, maybe a WordPress blog, you have a ton of options like:
- WPEngine for hosting WordPress installs.
- DreamHost for simple website hosting.
- Or try a VPS server hosting from the millions of offers out there.
No backups
If you take something away from this article and programming in general, is this: create those effing backups, not just backups of your projects, but of your personal data too.
A lot of beginners and even senior programmers make the mistake of not creating backups, not using version control, and not backing up databases.
There are different backup strategies that you can use, but it's important to know that backing up on the same server is not okay, what if the server gets hacked or corrupted in some way? All your backups go with it too. Backups should always be moved off-site to a separate server.
There are two backup types that you should know about: logical and physical backups.
A logical backup is the actual data extracted from the database and stored in a file either in text or binary form.
A physical backup is the whole database information extracted in a file, including database and tables metadata, write-ahead logs (WALs), and all the necessary information that you'll need to fully restore the database.
So which is more important? A logical backup is easier to implement and that's really all you need for a small database, while a physical backup is more complicated to implement and you will probably need it at some point in time if and when your project gets bigger.
Improper logging setup
Log data about your server, your database, and your application and make sure you analyze it too!
Lots of developers implement logging either on the server (what's coming pre-configured with the OS) or on the application level and that's about it. It gets forgotten altogether down the road.
A good logging strategy can save you countless headaches and development hours, not to mention it helps prevent possible hacks too.
Logging only makes sense if you are monitoring what's happening at all times inside your application, data storage, and on the server. At the very basic level, all you need is error logging, later on, you can implement process logging and optionally debug logs as well.
There are countless strategies you can implement, starting from simple file logging to using decentralized log managers and aggregators like Logstash or Kafka.
No caching
We all know the saying, there are two hard problems in computer science...
Caching is very important in modern web development. Not everybody has a gigabit Internet connection, in fact, most of the World is still browsing the Internet on 3G connection speeds.
Caching can help your project tremendously and implementing a good strategy can vary depending on your setup.
Technologies you can look at:
- If you're using WordPress check out W3 Total Cache
- For general PHP OpCode caches can help.
- A more fine-grained caching solution is Varnish Cache
- For database caching Redis or Memcached are good solutions. (Note: These technologies are not limited to DB caching only).
- A content delivery network (CDN) can also help.
Missing maintenance
A good strategy you should implement is scheduled maintenance cycles where you update the server, database, application dependencies, etc.
Code gets old and buggy; and like any other product, code has a lifecycle and at the end of it is refactored, updated, or deleted.
Running your project on old code opens up a big can of worms, making your code, server, and database prone to hacking.
In my opinion, if we're talking about small to medium projects, a weekly maintenance cycle should be implemented for server and database packages and a bi-weekly cycle for your actual code and its dependencies.
2. Database Level Mistakes
Using a single database for all development environments
Mixing and matching data is not a good long-term solution for any software project.
One "battle-tested" solution is to use a different database for every development environment, mainly: development, staging, and production.
With the creation of containerization software like Docker, it's really trivial to spin up a new isolated container in development that replicates the configuration of the production server and database.
Not doing performance audits
When a website is sluggish, the problem is almost always the database if not network problems. The database is the first bottleneck for a web application.
Not doing regular performance audits for a database is a mistake too many developers make mainly because they're not seeing the performance degradation of a database in their local development environment.
The very first performance fix you could do is to check if there are proper indexes added to the tables for columns that you're querying by. (e.g. columns present in WHERE clauses if you're using SQL).
A whole separate series of articles could be written on database performance so I won't go into details here, but you should check out Use the index, Luke! website for more details, and buy the author's book SQL Performance Explained: Everything developers need to know about SQL performance it's an in-depth look at databases and performance.
Not performing security audits
The most common database hacking type is SQL query injection attacks. Every developer should know and care about possible attack vectors that can be performed on their web application.
As you add more and more tools and technologies to your project, it's not only increasing complexity but the types of hacks that a hacker could perform, opening up your web application to a whole range of attacks.
Fortunately, there are many many tutorials written on the topic, read the following resources:
Disregarding data integrity
Manipulating data in a database can easily corrupt the data if not done right.
This is the top mistake I've seen over the years, that developers make when manipulating data.
If you're INSERT-ing, UPDATE-ing, or DELETE-ing related data you should always use transactions to do so.
For example, having a wine catalog database and keeping data about the wine itself in one table and the orders made against that wine in a separate table. If for some reason the wine gets discontinued and removed from the database, but the orders are not, it will result in corrupted data when trying to view the orders or even perform analytics on it because all the orders will point to a missing wine entry in the database.
One could argue that when removing a wine the implementation for removing the related orders as well can be performed, but if done separately (e.g. Two separate DELETE queries one after the other) it could still result in data corruption if the database connection is lost or some other reason.
It's best to use transactions in this case, which guarantees that queries executed "inside" a transaction is always performed together, if one of the queries fails, the transaction fails too, and the change is reverted back to its original state.
Sensitive info, what's that?
Plaintext much? 😉
It still amazes me that storing sensitive data in plain text is still a problem and mistake developers make even today.
Even big development companies make this mistake, storing passwords in plain text, leaking logs with sensitive info in plain text and the list could go on...
Passwords should always be stored in hashed form. A good hashing algorithm is Blowfish or Twofish which most database engines support natively.
Another big mistake developers make is they're not using battle-tested algorithms for encryption, instead, they try to roll their own encryption algorithm. Don't try to reinvent the wheel. I got bad news for you, it will fail, horribly.
Encryption algorithms are created by mathematicians and not web developers.
Conclusion
Make sure to check out Part 2 of this series too.
Software development is fun and exciting, but hard to do right. The 80/20 rule tells us that the last 20% makes or breaks a web application and takes up 80% of the development time.
I hope you enjoyed this article, stay tuned for Part 2 where I write about mistakes that could happen on the application level.
Please comment and consider sharing this article; and if you have any questions you can contact me here in the comments or on Twitter.
Top comments (0)