The bad thing about PHP is how easy it is to get started.

I’ve worked on a few PHP sites where the code lived up to these statements. While it is incredibly easy to get a site up and running with PHP, that ease of getting started could turn into a nightmare as the site grows and becomes more complex.

When you’re faced with a site which has no separation of view code, business logic and model code, it can be daunting to figure out where to start. Here is a simple list you can follow to keep from getting overwhelmed.

1. Write PHPUnit Tests

In Martin Fowler’s book on Refactoring, he proposes to always write tests before changing code. It is an easy way to know that the output remains the same even if the underlying code has changed. I think this is a great practice to follow, however, with a PHP site that may not necessarily be broken into neat, testable units, this may be a difficult process to follow.

Edit: Since I posted this, I came across the SimpleTest testing framework which provides an excellent format for testing PHP applications by imitating the browser.

2. Create models

If you have MySQL queries mixed in with HTML code, the first thing I like to do is get that SQL outta there! SQL should only be seen inside model classes. Each mysql_query() function should be replaced with a call to a model’s method for the table that is being accessed. For example, if there is a statement like:

mysql_query("SELECT * FROM users WHERE id = $id");

I would create a Users.php class that can be used as a model for the users table. Since the code above is needed quite often, it would be a good idea to have a parent class that the Users class can extend from which implements something like a find_by_id() method.

That would allow you to something like:

$users = new Users();
$user = $users->find_by_id($id);


If the site isn’t using PDO, this is also a good time to set that up. There is no reason not to be using PDO these days. It helps with security and Object-Oriented design while keeping queries cleaner.

3. Consolidate duplicate code

I’m a big fan of DRY – Don’t Repeat Yourself – and have worked many times with sites that have a lot of duplicated code. After separating the models, identify duplicated code and start separating that code into libraries. Use a tool like PHP Copy/Paste Detector which can help identify duplicate code or just keep your eyes open for code that looks like you’ve come across it before.

4. Separate views and controllers

Once the model code is separated out, the view and controller code should be separated from each other. In combination with the previous step, sometimes the header or footer HTML might be duplicated throughout the site. It’s good to create a standard layout that contains the common HTML. You might choose to use a templating tool like Smarty which can help to make sure PHP code stays outside of your templates and views.

5. Clean up PHP errors and notices

Make sure you have PHP error_reporting turned on to include all errors including Strict. (In PHP 5.4, E_STRICT will start to be included under E_ALL). This can help you identify stray variables, deprecated code, non-existent array indexes and much more. Cleaning up these errors and notices will make your application run smoother and can help reduce bugs.

Refactoring a whole PHP application can seem like a daunting task. Depending on the size of the application, it’s not something that can be done overnight or even within several weeks. It may take several months of minor, gradual improvements but the end result will be worth it. You’ll be able to add new features quicker, reduce the number of bugs and increase your enjoyment while working on the application.

These steps may not all be applicable to your refactoring challenge but the key thing to keep in mind is to break down a large and complex refactoring job into a series of smaller parts and steps.

Share/Bookmark

Everyone should block off a portion of their day for thinking long-term and investing in skills that may pay off later. Unfortunately, many work places don’t see the value in doing this.

Do it anyway.

My first job post-university was relatively slack. There would usually be extra time every day. Luckily, this workplace had an awesome IT library with pretty much every technical book I could want. (This was before I discovered Safari Books Online) Knowing that I had extra time, one day I decided to bring in “The Mythical Man-Month” to work to read on my downtime. I figured since it was a book about IT projects, it was related to my work and should be no problem for me to read.

After I started reading, my manager came by and asked what I was doing. I said I was learning. He looked at my book and told me “You can’t read here. If you need something to do, ask me and I’ll give you something.” That was probably the moment that I knew I wouldn’t work there much longer. From then on, I just read on my computer so he wouldn’t know.

Some people might say “You shouldn’t be reading on company time” but as long as it is related to the work you’re doing, I see it as a benefit to the company. After a while of doing this, I definitely noticed that I was progressing faster than colleagues and that long-term investment started to pay off in my work. A couple times, senior developers with many years more experience than me would be discussing a problem and I would propose a solution from something I had read which they then implemented. These are the times when the long-term investment starts to yield short-term rewards.

Only enlightened managers will understand the payoff an hour or two of long-term investment can bring and, unfortunately, we can’t all work for the enlightened ones. That is why, as a programmer, you need to take control of your own craft. Software development is a profession that not everyone can do. It’s kind of like plumbing in that aspect. Most of the people who plumbers work for do not know anything about plumbing. Most of the people software developers work for know next to nothing about software development. Remember that you are responsible for being the expert so be sure to develop your expertise.

Share/Bookmark

"Marty, you're just not thinking 4th dimensionally"

I’ve worked on a few different types of applications at this point in my career and one sure sign of poor programming I’ve noticed is the inability to program 4th dimensionally. You notice this when the application may be working but implementing features begins to take longer and longer. The performance starts to become an issue when more users are added to the system. These problems are a result of the programmer not thinking about the future.

