Also just wanted to mention. People say (even Fabien said) that symfony is not for small applications. I tend to disagree with this. From my experience, small applications tend to turn into big ones. If you develop what seems like a small application at first with symfony, when you need to add additional functionality later on its a snap because of symfony's structure.
The key there is never underestimate the clients ability to overcomplicate an application later on. I'd rather do the "little app" in symfony and maybe take a little longer. Even if that application is never extended, at least it always will be ready for it. On Mon, Nov 2, 2009 at 9:22 PM, Derrek <dle...@allofzero.com> wrote: > > > hehe, yeah. I think it's more likely that I will donate time and/or > money to symfony at some point. I have mostly used it on private > backend development for clients who don't care how the work gets done. > I have yet to launch any of my personal projects using it. If one of > those takes off, then you bet I'll donate to symfony. ;) > > I just realized how much of a symfony-head I sound like on here. I've > tried a lot of frameworks. I stick with symfony because it's the best > mix of flexibility while forcing you into a maintainable development > style. > > Zend was too flexible. If you didn't do everything right, you ended up > with an OO-MVC mess. Symfony keeps me on track with minimal > restrictions as a structured framework. > > *gets off the soap box* > > --Derrek > > On Nov 2, 1:15 pm, Alexandru-Emil Lupu <gang.al...@gmail.com> wrote: > > However, symfony is open source ... :) as fabien said ... no one has > thought > > to help financial sensio labs or symfony project ... > > if is so powerfull and your managers are satisfied about the product, you > > could try convince them to donate a small amount of money to symfony > project > > ... > > Unfortunatelly, my manager is not a tech person and also does not > understand > > the donation concept... he's an accountant > > Alecs > > > > > > > > > > > > On Mon, Nov 2, 2009 at 7:10 PM, Derrek <dle...@allofzero.com> wrote: > > > > > I would love to see a TCO study as well. > > > > > It's just hard to compare. One of my clients that has been resisting > > > symfony/php for a while just opted to have me build a standalone > > > module in it. The module is a reporting tool that seamlessly > > > integrates with their database. The module took a month to build and > > > exposes all of the databases tables (over 200 tables) for statistical > > > processing. I couldn't have built it without symfony + doctrine. It > > > could have taken months or even years on a non-mvc-orm platform. I > > > didn't have to write any form code (because of widgets/validators), > > > sql (because of doctrine) or handle anything but building my own > > > report logic. *and* it works on SQL server and MySQL which is huge > > > since this client is migrating from SQL to MySQL at the same time as > > > releasing this tool. > > > > > It's so powerful that the client is thinking about selling it as an > > > add-on component as their user base would not need crystal reports or > > > other reporting tools anymore. > > > > > If you factor in situations like that, symfony would pay for itself > > > dozens or hundreds of times over. > > > > > --Derrek > > > > > On Nov 2, 10:25 am, Lee Bolding <l...@leesbian.net> wrote: > > > > 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,Derrekwrote: > > > > > > >> 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 > > > > -- > > As programmers create bigger & better idiot proof programs, so the > universe > > creates bigger & better idiots! > > I am on web: http://www.alecslupu.ro/ > > I am on twitter:http://twitter.com/alecslupu > > I am on linkedIn:http://www.linkedin.com/in/alecslupu > > Tel: (+4)0748.543.798 > > > -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
