Something all of us developers realise but it doesn't always smack home until certain scenarios arise - The Wall (as I'll call it for now) is the virtual line behind the UI which is where the developer / client separation of concerns occurs. The client wants to see one thing on a UI, click a few buttons, hit a few keys and see the UI change to another thing, this change indicates that we as programmers have done our job, behind that line is generally our concern.
Here's the scenario.. a few weeks back "we" started a full 3 tier app, the Applcation tier consisted of the three big layers, service layer -> domain model layer -> data source layer; everything implemented by the book with transfer objects, DAOs, business objects, a full language extension lib, utils, everything coded to interfaces and using factories.. you get the picture.. a lot of code. On the presentation tier we had single UI consisting of a full MVC framework with all the magic and goodness, the models of which talked to the service layer of the application tier (as it should).
A couple of hundred hours later we get our first full end to end done, a simple FAQ system.. possibly the most overkilled FAQ system ever, but still a great end to end test. This is where the wall becomes clear, because for all of that the client only saw a simple FAQ system.
At this point, as a developer you have to ask yourself why.. the FAQ system could have been developed in circa 1 hour using a few lines of PHP and simple mysql database + some echo's.
I don't have an answer to this, and don't think there is one... because if you think about all the immediate arguments for doing it the "proper" way.. maybe even the java way - you still have to think, what is more maintainable a few hundred files and a complex architecture full of design patterns, or three lines of PHP a "n00b" could maintain.
More over.. ultimately those few lines of code you could make the application with are pretty much the same few lines of code which aren't reusable when using the full application approach.
Finally you ask yourself.. if a good programmer introduces about 2.5 bugs per 100 lines.. then what requires more long term maintenance; 100 lines for a full FAQ system or 100 classes with 100 lines each.
Just a thought, that won't go anywhere - because i get paid to make these big applications, but when the pressures on and I've got a 3 hour deadline I do the 100 line thing.
no response needed, simply questioning oneself (again)
HA! couldnt agree more! I think this is the thing that kills java- the culture that everything must be done *properly*. Like all things, its a matter of finding the common ground- Too much focus on coding conventions and patterns causes bloat, while too much php hacking makes for ugly brittle code. Php does bring out the devil in people... i'm sure of it ;P
Its really up to the developer to design with simplicity and the end goal in mind
Good point, makes one wonder: would starting a FAQ in PHP and then the site evolving from around there lead eventually to reimplementing the whole mega-modular thing later? Would that be better or worse than starting from all the modules, if you end up pulling them in one at a time as required anyway?
Reading http://webr3.org/blog/general/the-wall/
This comment was originally posted on Twitter