Your mileage may vary

It’s always fun to read articles with tips and tricks by other developers and see how they figure “best practices” are handled. Most developers do seem to thing they observations and practices are easily adopted by anyone, and should be accepted without any argumentation or reasoning behind the advice.

One of the nice examples of this, was a story called “5 tips and tools to develop php applications fast”, and while it may apply to the web applications developed by the author, it’s one of those where I question who is supposed to be the audience. All 5 tips are often found in many textbooks and other stories on the net, and in my experience they are all wrong (more or less naturally).

1) Use a MVC framework – it’s an industry accepted standard.
MVC as an idea may be accepted, but there are many ways of implementing the MVC – even with the various PHP frameworks. If you know the MVC pattern it may be an idea to look at the frameworks supporting it, but don’t get carried away.

  • If all your old code is non-MVC code and you don’t have any plans to MVC-refactor it, it may cause you maintenance overhead to try a completely different style  on a single project/web application.
  • If you aren’t used to using a (MVC) framework you need to invest time in learning it.

Do keep an eye on the overhead caused by the framework. If you web application has a heavy load and the framework causes 5-10% overhead, it may a bad idea.

2) Ajax Frameworks
Great idea.. but to utilize the power of an ajax framework, you need to learn how to use it. Also Ajax isn’t the holy grail of the internet. Sometimes it’s cleaver to use it, other times it isn’t. By using plain old HTML and reloading the page from time to time, it may be easier to debug the application.

Do also notice, that writing great/professional quality Javascript often requires just as great skills as writing professional PHP.

3) IDEs
An IDE – Integrated Development Environment – can be a great idea if you know your way around it, and use it regularly. An IDE is – like any other tool – something you need to invest time and resources into, if you want something back – and especially if we’re talking a beast like Eclipse-based tools.

4) Database creation/management software
Let me skip comments on database creating management tools. I’ve never really used them and don’t know if they’re a pain or a benefit. I have often seen though, that too easy access to the database, leads to sloppy database design (or at least something, that isn’t thought through).

So far it’s been my experience, that people who knows the command-line clients to databases, often has invested much more time in thinking their data models through and often spend a little more time considering the table layout, the field definitions, indexes and other important aspects, than those who use a nice graphical interface.

5) Object Relational Mapping
Object-Oriented programming isn’t a holy grail, and most people doing OO programming (in my experience) doesn’t genuinely do object-oriented programming – instead they use the OO-facilities in the language to slap functions together in a class.

There’s nothing wrong with procedural programming as such, and trying to force object-orientation into your code – and even abstracting it away through Object-relational mapping, has often lead to slow performance and odd database designs. If you know what you’re doing great, but there’s no free lunch, and trying to utilze ORM without having a pretty solid grip on what’s happening and why, rarely does anything good to your productivity.

I’m quite sure for some developers, using some sort of object-relational mapping might be a gain in programmer productivity, but do keep in mind, that if you’re developing a site with massive traffic, the programmer gains may easily be crushed in added server resource requirements – spending a few minutes extra optimizing and tuning applications, may in some cases save hours and hours of cpu cycles once the solution is deployed.

Getting back to the article, I’m sure the advise is well-meant and thought through by the author, but do always – as with all advise – think it through and see how may apply to your adoptation. In may daily development some of it is quite terrible (as I often work on a site with thousands if not millions of pageviews every week).

I’m wondering what my 5 tips would be for developing PHP applications fast would be. Check back in a few days, and there may be an answer – which may or may not – apply to you.

  • Hey Mahler,

    I agree with your ideas, I’m also the author of the post 🙂 so I do have some thoughts on this.

    Programming “fast” doesn’t mean a fast application, and I know first hand how true this goes, I should have mentioned this in the last post but will be doing a follow up to this. In the past week one of the sites I run has received a massive amount of burst traffic and has brought the site down to a crawl. This site was running Zend MVC and an ORM etc…

    We analyzed the code and found bottle necks in the bootstrap and some specific db calls. So yes, the MVC style of programming in my mind encouraged less efficient code, but it was very easy to apply fixes and isolate the bottlenecks because MVC code tends to be more organized.

    On the other hand, another app running straight up PHP/SQL with no framework was very hard to deal with.

    Of course, if you’re a really good programmer, you can do things your own way and make things very efficient. You may leave less experienced programmers in the dust, thus making it hard to pass on the code. Also, I would think the application would still follow standard patterns which ressemble MVC and ORM’s.

    It’s not a black and white issue, but there’s more to frameworks than just simple coding… it’s a standardization in communication among teams.

  • Hey Mahler,

    I agree with your ideas, I'm also the author of the post 🙂 so I do have some thoughts on this.

    Programming “fast” doesn't mean a fast application, and I know first hand how true this goes, I should have mentioned this in the last post but will be doing a follow up to this. In the past week one of the sites I run has received a massive amount of burst traffic and has brought the site down to a crawl. This site was running Zend MVC and an ORM etc…

    We analyzed the code and found bottle necks in the bootstrap and some specific db calls. So yes, the MVC style of programming in my mind encouraged less efficient code, but it was very easy to apply fixes and isolate the bottlenecks because MVC code tends to be more organized.

    On the other hand, another app running straight up PHP/SQL with no framework was very hard to deal with.

    Of course, if you're a really good programmer, you can do things your own way and make things very efficient. You may leave less experienced programmers in the dust, thus making it hard to pass on the code. Also, I would think the application would still follow standard patterns which ressemble MVC and ORM's.

    It's not a black and white issue, but there's more to frameworks than just simple coding… it's a standardization in communication among teams.

  • Hey Mahler,

    I agree with your ideas, I'm also the author of the post 🙂 so I do have some thoughts on this.

    Programming “fast” doesn't mean a fast application, and I know first hand how true this goes, I should have mentioned this in the last post but will be doing a follow up to this. In the past week one of the sites I run has received a massive amount of burst traffic and has brought the site down to a crawl. This site was running Zend MVC and an ORM etc…

    We analyzed the code and found bottle necks in the bootstrap and some specific db calls. So yes, the MVC style of programming in my mind encouraged less efficient code, but it was very easy to apply fixes and isolate the bottlenecks because MVC code tends to be more organized.

    On the other hand, another app running straight up PHP/SQL with no framework was very hard to deal with.

    Of course, if you're a really good programmer, you can do things your own way and make things very efficient. You may leave less experienced programmers in the dust, thus making it hard to pass on the code. Also, I would think the application would still follow standard patterns which ressemble MVC and ORM's.

    It's not a black and white issue, but there's more to frameworks than just simple coding… it's a standardization in communication among teams.