My manager pushes me to use his self defined best practices. All of these practices are based on is own assumptions. I disagree with them and I would like to have some feedback of well experienced people about these practices. I would prefer answers from people involved in the maintenance of huge products and people whom have maintained the product for years. Developers with 15+ years of experience are preferred because my manager has that much experience himself. I have 7 years of experience.

Here are the practices he wants me to use:

  • never extends classes, use composition and interface instead because extending classes are unmaintainable and difficult to debug.

  • What I think about that
    Extend when needed, respect "Liskov's Substitution Principle" and you'll never be stuck with a problem, but prefer composition and decoration. I don't know any serious project which has banned inheriting, sometimes it's impossible to not use that, i.e. in a UI framework. Design patterns are just unusable.

  • In PHP, for simple use cases (for example a user needs a web interface to view a database table), his "best practice" is: copy some random php code wich we own, paste and modify it, put html and php code in same file, never use classes in PHP, it doesn't work well for small jobs, and in fact it doesn't work well at all, there is no good tool to work with. Copy & paste PHP code is good practice for maintenance because scripts are independent, if you have a bug somewhere you can fix it without side effects.

  • What I think about that:
    NEVER EVER COPY code or do it because you have five minutes to deliver something, you will do some refactoring after that. Copy & paste code is a beginners error, if you have errors you'll have the error everywhere any time you have pasted it's a nightmare to maintain. If you repsect the "Open Close Principle" you'll rarely get edge effects, use unit test if you are afraid of that. For small jobs in PHP use at least something you get or write the HTML separately from the PHP code and reuse it any time you need it. Classes in PHP are mature, not as mature as other languages like python or java, but they are usable. There is tools to work with classes in PHP like Zend Studio that work very well. The use of classes or not depends not on the language you use but the programming paradigm you have choosen. I'm a OOP developer, I use PHP5, why do I have to shoot myself in the foot?

  • When you find a simple bug in the code, and you can fix it simply, if you are not working on the code where you have found it, never fix it, even if it takes 5 seconds.
  • He says to me his "best practices" are driven by the fact that he has a lot of experience in maintaining software in production (14 years) and he now knows what works and what doesn't work, what the community says is a fad, and the people advocating such principles as never copy & paste code, are not evolved in maintaining applications.

  • What I think about that:
    If you find a bug fix it if you can do it quickly inform the people who've touched that code before, check if you have not introduced a new bug, ideally add a unit test for it.

I currently work on a web commerce project, which serves 15k unique users per day. The code base has to be maintained and has been maintained this way since 2005.

Ideally you include a short description of your position and experience in terms of years effectively maintaining an application which has been in production for real.

  • 5
    You want to outweigh a manager of 15+ years of experience with arguments from developers with 15+ experience? I doubt that the conversion ratio is 1:1 and that a manager with such strong opinions can be convinced otherwise. If I were you I'd be looking for a new job. – bhaak Dec 5 '12 at 10:38
  • I'm looking to a new job currently, but I really enjoy to work with the rest of the team, and my manager claim that I not competent at all. I would like to really know if I'm wrong or right, and I want to inform my CEO the objectives reasons why I will live the job. My CEO says that he is not an expert and is confident on what say my manager about me – Damien M Dec 5 '12 at 10:57
  • I don't want to convince my manager, which argue that experience of others are not valuable, practices defined by community are fashions. He is really sincere and changing his opinion mean revoke belief based on it's own experiences. For him it's the best way and it work certainly for him for years, I cannot pretend what is good for him or not. I just know my best practices are shared by all others out there and I would like to keep up with the rest of the industrie, I do know that it's the way I 'am more productive and efficient. In such condition I'm currently leaving the job. – Damien M Dec 5 '12 at 11:05
  • IMO nothing you wrote sounds unreasonable, stupid, or even incompetent. You seem to know that there is not a silver bullet that will always work, that a developer has to look at the current situation and decide which action to take. From a general POV your manager's "best practices" look really odd. Maybe, just maybe, they work for that project you're currently on but I doubt that. That your manager calls you incompetent for wanting to follow standard procedures makes me doubt it even more (my xp: 12 professional coding (~20 if you include nonpaid stuff), nowadays mostly in Java, C, and Ruby). – bhaak Dec 5 '12 at 11:36
  • thx bhaak can you post that comment as a plain answer please ? – Damien M Dec 5 '12 at 14:33

O my...

Inheritance vs composition

About inheritance versus composition. Both have their use cases, it is as simple as that. There is no good reason never to use inheritance or never to use composition.

If you have a different types of webshop products: say basic (can of coke, can of sprite), configurable (a sandwhich with an option to choose type of bread and toppings) they are bound to have things in common like title, price, etc. There are also things (predominantly in the configurable product probably) that are unique to the implementation. I would always use inheritance for this.

If you have serious webshop with prices, discounts, different vat percentages,etc, I would always make Price a seperate object since you're bound to do a lot of calculating that you want to isolate and unit-test. I would never extend Product from Price however. So this example is part composite (Price) and part inheritance (Product type tree). Common sense and use case are keywords here.

Copy/paste vs creating

Again, there is no right and wrong here. I hardly ever copy anything, but using something as a template to quickly setup something else might be worth the time. I agree with you however, that since you need to change function names, class names, variable names and slightly change the algorithm, the time you gain is very little at best. If you do not need to change things by the way the function should be re-used. If you change a little the function should be more robust and be re-used.

What can be convenient is the following. At my job we have a large system that consists of loads of modules. Each module has an index, some basic folders, a setup file, a plugin registry, etc. Creating a new module with all those files isn't something we do manually. There is a script that takes some parameters and does the work for you. Copy and pasting a small module and working from there is a no no, generating exactly what is necessary is great.

