Frameworks Development Teams Pragmatism, by Orguz Demirkapi

One of the main reasons to use a framework is to optimize development. Having a defined work flow offers a clear path for developers to take, making a standard for all developers to follow. When you want to maintain an application it’s easier for the next developer to pick up (or for you to pick up later) you’ll be able to follow your code. This allows hiring anyone who knows that framework where they can jump right in and follow what’s there. With frameworks you can create work separation to split up the work in a logical way. He mentioned Secretagents.com where over 100 developers created a site in 24 by all being able to work without relying on other’s code. The downside of all this is that you invest a lot of time in learning a framework. Although some frameworks are more straightforward that others, it’ll take time and money to learn. Also some sites don’t need frameworks. For a 5 page static site it’s going to be overkill. Once you have a development team in place, you can focus on the models, the environment and training (amongst many other things). Be pragmatic though. Be careful of your budget, time; be transparent in your work and be honest to yourself and your team about the project. Using a framework makes your methods transparent to your company and clients. Creating good software depends on good analysis. With requirements gathered you can make an educated choice on which framework is the best fit for your project. If you go into a project saying that you’ll use fusebox or model glue, and learn that the page is actually only a few pages you’ll have wasted some time that could’ve been spent gather requirements or prototyping. Don’t get ahead of yourself if the client is being slow; just wait until you have what you need before moving forward. Just as important is choosing a framework you actually know. If the developers have never used a framework, it’s probably not a good idea to start off creating a huge enterprise application in it; at least not without some training and maybe a small project or two under their belts. Ideally this should be an internal application that can be thrown away. Project managers should reject using a new solution no one has worked with. Instead insist on learning more about it first; creating some samples, maybe giving a presentation to the other developers on something.