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]
