Allow me to coin a word:
hack·le /ˈhækəl/, noun - A group of 2 or more people working with little or no coordination on one or more software projects: Apache is “a patchy” web server built with patches submitted by a large, distributed hackle from around the world.
Yes, there are already enough words in the English language. Yes, this is an extremely cheap and trite way to introduce a post. But tough titty. I need a word for groups working on the same project, and ‘team’ won’t cut it. Why, you probably aren’t asking? Because people working on the same software project aren’t necessarily working as a team.
Teams are especially rare in the open source world where developers are working on their own time and dime, and no one is tracking- much less optimizing- team productivity; everyone’s too busy trying to get their pet project in to the next release. What should we call all of these loosely associated people who happen to be hacking on the same software?
How bout a ‘hackle’?
But most of these hackles- FLOSS hackles included- can organize themselves to significantly improve their overall productivity and the quality of the software they are building. With a little time, effort and possibly expense, these hackles can become a bona fied team.
Don’t think I’m trying to sell you some agile process snake oil, because I’m not. I don’t believe that Scrum, eXtreme Programming, or Unified Process are a prescription for success in any and all software projects out there. In fact, you name a methodology, and I don’t believe in it. But I do believe that there are some valuable practices that pop up over and again in these methodologies. And I do believe that there is some methodology that can help you herd your hackle. More on that below.
Pair programming. Daily status meetings. A ‘product backlog’. Test driven development. Various and sundry UML diagrams. All are common solutions to common problems that hackles are likely to face sooner or later. We know methodologies are nothing more than collections of practices that are supposed to improve hackle productivity. Methodologies that are nothing more than a cocktail of established practices have become common hackle-hold names. These are tried and true methodologies that worked well for the particular hackle/project that some process pusher with a book deal has documented in gruesome detail. But these methodologies won’t necessarily work for the unique challenges you’re likely to face in building your unique software solution.
Don’t worry. You don’t have to start putting together a process from scratch. These cute-name methodologies aren’t all bad. Take a good look at each of them; you’re sure to notice a lot of common solutions to common problems. In fact, you might draw an apt analogy to the programming patterns you (should?) use constantly in your code. Fact is, you wouldn’t be the first to reach this epiphany: http://www.ambysoft.com/processPatternsPage.html.
You’d never adopt a system design whole-hog to sorta/kinda address your users’ needs, yet lots of us try to implement the agile flavor of the day with no thought given to how it fits with your hackle and with whatever it is you’re trying to build. Chances are you’ve already run in to an eager beaver project manager that couldn’t wait to throw everyone in to a bullpen just because XP says so. There must be a better way to get your agile on.
There is. As someone who has implement methodologies in many environments with very different climates, I can tell you that there is a constant temptation to tweek the process you’ve picked whenever one of the prescribed practices doesn’t jive with your hackle. With each iteration- if you’re doing iterations- corners are cut and new practices are added for the sake of practically and productivity. No matter what, you’ll end up with a custom process. Maybe it’s time for us to stop resisting common sense and start designing the best-fit process for our respective hackles from the ground up in terms of smaller building blocks called- say- process patterns. Patterns like iterative development, for example.
So, now that I’ve firmly established ‘hackle’ in the lexicon of software development, let’s use it to define another word that should take a good seat in your vocabulary:
Process Patterns, noun - Common solutions for common organizational problems that are used to build bespoke processes to enable hackles solve unique- and substantially more interesting- problems.