OK, now that you've mentioned porting an existing application, I can *kind of* understand that.
I'd expect most management to take the approach "if it ain't broke, don't fix it" - and in their eyes it ain't broke. A while back I was in a similar situation - like you, I tried to explain the case of doing it the correct way (cheaper, faster, easier to maintain, following conventions(!) less risk, etc) but they weren't interested. If I had the time, I'd do a TCO study for my next symfony project - showing how long certain aspects took with symfony, how long they'd have taken without symfony, and how that affected the overall cost/ profitability of the project. It would also be good to see a similar thing to compare different frameworks - after all, apart from availability of developers with experience, the next most important thing about a framework (for management) is how much it's going to cost or save them, isn't it? On 1 Nov 2009, at 21:44, Derrek wrote: > > >> Do you know the reason they don't want to use symfony? is it because >> they want to maintain the application themselves? or with labour >> cheaper than yourself once it's built? it would be interesting to >> know... as it could spur on a symfony and TCO study or something. > > It's a bunch of things. Using symfony would actually let them get less > costly help than me once the app is written. The problem I think is > the up-front investment in conversion. Most of them have tech guys > that are comfortable with how things are now. So the tech guys tell > management "we don't think it's worth the cost". It's much much *much* > (let me reiterate *MUCH*) easier to get management to start with > symfony on a new project. But if there is an existing system, even in > php, they shy away from it. It may be a good idea to have tutorials > for showing how efficiently an app can be re-developed in symfony when > coming from another platform. > >> I actually find that it takes me considerably longer to do anything >> when not using symfony now... validators? security? ORM? ergh. Even >> simple CRUD applications can be knocked out quickly - remember the >> original Blog screencast for 1.0? how long did that take? 8 minutes >> or >> so? > > I concur, especially on new development. I can knockout a new project > for a demo in a few days. Polish a large project in a few weeks. But > migrating an existing system with 200+ tables in a best case scenario > takes time. Time that will be saved when faced with the idea of re- > creating what symfony does very well already. One of my clients just > spent days re-creating doctrine's nested set capabilities. They kept > looking for ways to make it "better" for their needs. In the end they > spent dozens of man-hours creating something that is entirely inferior > to doctrine's nested set. It would have taken me 2-3 hours if they > were already in symfony. > >> The only argument I can see against using symfony is for the >> reasons I >> mentioned above. > > I'm not sure there are any rational arguments to not use symfony (or > any other competent MVC framework like Zend). Except that I get paid > way more in the long term on a project if I *don't* get them on > symfony because I have to re-create so much of what it does. :) Again, > I don't mind this. Clients that choose symfony accelerate their > product development and meet the users needs better. The problem is > proving that to management. > > Anyway, back to work. > > --Derrek > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
