I think this philosophical topics are SUPERB, specially on fridays. I don't have Ur xperience in development, but I'm a "new tecnology skeptic". If someone in my team tells me to use X tecnology, because it's brand new, etc.... or if because it's a standard, I just tell him about the risks, the standards, the "market standard", the learning curve, the productivity, etc... If I can't learn it in 2 or 3 days, we don't adopt it. The last one that I burned my tongue about was JSF, that I was a TOTAL skeptical, but I liked a lot.
Best regards, and have a nice weekend. Rafael Mauricio Nami 2005/10/7, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > Hi Frank, > > Sorry couldn't help but remark that... it seems some people are forgetting > the software engineering basics.. :) > > "There is no silver bullet!" > > And you are absolutely right that there is no justification for using new > technology just for the heck of it... (And there is a reason some of the > banks still have those mainframes lying around!.) like they say "if it ain't > broken, don't fix it!". > > Here's wishing you Happy Friday!, > > Cheers!, > > Dharmendra > ps: have a super day! > -----Original Message----- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: Friday, October 07, 2005 3:08 PM > To: Struts Users Mailing List > Cc: user@struts.apache.org; [EMAIL PROTECTED] > Subject: Re: OT: RE: Development philosophy and such (was: Base action > class) > > > On Fri, October 7, 2005 2:33 pm, [EMAIL PROTECTED] said: > > 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!!. > > It's not so much what I believe as I have seen a number of people who do > exactly that. They are just trying to pad their resumes and not thinking > about what solutions properly fit the requirements. I'm not talking about > making a bad decision by the way, everyone does that on occassion. I'm > talking about people that are constantly looking for situations to apply > new technologies to, not because it will make things better but because > they want to gain experience with those technologies. > > Gaining experience is a good goal, doing so with no vision of what makes a > good solution isn't :) > > > 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 your talking about evaluation with each new project that comes along, I > absolutely agree. What I'm talking about being a problem though is taking > an existing application that is solid and robust and does everything it is > required to do, and deciding to redo major parts of it just because some > "better" technology comes along. > > From a technology standpoint, you always run the risk of making things > worse when you refactor. That's not to imply that you shouldn't refactor, > just that doing it on a whim to play with a new toy isn't the best > motivation. > > From a business standpoint, why incur a risk that you don't have to? I > have seen time and again where an application that worked well was deemed > "old", whatever that means, and was redone, and the result was worse. If > you have a requirement that the application can't meet in its current > form, *then* it is of course appropriate to rework it. But in the absence > of such a requirement it seems to me very hard to justify that risk. > > > - 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.. > > Again, if the requirements change, so to the application may have to, and > so to may the underlying technology have to. I don't have any problem > with this, as long as it's not taken to the extreme... I've seen cases > where people say "ok, we need to add X to the application to meet this new > goal, so while we're at it let's add Y and Z because it scratches an > itch". X is good, Y and Z aren't. > > Maybe that's how I should put it... change for the sake of "scratching a > technological issue" isn't (usually) a good thing. Change for the sake of > meeting a new requirement is. > > > 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...) > > And I wouldn't say there's anything wrong with that :) But think of this > scenario... what if after 3 MONTHS someone decided that wow, J2EE is all > the rage, let's rewrite this application because we want to get J2EE > experience. Would that be OK? > > For you as a technology person it may be, but probably not for the > business, and IT is here to service the business, not the other way around > :) I see people forgeting that all the time too. > > > 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!)!!! ;-) > > Let's not talk about mechanics... sore subject around these parts right > now :) > > I get your analogy of course though. Especially since I just bought a new > car recently because my old one was too expensive to keep running. > > But what if this week, after having my new car for a month or so, I decide > that the '06 model is cool and I want it, even though the car I have now > is doing the job just fine and has some headroom to keep doing fine for a > while. Good idea or not? :) > > > 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. > > If that's your underlying thesis, I in no way disagree :) > > Here's my closing argument :) ... > > Anyone still doing QuickBASIC programming because that's what they are > comfortable with is probably not open-minded enough. > > Anyone that still has a QuickBASIC program that is chugging along just > fine that the business depends on and yet wants to rewrite it from the > ground up using JSF, Hibernate, Spring and run it on Websphere tied in > with LDAP, unless they can prove that there will be a substantial gain > from the effort, is probably just trying to make their resume look better, > and I would have a problem with that if I was their superior. > > (and before anyone says it, yes, there is obviously benefit in usual > technologies you can hire people to support, a problem you might have if > you keep using that QuickBASIC app... that *may* be justification enough > to make the change, but it's at least debatable because I can probably > find any reasonably capable programmer and have them supporting that QB > app in short order at as reasonable level, so that justification might not > be as strong as you would think initially... as I said though, this is all > debatable) > > > Regards, > > > > Dharmendra > > ps: have a good day! > > You as well! :) And thanks for input, I think these philosophical > discussions, regardless of where you come down on them, are always > valuable, if just to hear how other people approach things. > > Frank > > --------------------------------------------------------------------- > 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] > > -- Java - Assim no Server como no Palm <i>Java - thus in the Server as it is in Palm
