The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Now the extra calculation decision is explicit in the application and we have managed to keep the data fetch small. It also means that the data fetching code can be used again.

Originally Posted by josheli

sure, when you have a stab at it, Bob's your uncle, but when i get a couple of iterations in, i can't see the forrest for the trees.

The main thing is to do just one at a time. We all get stuck about the third iteration in, but the result is usually greater insight into the problem long term.

Originally Posted by josheli

so, as devil's advocate, assuming i go down this OO route, what will it buy me that some glue code, some functions and a few classes won't?

Because of the extra syntax it will grease the wheels in the following areas...
1) Clarity of the application code.
2) Being able to work on one extremely small piece at a time and know taht you are doing that.
3) Isolation of the application code. You should be able to add and remove parts of reports without major rewrites.
4) Ease of making changes once your core interfaces are correct. Making them a good fit is itself an iterative process. Things will be a bit wrong on the first attempt.
5) Ease of testing. Classes are way easier to test than bare scripts.

The real advantage is long term. You are enabling an evolutionary process by unlocking a feedback loop. As your understanding deepens you will come up with a more incisive solution than my off the cuff effort I'm sure. And you walk away with this knowledge onto future projects. It will be slow going, but the only way is up.

I've never had the luxury of "they should never be able to tell you how long a task should take" or "don't even commit to that because it's an estimate."

I've learned the hard way to make this clear on day one. If a building manager were to tell a bricklayer how long a wall would take you would expect to see them dangling from the scaffolding. Yet developers often accept these constraints without batting an eyelid. The result is long hours and stress.

These days I will be outright rude if the time message is not getting across because I know what's at stake. Our side of the bargain is transparency of progress, so at least they don't feel they are running blind.

Originally Posted by arborint

You will need to maintain old and new codebases for a while until you reach a point where the OOP implementation starts to make you happy.

Which is a pretty good benchmark .

Originally Posted by arborint

Finally, where lastcraft and I would disagree is that I think you could also refactor your current procedural code base and get similar gains.

Not at all, I would agree entirely. Even I'll cave in under that much pressure (35 apps) though and take the expedient option if I can.

With 35 applications I would keep at the hard work of "glue code, some functions and a few classes" but keep moving things OOP where you can. I find the challenge of evolving code to be one of the most satisfying parts of programming.

Unfortunately you really can't understand a new programming style until you actually solve one of your own problems using that new style. And that usually means solving it poorly first, then better, then settling into a good practice. That is until the smart guys raise the bar another notch.

There is an unacknowledged war that goes on every day in the world of programming. It is a war between the humans and the computer scientists. It is a war between those who want simple, sloppy, flexible, human ways to write code and those who want clean, crisp, clear, correct ways to write code. It is the war between PHP and C++/Java. It used to be the war between C and dBase. Programmers at the level of those who attend Columbia University, programmers at the level of those who have made it through the gauntlet that is Google recruiting, programmers at the level of this audience are all people who love precise tools, abstraction, serried ranks of orderly propositions, and deduction. But most people writing code are more like my son. Code is just a hammer they use to do the job. PHP is an ideal language for them. It is easy. It is productive. It is flexible. Associative arrays are the backbone of this language and, like XML, is therefore flexible and self describing. They can easily write code which dynamically adapts to the information passed in and easily produces XML or HTML. For them, the important issue is the content and the community, not the technology. How do they find the right RSS feeds? How do they enable a community to collaborate, appoint moderators, and dynamically decide whose posts can go through and whose should be reviewed? How do they filter information by reputation? These are the issues that they worry about, not the language.

* You do NOT have to refactor all your code.
* You do NOT have to keep up with the latest news from microsoft, and know everythnig there is to know about longhorn, whidbey, avalon, XAML, indigo and star wars III.
* You do not have to have perfectly de-coupled tiers in your technology independent SOA software.
* You do not have to comply to every standard, achieve the perfect balance between maintainability and performance. Usability and familiarity.
* You don't have to do "first things first every day"
* You DO NOT have to memorize and understand every patten the gang of four have catalogued.
* You do NOT have to read every technical blog, print out every technical article and learn every technical thing there is to learn.
* You are beautiful just the way you are.
* You are brilliant, interesting, wise and fun to be around.
* You rock.

That's not what i think of when I think of an architect. I see someone who designs and oversees the project implementation to make sure his design is suitable and changes when the implementation requires it to change for a concrete implementation. Having said that, in bigger compaines where there are larger teams, the lead architecht often is just what is described in that article - all concptual - and of course the design and implemntation end up being completely different products. Which largely makes the architects job redundant.