If it’s something simple I’ll make a function.
If there are many functions that start to relate to one another I’ll see if there is a set of them that would quickly and easily make a usefull class.

Only if it’s obvious the use of some part of code can be used on a majority of my projects, or if I find myself redoing something quite often that I didn’t foresee, then and only then will I bother with really fleshing something out, and only in free time… like at the coffee shop on paper or if I have maybe an hour left alloted for the day on a project I finished/got to a good stopping point early.

That way, your time is not wasted on details that may end up being irrelevant for a long time anyway, and the process is more "organic" by "evolving" in a manner that tends to be the path of least resistance.

I have seen the advantages of a large design stage, but unless the programmer is working on a huge project that may be split to multiple teams of coders, and they are the one overseeing most of that… or at least fleshing out the parts so management can split it up, it just doesn’t appear justifiable from a more financial/business sense. If that is the scenario however, reuse and modularity is almost a necessity for organization’s and sanity’s sake.

Well, there’s my two scents, hope it helps.

Try to code projects, so that you can reuse the code later, whether using functions or objects, but don’t lose sight of the original goal. If you don’t have a deadline, then it is all good.

I’m a hard advocate for code reuse and OOP. Sometimes, you just have to say to yourself, do I want to do this done right or do I want it finished quickly. It is a hard decision and you can’t have it both ways every time.

Embedded Mysql queries can be maintainable if you separate the content out. If you are looking at a huge blob of text with queries, then it does tend to hurt your eyes.

It’s even more difficult if the project spans a few major php releases (i’m still working with a website that was developped when php 4 was just a new kid on the block) and contains a lot of code.

The programming world also changes, in 1999, in the php world, not a lot of ppl were working with OO. Database good practices for mysql also changed since v3 etc etc.

I strongly believe, that a site build by complying to the latest trends (OO, patterns, database abstraction, unittesting etc) will be a lot easyer to maintain over the years. Butalas, it’s true, writing unittests, or phpdocs, etc takes a shitload of time, mabe better used adding features