Recently, I had the opportunity to build a plugin with two other developers – Pippin Williamson and Andrew Norcross.
We came up with the idea via Twitter, scoped it via email, and built it
using GitHub using its tools all prior to releasing it.
I
know – the title of this post sounds all too familiar especially given
the global economy in which we all live today. After all, many of us
work from our home offices, coffee shops, or wherever else while the
home base of our company is located elsewhere.
But this is a different type of distributed team.
First,
let’s acknowledge that when it comes to building software in the
WordPress space, we’re extremely fortunate to be able to do so by
ourselves, with a couple of friends, or within the context of a team in a
corporate environment.
Even though WordPress itself is built by a
lot of people all over the world, you don’t often see the same
experience being pulled through with themes or plugins. This isn’t to
say that it’s never done (because it is), but it appears that it’s done less so.
Now,
the purpose of this post is not to promote the aforementioned plugin,
but it’s more of a call to action for us to find more creative ways to
build publishing products with teams – namely, our “Internet friends” or
tweeps – with whom we may not have previously worked.
But there
are a few learnings that have come from this process that I think are
worth sharing for the sake of helping others get into experimenting with
developing projects with fellow tweeps.
Scope Is Key
Simply
put, locking in the scope is part of identifying the core features of
your plugin. When you first start out, it’s important to be able to succinctly state what your product is going to do.
In our case, we said:
We want to make it easy for people to identify what comments need a reply from the post’s author.
What
this does is allow you to define a grid – or a scope – through which
all potential features can be filtered. If it doesn’t fit in with the
core idea of the plugin, then it’s not fit for the first release.
That said, this feels almost like it’s a bit cliche because it should be expected for any software project: identify the scope, lock it in, and then aim for it.
But when you’re working with a group of friends on a free project, this can become increasingly easy to ignore.
Case
in point: As a single developer, how often have you thought to
yourself: “That’d be a cool feature to build!” And then, because you had
no one to really hold you accountable to build it, you were able to
achieve it.
This isn’t to say that’s wrong – it may be,
it may not be – I don’t know the specifics of your project; however, if
you’re working with a team on a project, taking time to work on
something that is outside of the scope is time wasted that can
ultimately detract from the core of the plugin. Furthermore, it can hold
up your peers’ development time while they wait for your feature to be
complete especially if there’s a dependency on your work.
Finally, if you get a group of developers together to build something for the fun of it, the project may never get done because you’ve taken the idea of “wouldn’t this be cool,” and multiplied it by however many are on your team.
The
point is that even though you’re running the project with friends,
you’ve got to scope the project lean, and scope the project early;
otherwise, you’ll never be done.
Delivery Date Matters
And
this brings us to the second point: Despite the fact that you have no
one “above you” holding you accountable to your delivery date, you still
have an obligation to yourselves, your scope, and those who may be
waiting for the product to complete development.
Granted, there’s
always the argument that can be made that since people aren’t paying,
then they have no real demand on when something should be finished;
however, if you’ve set a date, there’s a level of integrity that should
be matched when aiming to deliver your work.
To
that end, it’s important that you set a delivery date – however
arbitrary it may be – and then set milestones to make sure the pace of
development matches that date.
For example, Pippin, Andrew, and I
scoped the plugin in February and aimed to have the plugin completed in
April by the end of one of the WordCamp events. Sure, the deadline was
somewhat arbitrary, but it kept us honest not only in our own
development efforts, but it allowed us to hold one another accountable
for our own specific tasks.
This means that if I was dragging my feet, Pippin or Andrew could call me on it (of course, it works all around).
Keep It Open
Finally,
working with friends is great especially when you’re unified around the
same vision. It allows you to get more done faster since the work can
be spread across more than a single person.
But the nice thing about software is that it can
be open sourced. This means that if others are not only interested in
the project, or are bought into the vision, they can even contribute to
it.
But here’s the thing, software is inevitably going to breed two things:
Bugs
Feature Requests
Using
tools such as GitHub allows the plugin’s user base – be it users,
developers, or designers – to voice their issues and/or feature requests
in a centralized way.
Furthermore, it allows the core team to not
only assign each set of issues to their own milestones, but it allows
for other contributors who are also brought into the vision know exactly how they can contribute. There’s no guesswork. There’s no “hey, maybe we could do this!”
Instead,
there’s a list of issues and requests that are needed (permitting the
list is kept up to date) so that contributors know they are ultimately
improving the product – not just blindly adding something because they
think it would look good.
Of course, this isn’t limited to GitHub:
Whatever source control system and ticket system you opt to use, make
sure it’s something that makes it easy for others to interact and others
to view outstanding issues. The last thing contributors need is
yet-another-hurdle for contributing to your project.
Conclusion
So there you have it: Three points to working on products with a distributed team outside of the typical organized environment.
Simply
put, make sure that you scope your project, stick to your delivery
date, and allow others to contribute who are interested. By doing this,
you’re making it easy not only for your current team, but your future
contributors to improve the product.
Finally, I’ve avoided
discussing the plugin that Pippin, Andrew, and I built specifically
because I wanted this post to be about the process, not the product;
however, now that we’ve covered the former, you can find the latter here on GitHub. If you’re interested, feel free to leave us issues, notes, or even pull requests!
Hi folks I’m back with another cool blogger template Portfolio. This time it is a blogger gallery template.
Portfolio
is a gallery type blogger template with never before seen features in
Google Blogger. Besides its features it is a simple yet classic blogger
template with advanced functionality. It
is actually a premium template. So this time if you really like this
template then you will have to buy it before using. It is priced at $20
and all the necessary instructions are provided along with the download.