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]
