Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have been trying for months to convince my boss to switch to OOP php, but each time, he takes out his previous experience with programming and convinces us other wise.

i need to talk like a boss to him, tell me how do i convince him? I need to make him understand the long term benefits and also financial benefits.

One arguments he used today was that it was not optimum for performance, like each time you need to make a conection to the database, you need to create a new object each time.

Please help me.

share|improve this question

closed as not constructive by Robert Harvey, Mark Trapp Jul 26 '11 at 19:11

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

"Machine time is cheap, developer time is expensive" "Development is cheap, maintenance is expensive" etc – Raynos Jul 26 '11 at 18:12
What platform are you running right now? – mclark1129 Jul 26 '11 at 18:14
windows, even at work we use windows – mahen23 Jul 26 '11 at 18:18
nopes, WAMP-> Windows, Apache, MySQL and PHP – mahen23 Jul 26 '11 at 18:31
@Raynos best comment to any question I've read in a long while. – Patrick Hughes Jul 26 '11 at 18:50

Is your boss writing code?

If Yes: You need to be able to deal with the fact that not everyone on your team knows as much as you do. Maintainability is the most important thing, and code that can't be maintained by half the team because they don't understand it will never be okay. Teach the techniques to everyone on the team, and why they are valuable, and they will eventually use them.

If No: The real problem here is convincing your boss to butt out of the technical team's decisions. The coders should own the code, and should have responsibility for deciding what standards apply. If there are technical requirements, get them defined. ("Doesn't use OOP" is not a technical requirement. "Customers can edit the templates" is.)

On Performance: Performance should be measured and unacceptable performance should be fixed. "This code construct is slower than that code construct" is not a measurement. (I mean, if it slows server startup down by a tenth of a second, who cares? On the other hand, if it slows page rendering down by a tenth of a second, that may be a big deal. Measure.)

share|improve this answer

Since his argument is that performance is affected by OOP, I think you should start by showing that he's wrong. It will not be too difficult to do a benchmark to show that the performance is the same or nearly the same when using OOP compared to procedural approach.

Also, the last part of the argument makes me think that your boss doesn't know too much about development in general. Since he's not a programmer himself and does not have a solid background in development, it would be easy to convince him that the things he learned from some unknown websites or some conferences he assisted in 1998 are plain false or not true anymore. Sometimes, it may even be a good idea to invent some fancy arguments, like:

We really must move to OOP quickly, since in PHP 6, it will be impossible to use procedural programming any longer.

Of course, you should use such fancy arguments at your own risk and only when your boss doesn't know anything about the subject and if his own arguments are not proven as well.

Is there a guideline in your company which forces you to never use OOP in PHP?

  • If yes, well, it's too bad. It's often hard to discuss about guidelines, especially when the opponent says that in first place, we must not discuss them because they are here to ensure the uniformity of the codebase. You may still try to convince at least your coworkers to start violating the guideline, or trying to do all you can to see this guideline removed.
  • If no, then I don't see what's the problem. You write code, you decide to use OOP, you use it. If your colleague wants to rewrite thousands of lines of code to remove OOP, he's free to do it.

Showing world examples (large projects written by professional developers where OOP is actually used) may also be helpful to convince your boss.

Finally, if the boss doesn't listen to any of your technical arguments, there is the last one:

I've done the estimate of the change you requested the last Friday. It will give us four weeks to do it, since the actual code is a mess and it's nearly impossible to find where to put what. Ah, FYI, if the source code was refactored correctly and if we used OOP from the beginning, it would take us only three days.

share|improve this answer

Quite simple - if it's not OOP it cannot take advantage of any modern framework, nor any ORM solution.

Alternative is to develop in-house frameworks, which requires lot of effort and lot of maintenance.

share|improve this answer

Good Luck!

For the most part, you are going to need to have an answer for each of the concerns. Like with the database connection example, you can point out that you can use the same object or even allow one instance of the object (i.e the controversial singleton). You will have to debate the point that OOP will make the code flexible and easier to maintain. Also more testable, which makes it easier to refactor.

Try to avoid being confrontational about it though. Ask questions about the approach and offer alternative OOP solutions. Be polite though. Attacking may cause your boss to be on the defensive.

share|improve this answer

Have you ever worked in sales of any kind? If so, were you ever trained to "overcome objections" or otherwise convince the customer that what you were selling is a good thing?

The same applies here.

Gather up his objections and research the counterarguments to it. Is your current method actually faster than OOP PHP? Probably not, but in the chance that it is, focus on the faster development time that OOP provides. Will it take too long to rewrite the codebase? Probably, if done at once, so explain the benefits of refactoring over time, or the long-term benefits of spending a couple of weeks doing it all at once.

Remember, you're selling something "new" to your boss, which means it can't be just as good as the familiar, it has to be better, and it has to be obvious that it's better.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.