Dharmendra
Speaking as someone who has a 10 year old gas guzzler..yes I admit
everything is wrong with the vehicle and it eats gas but at least its paid
for!
Yes I worked for someone who wanted to re-engineer my J2EE application to
Perl (because they did not understand OO)
I think it is imperative to keep ones mind open to better and more efficient
solutions even to replace the solution you have just implemented
provided that the Solution MUST Fit the client's environment
As one of my professors once said..The only constant is change..therefore we
techno-evangelists must be the *implementors of change*
Have a good day all,
Martin-
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <user@struts.apache.org>; <[EMAIL PROTECTED]>
Sent: Friday, October 07, 2005 2:33 PM
Subject: OT: RE: Development philosophy and such (was: Base action class)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
