The OO perspective

[lastcraft]

Hi...

at any rate, the churn rate on the reports and the applications is pretty low. once they're working, they're not altered that often.

In that case I would let them go their own way and only backport ifyou feel a compelling desire to do so.

i've read about it, seen it discussed, possibly even used it unknowingly.

It's an invisible wrapper...

class WithProductitivityCalculation {
    var $_table;

    function WithProductitivityCalculation(&$table) {
        $this->_table = &$table;
    }

    function nextRow() {
        $row = $this->_table->nextRow();
        $interval = $row['start']->calculateInterval($row['end']);
        $productivity = (float)$row['number']->getValue() / (float)$interval;
        $row['productivity'] = new DecimalField($productivity);
        return $row;
    }
} 

Usage is something like...

$report = &new Report('Employee Productivity');
$report->addTable(new WithProductitivityCalculation(
              new Employee Productivity($startDate, $endDate, $issue)));
$report->generate(new ExcelWriter()); 

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.

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.

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.

yours, Marcus

[lastcraft]

Hi...

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.

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 .

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.

yours, Marcus

p.s. Good advice, but I cannot give you any more rep.

[arborint]

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.

[josheli]

It will be slow going, but the only way is up.

Ouch. Hey, you don't scare me.

Consider programming itself.

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 are NOT inadequate.

It is about time someone told you!

YOU ARE NOT INADEQUATE.

* 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.

Craftsmanship.

Good programmers are judged ultimately on the efficacy of what they make, not on the cleverness with which they make it.

thanks. all in fun.

[lazy_yogi]

Ouch. Hey, you don't scare me.

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.

Interesting article tho.
Cheers for the link

[lastcraft]

Hi...

Ouch

Oops, sorry. Didn't mean it like that . I meant that the application wil get easier to work with and compared with the drudge of 35 apps. to maintain, the only way is up. I wasn't talking about you.

yours, Marcus

[Super Phil]

"Good programmers are judged ultimately on the efficacy of what they make, not on the cleverness with which they make it."


A quote from here, I think (not mine!).

"A good programmer can hand his code over to a third party and they can easily understand and modify it".

[arborint]

I think "architecture astronaut" is a fun straw man to write an articles about.

The "war between the humans and the computer scientists" is an exaggerated point in an article about somethings else.

"You are NOT inadequate" is a few good ideas wrapped up in some self-esteem mantras.

The "Craftsmanship" quote is true, but we are not talking about being judged here. We are talking about living with the the cleverness (or lack thereof) of what we make.

A bunch of interesting links though.

[josheli]

That's not what i think of when I think of an architect.

A quote from here, I think (not mine!).

"A good programmer can hand his code over to a third party and they can easily understand and modify it".

I think "architecture astronaut" is a fun straw man to write an articles about.

The "war between the humans and the computer scientists" is an exaggerated point in an article about somethings else.

"You are NOT inadequate" is a few good ideas wrapped up in some self-esteem mantras.

The "Craftsmanship" quote is true, but we are not talking about being judged here. We are talking about living with the the cleverness (or lack thereof) of what we make.

A bunch of interesting links though.

this is what i was talking about earlier in the thread. one can't even post interesting links without them being argued, dissected, debated, shot down.

uncle.

nm.

[lastcraft]

Hi...

this is what i was talking about earlier in the thread. one can't even post interesting links without them being argued, dissected, debated, shot down.

Er...isn't that the idea of a forum .

yours, Marcus