By the way, copying and pasting is NEVER good for maintenance. It means if you have a bug somewhere you're likely to have copied to other unknown places as well. I'd rather fix a bug in one location only. Most certainly since I'll write a test and it will never occur again.

Mix HTML and PHP

Please. Do. Not. Do. it.

We're currently in the process of migrating to twig as a template engine. This is so much better for development and design. For development it means cleaner readable code without for loops and tricks to add classes (odd, even, first, last), for design it means they have simple html like template files that they can maintain themselves.

I am truly happy with that change and we see the fruits of this migration on a daily basis.

To class or not to class

This is style related. But the fact that it doesn't work at all, that there are no good tools is plain nonsense. PHP OO has come a long way. I'd say about 70% of our current code base is object oriented and about 98% of newly written code is. Everything is functioning just fine.

I can imagine that you wouldn't write a class, instantiate it and call the single method that it holds for a simple operation. I do it, but this is heavily personal preference related. I agree with you, if you're used to OO and have php 5 available, why not use it. The only reason I can come up with is the rest of the development team doesn't know or understand OO. If you alone in a team codes a specific way, you can't expect the rest to adapt.

There are brilliant editors around, I love PHPStorm. But even vim can be configured to work with PHP like a bliss. I do not know what kind of tools your manager wants but I can't say I miss something.

Fixing bugs

I can't figure out why you'd not fix a bug you encountered. I can imagine if the code is complex you'd get the person who wrote it originally involved, but ignoring it altogether is plain stupid. Not fixing a simple bug if it right in your face is even negligent to your customers.

Concerning me

I work on a codebase of 2000000 lines of code that is used by tens of thousands of users. I work in a team with 10 other developers. I'm coding professionally for somewhere around 5 years but ever since my first contact with BASIC (about15 years ago) for fun. I would like to take this opportunity to state that experience isn't everything. I'm certainly not all knowing, absolutely not done learning but it sounds to me that your manager, 15 years experience or not, isn't either.

Also I do agree with the first comment on your post. Trying to get your manager to agree with you might a waste of time, it seems he made up his mind. Hopefully good arguments might help you a bit though :)

I would like to end with a sincere: Good Luck!

|improve this answer|||||
  • 4
    not fixing bugs may be because he wants a report raised so costs can be tracked, or impact can be assessed (e.g. will it require docs to be updated?). I do think using the word never here is going over the top though – jk. Dec 5 '12 at 10:54
  • I agree, there might be reasons, there actually almost always are. I've however found that focusing on 99% of the cases avoids discussion on a sound principle revolving around a very specific case that doesn't happen very often, if at all. – hoppa Dec 5 '12 at 10:57
  • jk right ! @hoppa thx, I would find answer from more experienced developer or architect too – Damien M Dec 5 '12 at 11:08

As both manager and developer:

Yes I believe things can be done more nice. Totally correct. I don't know codebases which can't be better since that would mean there wouldn't have to be made any considerations based on for example budget, time, staffing etcetera.

Developer view

Implementing best practices in your codebase is actually very important. Like implementing correct design patters, code standard, testing. We all know it.

Manager view

The opposite view, of the manager, is actually also not wrong. He cares about keeping the codebase the same way it is, so the newer parts are designed equal to the already existing parts. You can decide that's not the best way but it is following the standard of the codebase.

Example topic

This one is very interesting:

When you find a simple bug in the code, and you can fix it simply, if you are not working on the code where you have found it, never fix it, even if it takes 5 seconds.

You don't post the "why" he decided this. Is your code unit tested with high coverage? If not: This point is actually very valid, you won't be able to find what's broken when you fix this "bug".

See, there is the difference between the developer and manager role. Developer sees bug, fixes it and proceeds. Or developer implements nice new class structure. But the responsibility goes to the manager.

So with the bugfixes or changes done the manager still has to:

  • Deliver the right features in time
  • Make sure the system doesn't break (did you test all features when you implemented that new class structure?)
  • Ensure that if you are gone another developer can proceed on the work
  • Etcetera

Sometimes nice is not the best solution BUT the manager is there to support the developers. Not to fight them.

Be constructive

So: If there are points in the codebase which should be improved, like the copy-paste area he should at least be listening. You might for example build some demo case on it saying:

  • We used copy-paste to create 1000 individual copies of this script
  • Development time on it is: ....
  • Bug fixes take more time because we have to copy-paste etc.
  • We could fix this with following classes / code generation tool / whatever you think.

Then you have a project proposal. Now you can discuss with the manager / team whether this project is important, is there budget, time etc. The you are really talking and improving the product and the teamwork.

Saying his view is worse than mine isn't constructive, prepare, decide and act. Together.

|improve this answer|||||

Is your manager familiar with an object oriented programming? Objects were introduced into the PHP not so long time ago and at the beginning it was rather "lets make some libraries as objects, add class statement and we have object oriented programming language" - very similar to the situation with VB v4

What you describe as practices is at least strange and in some places plainly wrong from the programmer's point of view. But it seems that those practices work and it may be hard for your manager to become accustomed with something new. Your CEO is concerned with the customers paying for your work and "proper OO practicies" are completely irrelevant for him.

I have seen lot of badly written code but at the same time everyone was happy as this badly written code was doing it's job at least from the user point of view. In different companies you can see different approach to the programming process if you care about proper practices and want to be what we could call "a good programmer" then you should find a company which cares about such stuff.

|improve this answer|||||

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