I was musing about what is crucial to make an internal project like Bootstrap from Twitter work.
Reading the article on Twitter’s Bootstrap on A List Apart definitely gave me positive vibe. Twitter and above all its team proved that you can create cool and useful tools if you think further ahead than just pondering how you’re going to write your 20th incarnation of a sitemap link list for some project.
Yes, it takes some time and discussions between the disciplines but you can win so much time in the future if done right. Doing stuff right depends on some crucial things:
- Work interdisciplinary and as (almost) equals. It’s easy to say what you think out the whole plan yourself, but if you do that, others are not inclined to think with you. Each new idea becomes just another bump in the project instead of a good contribution to a discussion to get a better understanding of a problem. By putting your problem on the table and make team members real team members, you get a real discussion. And a better product in the end
- Make your work public. You also get a whole other situation if you know that other people (clients or the community) are keeping an eye on you. In the positive sense of the word, that is. You have to think (just like Twitter) what is really useful outside your little bubble. And you might get good feedback to make your code even better/stable/useful.
By thinking hard how to make stuff usable for the outside world, you’re instantly making a very usable and learnable tool for anyone who’s going to work at your firm.
Making open source software could also motivate people. They’re not just working hard for the company anymore, they’re also working on something that can also be useful outside of the company and the greater good. That can be the motivation to work a more on it outside work time. - Results before deadlines or budget. Ok, projects with limitless budgets aren’t realistic. But making reusable code or applications without keeping an eye on its usability or not even testing isn’t realistic either. To get quality reusable code you do not only need to write it, you have to think it out, write it and rewrite it and rewrite it. If you’re not prepared to do that, just save yourself the trouble.
- Continuous testing. Don’t wait until the very end of the project to measure its quality. You cannot remove the concrete slabs below an ill-constructed house either. Everybody has to at least check the end result of the finished component before moving on to the next target.
- Reusability is epic. Don’t kid yourself: Most of the stuff you do now has been done in the past as well. Talk with designers, programmers and developers to aim for reusability while preventing that all websites start to look the same. Getting some framework that works for everybody is everybody’s priority.
- Keep it simple. Some projects need solid plans. Others don’t. Some stuff does not have to be written out in threefold as long as the basics are known and the outer borders have been drawn. Be wary if the 5th version of the plan is mailed in PDF form to all team members, project time already gets out of hand and no real work is done yet.
