Four developers, four laptops, one table, one projector and a whole lot of learning. Our team, the inappropriately named ‘League of Extraordinary Developers’, made the decision to break away from the rest of the labs organization to run a process experiment for two weeks. The goal was to figure out how much process, direction and guidance a team of developers really needs to build good software. Our motto was simple:
Get Shit Done
And yes, we have the poster. The guiding principles for getting shit done were as follows: production ready, user validation, UI first, test, code review and do not add it until you need it.
The tool of choice.
Ember is often described by people who hate it as lots of upfront learning and a lot of opinions. Additionally Ember is often described by people who love it as lots of opinions. I’ve been working in the land of JavaScript for about five years now. The coupling of ember and the ember-cli has been magical. I started out with writing web applications in pure jQuery. I love jQuery and all that it brings in terms of cross browsers compatibility and simplicity. I do not however enjoy callback hell nor do I enjoy managing state between the UI and an underlying data model. My next library was Knockout.js. I have a great respect for Steve Sanderson and the entire Knockout community, so much that I credit much of what I am as a developer today to that library. The binding is simple, powerful and provides a decent way to build single page applications. All this being said, Ember is a different beast. It is not a library, it is a full framework. Ember provides the entire application life cycle. My biggest worry is that the application actually does what the client wants. This is an issue well outside of the scope of this article but a deeply troubling problem in the world of software.
Opinions are great. Share them. Enforce them.
Ember all but eliminated one of the biggest issues that I deal with in JavaScript programming. Opinions. A difference in opinions has created entire frameworks. In Ember, for the most part, there is a correct way to do something. This baked in opinion leads to less arguments when a solution is largely based on personal preference. Spending time debating takes away from solving business needs and retards the development process. This coupled with the first of five concept has allowed us to make decisions at a lightning pace.
Convention over configuration in practice.
The Ember team has always preached convention over configuration. The benefits of this pillar are hard to spot as a lone developer who has written every line of code in a project. It surfaces when you have a team of people working in a large code base. Everything is where you would expect it. Weirdly useful huh? Who would have thunk it. If you do not know the convention you can always look it up. In our project we decided that the pod structure was best for us. This decision even further helps to put properly named files in the proper location. There is no debate. It is what it is, get back to bringing value to the business.
Measure twice. Cut once.
Who ever thought an idiom so grounded in the physical word could fit in the digital world? Discuss what you want to write. Discuss how you want to write it. Code. Review. This process may be slow (it is really not that slow) but without a doubt it is amazingly effective. Everyone has a say in what was written and by the time it is ready to check in the code has been approved by the whole team. We found that this process helps to break personal attachment to code. The effort it took to create that code is dispersed across the team. The weight of building the application is shared with the team.
Our conclusions.
- If you are using Ember, use the ember-cli with pods
- Pair programming can help write quality, understandable code if executed well
- Ember can help remove opinion from the conversation by injecting a well thought out and ready to use opinion
- Do not force your tools to work outside of their comfort zone. If it is hard to do, you may be doing it wrong
- Option 0: do nothing. Not always the best option, but an option none the less
- Fist of five is an outrageously effective way to keep on topic and make small decisions efficiently
- Only make decisions when you need to. If the team is not ready to make a decision, write it down and come back to it when you are ready, do not force it
- Avoid the big reveal. Rapidly presenting to the business what the team is working on provides a simple feedback mechanism. If the product is not going in the direction the businsess has envisioned they can help correct course early in the process
- This process is not for everyone. Working off conclusions five and seven, if your process is working, you do not have to bring in a different process just because it worked for somebody else
