Developer

Stop arguing and start prototyping

The right work culture and approach to projects can be everything for a developer.

The right work culture and approach to projects can be everything for a developer. Promises of money, fame, and fortune might get developers in the door but it probably won't keep them. Developers like to feel like they have a sense of control over a project, even if it is a small part of the project. I hate to use this word but most like to feel "empowered".

While each business and project may approach culture differently I recently stumbled upon documentation for Red Hat's Mugshot project. On the developer wiki is a set of guidelines for the culture of the project (see the guidelines below). While these particular points might not work for all projects, it's definitely a good start to think about these types of rules for a project.

In particular, I liked the idea of solving problems via prototyping instead of arguing on forum boards or over a board room the differences in development approaches or designs. Prototyping early and often can help highlight some fo the long-term design hurdles, prevent last-minute design changes and re-coding in projects, inspire those in the team who can't visualise code or speak in tech terms, and provide a more tangible map past bullet points and specs.

I'd be interested to hear how different teams in Australia approach their development culture and their approach to prototyping. Feel free to leave a comment below or e-mail me at editor @ builderau.com.

Mugshot's approach to culture:

  • Bias for Action - don't have a big argument, just prototype both ways and see!
  • Bias for Learning - real-world research, then rapid prototyping; facts over speculation, fieldwork over lone genius at a desk
  • Play - if you're obsessed with being "serious" you won't try new things and have new ideas
  • Collaboration - fan out in parallel and research; brainstorm in groups; everyone makes some prototypes; mutual respect
  • Individual Judgment - individuals are bolder than groups; collaboration need not mean democracy
  • People First - development by people, for people; not by technologies, for technologies
  • Controversy - you have to break some eggs to make an omelet
  • Failure - fail often to succeed faster. Celebrate failure as one step closer, like Edison's first zillion lightbulbs
  • Opportunity - focus on opportunity for gain, not risk of loss
  • Different - disruptive not incremental
  • Fear of Stagnation - recognizing the risks in staying the same, not only the risks of change

Editor's Picks

Free Newsletters, In your Inbox