in reply to Re: Re^3: Nirvana through the templating yin yang (TT2 /
in thread Nirvana through the templating yin yang (TT2 /

The issue is behavioral , not logical and technical. The table depicts more of what tends to happen than what ought to be.

Sorry, I misinterpreted your post as saying that this was what should be, rather than what usually is.

When I said "PHP," I meant "PHP-like" way of coding style, i.e. writing everything mostly in one file, which applies to ASP, Perl-CGI, etc. I meant more of "style" than "technology." But "PHP" is shortest to write, lazy me.

I was trying to clarify my statement, not yours :-) I've been accursed of being anti-PHP in the past - and I'm not.

If you use XML as templating technology, you need (logically or physically) as many as four files--XML, XSL/XPath, {$insert_ur_fave_lang} script, and DTD/Schema. That needs a lot of thinking, even though it might not actually physically take you that much time.

True. In my opinion adding too much complexity is an even greater sin that not having enough. Needless complexity is evil. Things should be decoupled to make things simple - not just for the sake of it. A four tier framework is not the right answer to all questions.

For a lazy or inexperienced person, or for a person who has been torn by constantly scraping and redoing his work because of incessant whimsical change requests, would he tend to do it in one file or four files? "Why should I constantly make changes in four places rather than one?"

The lazy person needs firing.

The inexperienced person needs experience and mentoring.

The experienced person should realise that decoupling makes dealing with whimsical change requests easier not harder. If it doesn't then something is wrong.

If everyone does what's "logical," I didn't have to explain to someone why he shouldn't embed a SQL statement directly into ASP, but rather write a stored procedure and call it from ASP instead. Or, to a manager, why JSP doesn't make much different from ASP--it's the people (programmers and others) who make the difference (as some people, especially those who don't "implement" anything, tend to believe technology by itself does magic, and implicitly feel it can compensate for faulty business ideas and relieve them from thoughtful planning and "well-defined" spec).

It's nearly always a matter of context. Stored procedures might not make sense if you need to support multiple databases. JSP might not make sense if the rest of the company's codebase is ASP. A 4 tier application might be overkill if all you need to do is munge a database table into an HTML page. Etc.

It is part of our job as a developer to explain these things. After all, if they didn't think it was magic why would they have to hire us :-)

The key phrase is " as long as the interface is well defined ," as you said it. When sometimes you have account managers continuously walk up to a programmer directly requesting making changes at once, without notifying the project manager, everything is "on-the-fly" rather than "well-defined."

As the years go by I am more and more of the opinion that the "well-defined" spec is a myth outside a few safety-critical environments. The world doesn't work in a way that can produce a well-defined specification document. Business requirements change to quickly and cannot be expressed exactly without an unwarranted expenditure of effort, or by actually writing a working system that allows reality to be compared with expectations.

(Pointless anecdote: I once did some work with a .com startup who regularly changed their entire business model between meetings. One month it would be selling a product, next month it would be selling demographic information from site visitors, etc. It didn't end well :-)

The world tends to go the natural human behavioral way rather than the logical programmers' way. Behavioral change is hard. In my experience, people issues far exceeds technical problems in any project, for people don't always do the "logical" things.

In the fifteen odd years I've been a (vaguely :-) professional coder I can't recall a single project lasting more than a few weeks where the spec hasn't changed, often significantly.

Most of the time this isn't due to a lack of will, just lack of communication or an incomplete understanding of the problem space.

These sorts of issues are have caused me to move towards more agile development methodologies - where these issues drive development, rather than getting in its way.

  • Comment on Re^5: Nirvana through the templating yin yang (TT2 /