Hi Frank, Here's the thing about technology, it *evolves*... and it comes as really odd that you *belive* that people introduce new technology solution, architecture, design changes, to just make them more market-able!!.
I don't subscribe to this idea, but I would like to add however that:- - it is a by-product of, working with the current state of technologies - also if the "change/..." doesn't buy anything, then people simply don't stick to it... (reminds me of the "Origin of Species") Further - it is not a bad thing to continously evaluate the solution/approach to see how well it could handle anticipated changes, scale to new/additional/changed requirements... - if you want you can always develop your apps for any particular platform say DOS or Win 3.1 (just to name some of the non-*nixes!) and then worry about the GPFs blowing the fuse!! ;), or, perhaps worry about the database getting corrupted (I have actually seen this!!), when, say the application's data grows substantially over time... or any other factors necessitating the change..too many to list them all.. The point is that the applications need to grow and be adapted to "changes", in innumerous ways possible, which impact it's usability/stability/maintainability/... I have seen OO Perl/CGI application written for three people grow to a user base of 600 in 3 years, at which point it just wasn't cutting it, as well as changes were much harder to make, taking more time, and to maintain bugs, at that point it was retired and redesigned from ground up and implemented in the latest and greatest technology known at that time (aka J2EE...) I have an analogy, perhaps it's just like, after a while it's just *too much* to keep patching up an old car..it's much simpler to just get a brand new one instead (perhaps to avoid worrying about the gas(money!?)-guzzling monster, which sits in the mechanic's garage more than in your garage!)!!! ;-) So there you have it... again it's getting into the philosophical zone and way-off topic!, so I'd leave it at this... In summary, I'm not saying that your methodology/approach is wrong, just that it helps to keeps ones eyes and ears open! and anticipate and be *open* to ideas/changes and change is not necessarily a bad thing. Regards, Dharmendra ps: have a good day! -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, October 07, 2005 1:10 PM To: Leon Rosenberg Cc: Struts Users Mailing List Subject: Development philosophy and such (was: Base action class) I think we unintentionally hijacked a thread, so just in case we discuss any further, a topic change is probably in order... On Fri, October 7, 2005 12:14 pm, Leon Rosenberg said: > My leitmotif is always: keep it simple. No ibatis, no hibernate, no > ejb, no nothing unless you explicitely can prove that you need it. You and I would get along very well I think :) That has always been my approach as well. I don't like people that throw new technology in the mix just to get experience. Wendy Smoak turned me on to an acronym that I think is great (she got it from someone else, I forget who): ROP... Resume-Oriented Programming. I can't STAND people that take that approach. I don't like re-inventing the wheel, but if you can't prove to me that I need the wheel to begin with, I prefer to walk :) > I often hear, exchangeability of the database is not needed, noone > ever exchanges the db in the real world, and if they do, the have to > change everything either way. I've never bought this argument either, and I've heard it plenty. Here at work we're a Websphere/Oracle shop, and most of the other architects and developers have no problem building Websphere-specific or Oracle-specific applications. I don't agree with that. I strive for complete independency from those things. Now, I'm not saying it's *always* bad to be tied to Websphere or Oracle... it *always* comes down to what's required. But, I go into things trying to not be tied to anything. I develop on Tomcat and deploy on Webpshere specifically for this reason. I can be *reasonably* sure I'm not tied to Websphere. As far as the DB goes, I develop against Oracle as well, but I'm very careful not to use anything Oracle-specific, or if I have to I try and do it in the DB itself (SP's and such, which I generally try and avoid too). In addition, I develop on Windows but deploy to Linux. OS transparency is important too, and sometimes you can blow it in very subtle ways. > We actually really do exchange the db > daily. Our complete application runs in production on about 25 > servers. I can reconfigure it to use filesystem based persistences and > run it on my notebook if I want to work on the road. It runs with > corba in production but I can reconfigure it to use direct java calls > (with local instantiation) or RMI, or whatever SOAP, or whatever we > will decide (and implement) tomorrow. (Sofar for self-advertising :-)) Sounds familiar... Under Websphere we use J2EE security against LDAP, but in development I switch security off completely (I know I could do most of it in Tomcat, but then I'm tied to Tomcat for development to a degree :) ). > If it works its perfect --> XP. Why should you change anything in an > existing application if you don't have a requirement to do so :-) Ask those around me who like to change things just because it doesn't meet their vision of how things "should be done". I had one application in production for almost 2 years, solid as a rock (amazingly so frankly). They can down with a bunch of architectural changes they wanted made. It took me about 2 months to make the changes, and another 6 to get the damned thing stable again. Very frustrating, and it was all superfluous changed in my opinion, for exactly the reason you state above. > I think by time it would become a problem, you would know how to > change it, so its not a REAL problem. > The REAL problem I often see, is that developers don't have the guts > to say to the manager: "Ok, this is a complete new requirement, so I > have to change alot, even it looks like an hour of work to you, it's a > week for me". Instead they start to hack. > Half year later the application dies because of major architectural > flaws... > (Surely would the developer have the guts and tell this to the > manager, noone can assure that the manager has the appropriate answer, > but most managers I know act quite rational, if you can explain the > problem to them in their language (like we save one week of my > worktime now, but loose 3 days of sales in two month...)) Very true. I've been fortunate to have worked with mostly good PMs and managers, so I haven't really run into these problems. Then again, they all understand that I overestimate as a matter of course :) And not just a little fudge factor... if I know something is going to take me 3 days to do, my estimate is 7.5 days (times 2 plus half). Then I wind up doing it in the original 3 days anyway, so it always looks like I'm coming in ahead of schedule :) Those above me have figured out my pattern, but they live with it because the handful of times it actually takes longer than I expected, I'm *still* no worse than on schedule :) Makes them look better too in the long run. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]