Tag: Open Source Project Management (Page 1 of 2)

Project Guardrails: Writing To Production

June 9, 2017 / Tom / 0 Comments

In the past few articles, I’ve talked about a couple of things (saved for actually writing to production) that help to run a successful project:

The dangers in “design by committee,”
Considerations for provisioning an environment.

The last thing I want to address the learning I’ve experienced thus far is about maintaining the proverbial keys to the kingdom of writing to production and why that matters.

Project Guardrails: Provisioning Environments

June 8, 2017 / Tom / 0 Comments

This series of brief articles is made up of a few things I’ve learned over the last few years of running projects based in the area in which we (assuming you’re reading this coming from the same part of the industry I do 🙂) work.

If you’re just stumbling across this, the series is covering some factors that are important for a project:

There should be no “design by committee.“
No one else other that the core development team should be able to provision development, staging, and production.
No one should be able to write to production but the development team (and even then, there should be a deployment process).

I don’t really like making hard and fast rules like this namely because things change over time either by necessity or by more experience. This is why I like “guidelines.”

But at the time of this writing, these are the things I see playing out.

Project Guardrails: Design By Committee

June 7, 2017 / Tom / 0 Comments

When you’re contracted to build a solution for others – primarily on the web since that’s the area in which I work – I think that there are a number of factors that are important for a project:

There should be no “design by committee.”
No one else other that the core development team should be able to provision development, staging, and production.
No one should be able to write to production but the development team (and even then, there should be a deployment process).

I’m always hesitant to make statements like this as they come off as dogmatic, but I find that the longer I work in this industry, the more I think these three rules are important.

Or perhaps they are really just guidelines. After all, there are shots called before we actually get stuff done.

Regardless of if they are more suggestions or rules doesn’t really matter. There are reasons that we all arrive at the conclusions that we do, right? And so over the next few posts (rather than one long post), I’ll share the reasons I’ve found these three rules to be important.

There’s No Perfect Size for a Feedback Loop

April 24, 2017 / Tom / 0 Comments

The more I drafted this post, the more it felt like I should be writing some type of TL;DR for certain people who read this. So, in an effort to save time, here it is:

I’m writing this for those who are new to self-employment, project management, or generally have less experience than those who are asking “Why are you writing this?” Ultimately, it’s something that most of us learn at some point in this industry, but if we can help one another short cut it sooner rather than later, we all benefit.

If you’re still interested after reading the note above, then I assume you’re looking to get better at this aspect of communication. Which is good, because so am I 😏, and using a small feedback loop is one way in which I’ve found to do that.

Every industry has a bit of their own jargon and many of us laugh about it, yet we all continue to use it when in a professional setting. We’re funny that way.

Anyway, in our industry, one of the phrases that we use a lot – myself included – is “feedback loop.” The first time I ever came across the phrase was with regard to feedback from amplifiers. It had nothing to do with software. Nonetheless, in what we do we generally use it to refer to it as:

sending a request, comment, or general piece of information to a customer,
receiving a response from the customer regarding said information.

And for those who aren’t used to the idea (because there are those who do “big bang releases” which I’ll talk about in a minute), feedback loops are usually considered to be small or large.

The longer I’ve worked in software, the more I always aim for A small feedback loop no matter what.

Product Demos via Screencasts (Go for Video!)

October 20, 2016 / Tom / 0 Comments

If you’re working remotely or as part of a distributed team that is building a project for clients (versus something internal), having a way to give product demos is something that can be incredibly helpful.

I know, I know: The term “product demos” sounds like something you give after a product is complete. But when you’re chatting with a client through whatever means you’ve chosen, and you’re unable to pinpoint a bug, I’ve found that it helps to create a product demo and send it over to them.

Naturally, it’s not a good idea just to send a video and be the stereotypical developer who says:

Hey, it works on my machine. Must be yours.

First, that’s a terrible and counterproductive attitude. Secondly, it’s disrespectful to the client because you’re in the business of solving their problems. Not creating them or complicating them.

So how can you make their lives easier (as well as your own)?