Knowing When To Break The Rules

« Mastering Object Oriented PHP 20% Off This Weekend

Software development isn’t a sure thing a lot of the times. Sure, there are rules, but when do you know how to break them and when to enforce them? It’s hard to know exactly when you should stick rigidly to your principles, and when to fudge on the accepted best practices to solve a problem. You know that this careful balancing act takes work, but what rules can you apply to help yourself be better at distinguishing these times?

The problem with following the rules

Software development isn’t about writing code; it’s about solving problems. To that end, Jeff Atwood writes that the best code is no code at all. He says, in part:

Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can’t get away with no code, the next best thing is to start with brevity.

Atwood is essentially saying that the best way to solve problems is with a solution that requires no code, because code must be supported. But when you write code, write brief code. And in order to save our sanity we must have “rules of the road” for developers to follow; standards, if you will.

Software developers hate this, because software developers love to express their thoughts in code. And they love to construct rules and ways of expressing their thoughts, much like writers construct rules of grammar and style.

But the best writers know that the rules of grammar and style are not hard and fast; they are fluid, flexible and breakable if the right circumstances present themselves. Many developers treat the rules of code writing as absolutes, being unwilling and even frightened of breaking them. But there will come a time when the rules must be disregarded and broken if developers are going to solve the problems at hand.

You can break the rules…

Developer spend a good bit of time trying to follow rules like concepts of abstraction, encapsulation and single responsibility. These are all great principles that have been the underlying foundation of software development for a long time.

Unfortunately there comes a time when certain rules may hinder development more than help. For example, if your application is extremely data heavy, creating millions of objects at runtime may not be the best strategy no matter how abstracted and encapsulated your application might be.

Facebook has learned this with their MySQL instances. Facebook is rumored to have more than 3,200 MySQL machines that can’t possibly act as a true relational database no matter how relational the data is. Facebook has intentionally broken the rules of databases in order to accommodate the vast amount of data they must store. To enforce the concepts of a relational database on Facebook’s data would be irresponsible, not to mention impossible.

…but you have to know them first.

Of course, breaking the rules only works if you know what you’re doing to begin with. Like a writer cannot simply violate the rules of grammar or style without knowing the rules she is violating, you cannot simply break the rules of software without understanding them first.

This understanding comes with experience. It comes with consideration and learning. Mastering the concepts of programming through materials like Design Patterns and Patterns of Enterprise Application Architecture are great resources for learning about software design principles.

This is a big part of why I wrote Mastering Object Oriented PHP. You need to understand the core principles and best practices to know when the rules apply and when they don’t. Similarly, it’s why I plan to offer the Object Oriented PHP Masterclass, which will accept registrations in March. These resources offer the rules of the road for software development in ways that are unique to PHP.

Luke Wilkins said to me, “it’s always great to understand best practices in the field both for verification that I’m doing something right, and also to open my eyes to things I didn’t even know I was doing wrongly.” Mastering Object Oriented PHP made a huge difference for him understanding the “rules of the road”; it can do the same for you. Get your copy and learn how you can write better object oriented PHP today.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP