One of the single most important factors in choosing a framework is your team, since no developer stands alone (okay, some do, but most don’t). Experience, habits, and opinions (weak or strong) – all come into play when adopting a framework. If you’re helping your team adopt a new framework, you have to be very honest with yourself on these factors.
If you have a generalist team where you don’t have 100% coverage in a new language you want to adopt, you have to consider whether or not your team can re-tool and re-skill.
The great thing about developers is that we generally re-tool and learn new things all the time, but some habits die hard. Some developers really hate being forced to respect whitespace. Some think any project done in anything but language XYZ is doomed to fail (those aren’t great developers to have around anyway, but I digress). Be aware of those biases, and it’ll help smooth the way for the best eventual framework choice.
If you’re in the lead position, you can work with your team to ask questions about the right framework for the team. Get feedback in multiple ways — a meeting (bribe them with lunch), an anonymous survey, and so on. Truth can come from many places!
It can help if you set aside time for a “hack day” or build a prototype story into your sprint. If you have a few candidates for frameworks, do your own spin-off of TodoMVC and build something small, but in the direction of your eventual project. How do your team members like it? Do they see a simple path to testing and deploying it? Building something small can surface those answers.
If you aren’t a lead, and there’s one clear winner you want to advocate for, modify your strategy appropriately to help your champion get adopted.
One option is that you can put together a lunchtime talk, going over a demo application (that you’ve likely conveniently already done to test out the framework yourself) and you can run through why it’s the best choice with your team.
No matter how you shake it out, one commonality arises – when you’re choosing a framework, at some point you’ll be interacting with the team to make the decision. Try a hack day, try a visit to a user group, but try something to help to get your team on board – better that than to have your team hate the chosen framework.
Be sure to look at resources on frameworks that you can find in Safari Books Online.
Not a subscriber? Sign up for a free trial.
Safari Books Online has the content you need
|Web Anatomy: Interaction Design Frameworks that Work cites examples from both the successful and not-so-successful, breaking down the elements that comprise several common interactive web systems, discuss implementation considerations, offer examples of innovations based on these standards, reveal how frameworks work hand in hand with patterns and components, and show you how to integrate frameworks into your process.|
|Head First Design Patterns covers the best practices and experience of others, so that you can spend your time on…something else. Something more challenging. Something more complex. Something more fun. You want to learn about the patterns that matter–why to use them, when to use them, how to use them (and when NOT to use them). But you don’t just want to see how patterns look in a book, you want to know how they look “in the wild”. In their native environment. In other words, in real world applications. This book is for you.|
About the author