I’ve been at Huddle for a year now, and since joining I’ve not only dramatically increased my learning curve, but I’ve become a much better all round developer, and so has everyone else in the team.

So how does Huddle vary from other jobs I’ve had, and what are we doing differently? Here are a few reasons.

Agile, Properly Done

Many companies think they’re doing “Agile” but in reality they’re not. Teams aren’t actually complete teams, backlogs don’t exists, there’s no concept of an internal customer, developers and testers are separate etc… So what do we do at Huddle?

  • Learn – there’s always boring work to be done, but there’s plenty of interesting work… or boring work that can be made interesting. Defining architecture, using MVC, REST, JQuery etc… Keeping your team interested is important. Just fixing bugs every day or making text changes is a quick way to reduce output and demorialise a team. We always keep people thinking and trying new things.
  • Listen – developers/testers etc… are as much a part of the business as anyone else, and often have some very good ideas. We have an internal customer that listens to our ideas and advice, and values our opinions when we push them. This not only creates a better product, but increases morale and gives a sense of ownership to everyone in the team.
  • Adapt – we use a mixture of Scrum and XP, and most importantly over the months we’ve adapted it to our needs. And we continue to adapt it. Things such as daily 20 minute estimation sessions to keep the backlog up to date and make planning shorter, and modified morning stand ups.
  • Reflect – Related to the above point, we have good, bad, do different as part of our retrospectives. Three simple categories. At the end of each iteration we sit down and go over how it went, and come up with tasks to help improve the next iteration. This is also a good time for team members to show happiness, or vent frustration (rather than bottle it up), and present new ideas.
  • Discuss – we don’t have a strict hierarchy of roles within the team. Everyone is treated as an equal, and is encouraged to contribute an ideas and discuss problems. For example we recently looked at Microsoft’s MVC and OpenRasta, did a spike for each, and then a demo to show the two working. After we discuss and all try to come to an agreement as to which one we’ll use. We have regualar architecture meetings for all developers where we discuss new technology and changes.
  • Team work

    A developer should be more than someone that writes code. Here are some other important factors which will round you as a developer:

    • Testing – not everyone likes doing it, but I believe developers always should. As long as you’re not testing your own work. It firstly helps stop QA bottlenecks, and secondly you learn more about the product, especially from a different perspective. If anyone knows your product well it is the QA team. Also developers can often bring a different perspective to testing and find bugs the QA team may otherwise not have known about.
    • Ideas – developers should constantly come up with ideas, and be writing them up and passing them to the product owner/manager. You can “pitch” for time to work on ideas and develop prototypes before an idea becomes a story. Ideas shouldn’t just be related to the product, they can be upgrades, refactoring ideas, changes to the internal environment etc…
    • Pair Programming – for a lot of stories, at least for portions of them, it’s good to pair program. It helps you learn a part of the code base you may not know, but someone else does. You’ll also be surprised how much better the quality of code is, if you have someone watching over your shoulder pointing out suggestions and improvements. The same goes for bugs, things you may miss, but a second pair of eyes won’t. It’s also a more social way to work (if you like the person and the banter is good), and helps gel the team.
    • Code Reviews – every story written should be code reviewed, even bugs (the bigger ones) as we all write crap code every so often. A code review should only take 10 minutes or so, and just involves another developer being given a walk-through of your work. This helps iron out any poor code, style violations, architecture issues, uncertainties etc…
    • Different Languages and Operating Systems – at Huddle I primarily use C#, but there are plenty of other languages we use that I can improve on. HTML and CSS for example. Many serverside developers will claim they can write properly used, well formed HTML and CSS but they often can’t. We also have JavaScript (jQuery) and PHP and use Linux (Apache, Samba, SSH) servers. Lots of things for developers to learn off each other, and expand their their knowledge. This also stops dependencies and problems should someone leave the company, or be on holiday etc…

    So there are some of the things we implement as part of our development process. None of them are complicated or difficult to implement, and they all offer benefits. I’ve worked in a few places (no names) where none of the above are done, which in retrospect is probably why I don’t work there anymore. I shudder when thinking back to the “old” development days at previous companies.

    If you’re reading this and thinking your company will never implement some of the points, firstly, you never know unless you start making suggestions or at least ask. Often you have to take the initiative and make your workplace work for you. Secondly, if it falls on deaf ears, just kick and scream until someone notices you, because eventually they will (or you’ll end up leaving after months/years of frustration).

    A Few Other Things

    How to become a better programmer? Here’s a quick list of other things that can help you become a better programmer(at least a happier one), but are probably less likely to get implemented.

    • A beer fridge and beer o’ clock (we currently do this, awesome)
    • Bean bags
    • Chairs and stools with wheels
    • Multiple monitors, at least 2
    • Computer club, basically Counterstrike after hours
    • A large flat screen for sporting events (Olympics, World Cup, Wimbledon etc…)
    • A build noise (for when the build breaks)
    • Background music while you work

Colin Grossman


Request a Demo

© 2006 - 2019. All Rights Reserved.