Building Better Software: It starts with a philosophy.
10 Dec 2012
The process through which software is built and shipped varies widely between companies, and even teams within any one company.
As a student of software leadership and an active participant on many development teams, I’m going to share a few thoughts on how I believe we can collectively build better software.
Follow me on Twitter: @ajordens
Small Teams, Individual Ownership.
In my opinion, teams should be no bigger than 5 people and they must be capable of owning what is built from inception to production.
Scalability comes from a focus on not repeating yourself and building tools to abstract away grunt work. Want an architecture like Netflix? You must iterate relentlessly and never settle on good enough.
We must focus on getting good at going from an initial idea or concept to implementation. Speed and efficiency come from reusing common patterns and techniques (and technologies), not reinventing the wheel.
Case in point, here’s my (current) set of preferred frameworks and tools:
- Dropwizard (for simple RESTful APIs)
- AngularJS (for client-side JS)
- Compass/SASS (for client-side CSS management)
- Fabric (for programmatic deployment)
- AWS (for relational and non-relational data stores, etc.)
Just as every carpenter carriers a hammer, every developer must aim to master a set of tools and ever-changing frameworks. What are yours?
Be Goal Oriented, not Task Focused.
Just because you broke an idea, goal or user story down into a series of tasks does not mean that you’ve captured the essence of what needs to be delivered.
All too often it’s easy to get lost in the details of crossing items off an implementation checklist and losing site of the fact that what is being built is a piece of crap. Focus on the customer and if the original breakdown is not aligned with your actual progress, adjust accordingly and talk with your team or stakeholders.
Personal rule of thumb, never go longer than a day without committing code and getting feedback from a peer, even if it’s just bouncing your progress off them for a quick sanity check. Always talk about what has already been done before discussing what will be tackled next.
A tool like JIRA, used incorrectly and without oversight, can make it easy to head off in the wrong direction. Put another way, JIRA will let you create all the sub-tasks and record as much time as you’d like against them, but it will never tell you you’re doing the right, or wrong, thing.
You don’t always get what you want.
As engineers, it can be rare to find an environment that day in and day out is going to push you to improve. I feel that we owe it to ourselves to find outlets outside of the office that offer rewarding technical challenges, be it taking Martin Odersky’s Scala course or working on a side-project.
On a personal note, I self-funded* my own 20% time last year and invested in personal experimentation. Learning to quickly take ideas from concept to implementation, and getting knee deep in Python, MongoDB, the App Store and much much more along the way.
Looking back, this was probably one of the best decisions I could have made.
* self-funded, in this case, meant taking an unpaid day off each week for a year from my regular job to focus on personal projects.
That’s it for now. Stay tuned!