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]