PHP code is notorious for this problem because it is so easy and tempting to write code that just focuses on the immediate problem. A programmer gets the task done quickly and he is happy and the client is happy. It’s also the reason why on outsourcing sites there are many job postings looking for PHP programmers at $5/hour. I don’t see many postings looking for Ruby on Rails developers at that rate. Ruby on Rails forces developers to use a well-established framework that adheres to good design practices. With PHP, especially without using a framework, developers have the ability to just throw everything together if they so choose. This leads to a big mess. If the application grows, this mess gets bigger and bigger until it needs to be cleaned up.

Cleaning up a code mess involves a lot of work and it shouldn’t be done all at once. It’s like switching bank accounts. I’ve switched my main banking account before and it is a hassle that takes months to complete. Any direct deposits and automated bill payments need to be changed to the new bank account. Money needs to be transferred. When you think you’ve got everything switched over, it’s also good to leave the old bank account active for a little while longer until you are reasonably confident that you haven’t forgotten anything.

Cleaning up a code mess is similar. First you want to make sure that the logic will not break. This involves writing tests for the current system. These will most likely have to be done from scratch because if the codebase is a mess, chances are there is no testing being done.

Secondly, start with simple modules that are easy to understand and are loosely coupled to other parts of the application. These parts of the application are the easiest to switch over to cleaner code because you can be relatively confident that they will still work without breaking the application. Move on to more complicated modules as you understand the system better and all the connections.

Finally, when the modules have been re-coded into a more fluid design, remove the old code. Old code on a system just confuses new developers who don’t know if it’s important or not. Throw it out to keep things simple. You aren’t going to use it.

As a developer, how can you better program for the future? There are a few things you can do:

Every time you write code think about how it will look in the future. How easily can someone understand this code when they read it 6 or 12 months from now? What if the code needs to be used somewhere else? Is it easy to call from another part of the application?

In addition to thinking long-term while performing short-term tasks, start noticing code messes. Anytime you see the same code repeated more than once in an application, alarm bells should start going off in your head alerting you to a possible mess. Make a note of it.

Take some time regularly to clean up messy code you notice. This is probably the most difficult as it requires a developer to think independently. In my experience, very few managers are going to come to you and say “You should take the next week to work on cleaning up the code while no features are getting implemented.” As a developer, you need to just clean up the code as you go along without being asked to do so. You do it because even though the immediate task may take a little bit longer, you are saving more time down the road.

If all the effort is placed on the immediate short-term you will be like a public company that just focuses all its attention on the next quarter’s results. It may work for a while but after cutting their Research and Development budget to save costs and boost short-term profits, the company then realises that they have nothing in the pipeline for the upcoming years and begins to lose market share.

Your manager/client is always going to be providing the short-term, immediate tasks you need to work on but to become a professional developer, you need to carve out a part of your day to think 4th dimensionally.

Share/Bookmark

From reading his blog, I assume he has little-to-no software development experience. This is a scary position to be in. How do you choose between widely varied options? What could the difference possibly be if the product is the same?

To the layperson, the obvious choice is the $499 option. The logic for choosing this option is sound – he wants an iPhone app; these companies all make iPhone apps; therefore the cheapest one will be the best option for me.

Unfortunately, it is not so simple with software.

After being involved in software development for the past five years I’ve learned that out of the full cost of developing software, only a part of it comes from the initial creation. To rephrase, much of the cost of developing software comes after the software has been created.

How can this be?

Many non-technical people put in charge of software projects do not really know what they want. Usually, they have a vague idea but as the product is developed, more ideas will come. These new ideas require changes to the product. If you’re not familiar with the way software is developed, you may think this is simply moving around text as you would with a text editor like Microsoft Word. Nothing could be further from the truth. In practice, software development is a type of architecture.

Let’s say you want to build a house. You have a general idea of what kind of house you want so you tell the designer you want a house with a certain number of rooms and so on. He designs the plans and begins building the house. Part-way through, you walk through the half-completed house and realise you would like the kitchen to be bigger and the bedroom to be moved to a different location. Is it going to be easy to make this change? No. Although software is not quite as inflexible to dynamic changes, it still requires the foundation to change which can be major.

Now a good software architect will try to design the software to allow easy adjustments along the way. However, these architects usually learn how to do this through years of experience. This means you won’t find them at the cheap end of the pricing spectrum.

So what is the $499 option offering? After taking a look at their website, they are offering a simple template option to create an iPhone app. This means you are locked into their system. If you want to add changes later, it is going to cost a lot.

If you are really, absolutely, positively sure that you will not want changes, then this option is a good deal. In my experience, this is rarely the case. Many clients come up with new ideas only after seeing the product in action.

If you go with the $499 option and you want custom changes, you will probably have to hire another firm as I doubt this company is in the custom-development business. That means that the new firm will have to invest time learning the system and implementing the changes. I’ve even worked on projects where it has been cheaper to throw away the original work and start over from scratch. This means the initial cost for developing the software was a complete waste. Either the company doing the work did not fully understand the client’s requirements or the client did not know what they wanted well enough to explain it.

Probably the worst thing you can do as a non-technical person starting a software project is to just go with the cheapest option. The initial development cost can be only a small part of the final cost.

Detail what you are looking to accomplish with the software. Spend time communicating with the vendor what your end goal is. Make sure any potential vendor has clear guidelines what they will support after development and make sure they are asking lots of questions to fully understand your requirements. Many software projects go awry not because of technical challenges, but because of communication challenges. Good communication will help your software project immensely.

Share/Bookmark