Development philosophy and such (was: Base action class)

["Frank W. Zammetti" <fz...@omnytex.com>]

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: fzammetti@hotmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Development philosophy and such (was: Base action class)

["Frank W. Zammetti" <fz...@omnytex.com>]

On Fri, October 7, 2005 1:27 pm, Michael Jouravlev said:
> P.S. The last soldier's reply does not exist in original joke, but
> many people I told it to could not get the joke without it ;-)

You really need to find some different people to talk to... the type of
people that wouldn't get it without the last line are the type of people
that just randomly stop breathing because their brain is at full capacity
and the lowest item in the stack had to be discarded :)

Frank


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Development philosophy and such (was: Base action class)

[Michael Jouravlev <jm...@gmail.com>]

On 10/7/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I think we unintentionally hijacked a thread, so just in case we discuss
> any further, a topic change is probably in order...

Tell me about hijacking ;)

On 10/7/05, Leon Rosenberg <ro...@googlemail.com> wrote:
> But I'm absolutely with you, if you say that the layer should only
> throw general-style exception to the caller. The caller isn't
> interested why an operation can't be performed, if the db ran out of
> disk space or is simply tired. The caller is interested in:
> was the call sucessful?

Well, thinking about it, it is not that different from real life.
(I hope I did not post this joke before)
<friday>
  Army garrison. A Colonel walks around the regimen,
  and sees a soldier, polishing his boots with red shoe polish.
  He approaches and asks:
  - Soldier, what are you doing?
  - You don't give a damn about that,- replies soldier
  - What? Answer as required!
  - Sir, the garrison is out of black shoe polish, so we are using
    red polish for out boots, sir!
  - I don't give a damn about that!- shouts the colonel out.
  - Yes, this is what I just said.
</friday>

So, the caller does not care what exactly happened, it cares in resolving it :-)

Michael.

P.S. The last soldier's reply does not exist in original joke, but
many people I told it to could not get the joke without it ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org