Signs That You’ve Outgrown Github

Github is WONDERFUL. I have used it for a long time now, and it’s great. It’s easy to get started, and especially for one-person projects, it really helps keep things organized.

But as you start to add team members, competing priorities, and overall complexity, something changes. In lots of little ways, Github starts to show that it just wasn’t designed for long-haul software projects, with many team members and a non-trivial workflow.

Here are some of the things you might already be dealing with:

  • You’ve created so many labels that you’ve written a wiki page to tell everyone how to use them (and how NOT to use them!)
  • Maybe you want to keep track of bugs and support tickets separately.
  • Perhaps you don’t think that developers should be able to close a ticket just by committing code.
  • Maybe you’re tired of having to search in Google Docs, Basecamp, Slack and Github to find where you talked about that new feature.
  • Could be that you need to manage the relationships between tasks that depend on or block each other.

I’ll do a blog post for each of these topics. This week, let’s start with the first one — labels.

Labels

Labels are quick and easy to use, offer a lot of flexibility and require virtually no setup or configuration overhead. The default labels in Github look something like this:

Those are probably fine for 98% of new Github projects. Over time, however, most teams will expand on the list of tags to include different values than the default list, and even different types of data. Adding categories for basics like type, priority, and status makes a lot of sense when you’re managing a backlog. But all of those new values expands the list beyond what you can keep straight in your head.

So, how can teams use complex label sets reliably? One common convention is to use a prefix word to identify the group to which each label belongs (courtesy of Dave Lunny):

This approach has the benefit of including the type of label as part of the label text, so you won’t be confused between “Status: Test”, “Environment: Test”, and “Task Type: Test”. Visually, the various colors can be used to show differences in the specific values, like production vs non-production, or high priority vs lower priority.

The downside is that when viewed across label types, the different colors are confusing and even downright jarring. Instead of quick visual signals based on color, you actually have to read each label value. It’s bad enough when looking at a single task, but when browsing a list of tasks, it can be a hot mess.

Another approach is to use similar colors for grouping. Here’s an example (from robinpowered.com):

While it’s much easier on the eyes, you no longer have the label type included with the label value. Also, this particular set of labels combines and separates a lot of values in ways you won’t appreciate later — for example, why is the production label in “Problems” and not “Environment”? There’s likely information on a wiki page somewhere, explaining that you don’t choose anything from “Environment” when it’s a production issue, right?

This next example isn’t really an example at all, but a cautionary tale. Imagine walking into your first day with these guys:

This isn’t someone’s drug-addled fantasty project, either — it’s servo, a very active and popular project on Github.

Tools For Your Tools

In response to this widespread need, there are actually tools (like git-labelmaker) dedicated to helping Github users automate the creation and management of complex sets of labels, using different naming conventions, color schemes and labeling styles. Which is very cool — except that it seems like an awful lot of work to go through, doesn’t it? If someone has created a tool to help you use another tool, maybe it’s the wrong tool.

Tag/label functionality was never designed for complex values or workflow.

A Right-Sized Solution

Instead of a mashup of various labels, organized by a prefix word or a color scheme, consider this layout (with a few additions that are, IMO, obvious):

Separating these various concerns also allows you the flexibility to require some fields when a task is created, and wait for the right step in your workflow for others. Instead of manually enforcing your task management process, you can allow your tool to do it for you.

One last benefit — if you’re using separate fields instead of specific tag values, then changing the name of the field or the values over time won’t break old data. The new field name or value(s) will be reflected in older tasks automatically.

If your tools are preventing you from improving your process, maybe it’s time to improve your tools.

Come back soon for another sign that you might have outgrown Github — next time, we’ll talk about Github’s one-dimensional task tracking.

Come try GForge Next for simple, comprehensive and elegant collaboration.

GForge v6.4.3 Released

Today we are happy to announce the immediate availability of GForge Advanced Server v6.4.3.  Other than being a bug fix release, this will likely be our last update to the 6.x series as we intend to ship GForgeNEXT later this year.

Important note: For anyone using GForge under the default license, which lets you run GForge AS free with up to 15 users without support, this number has been reduced to 5 users. Contact us at feedback@gforgegroup.com if you have any questions about this change.

Download GForge Advanced Server v6.4.3 Now!

New Features in GForge v6.4.3

  • Docman – Prior to this release, when browsing files in docman the link to the file pointed to the last version which had the version hardcoded as part of the URL. We now have use a URL that removes this hardcoded reference which means if you share the URL to the current version you will always get the latest version regardless of how many new versions have been added.  You can still access the direct link to old version through the right-click menu.
  • Project Export/Import – There were a number of issues preventing the export of a project from being imported into another GForge instance. You can now port projects between GForge instances provided both are running 6.4.3.
  • Licensing – Site administrators will receive warnings when they are approaching the maximum number of users allowed on their license.  Additionally we have given site administrators the ability to deactivate users in the event the hit that limit. Prior to this release when the system exceeded the maximum number of licensed use the system would give all users an error message.

The Gory Details

GForge v6.4.3 includes a number of bug fixes and security updates. For the full details of this release, please have a look at the Complete GForge v6.4.3 ChangeLog

Download GForge Advanced Server v6.4.3 Now!

How Many Project Tools Do You Really Need?

In my last post, I talked about some criteria for choosing between all-in-one or best-in-breed tools. Now, I’ll apply those criteria to our product space, and try to show why a unified team collaboration tool makes more sense than what you might be living with now.

So, let’s imagine that you’re looking to solve the following problem: How can we get everyone rowing in the same direction?

By “everyone,” we mean executives, product owner(s), designers, development staff, customer service, maybe even customers themselves.

And by “rowing,” we’re talking about all of the things it takes to get your product to the customer — things like planning, design, coding, marketing, testing and support.

The Accidental Integrator

The worst-case scenario is also the most common — each discipline area adopts whatever tools appeal to them.

NB: This is a simplified version of actual events from a previous job. The details have not been exaggerated, and the people involved were otherwise very capable, smart, and successful.

  • The Product Owners all decide to use Trello, and thus force it on the development staff.
  • The designers prefer Basecamp, where they can organize screenshots for the various user stories they’re working on. This means that the Product Owner has to look there as well, and so do the developers, and possibly also the customers.
  • The developers decide on Github, since it’s easy to start and Git is pretty awesome.
  • Customer Support starts a wiki, so they can get all of their procedures and help scripts in one place.
  • They already use FogBugz for tracking customer issues, and neither Trello nor Github has the features they need. This means that the Product Owner and developers have to look in FogBugz almost every day, as they respond to problems reported by customers.
  • The executive staff needs all of the above to keep a handle on what’s happening where. They also create and manage a couple of spreadsheets in Google Drive, to keep summary data for the various projects that are in process, and to prioritize upcoming work.

Here’s what that set of tools ends up looking like:

Pretty, pretty arrows.

Of course, some of these tools can be tied together with vendor-supplied integrations, web hooks, or some simple scripting. Adding these integration points might make things more convenient for users, but it doesn’t change the overall picture:

Now with 20% more arrows!

Inevitably, some amount of developer time each month (or week) will now be spent troubleshooting why x is no longer taking to y, and fixing it. People also regularly forget which password goes to which system, and need resets on a recurring basis. [Ed. This happens to me ALL THE TIME.]

Regardless of how good those integrations are, everyone still has to search across two or three or more tools to find what they’re looking for.

Each tool you add is another silo of data and process, and more friction in the overall workflow.

A (Kinda) Integrated Solution

Many teams opt for the Atlassian/Microsoft/IBM approach — buying a set of tools from the same company, with the promise of tighter integration. It’s sold as an all-in-one solution, in as much as you’re buying from one vendor. And for the most part, that’s true — until it’s not.

Tool suites like these do a much better job at tying related data together — build status can show up in the related tasks, support tickets can reference wiki pages, chat can become your company’s heartbeat. All of those capabilities help to decrease friction, distribute knowledge, and keep the entire organization plugged in to the right priorities.

Oh, that’s much simpler. (source: ClearVision)

But they’re still separate tools. You still have to flip from one app to another to search, get the details, or make updates. Each tool is still deployed and managed in separate software versions, which (sometimes) fall out of compatibility with each other. And don’t forget that you’re still going to pay licensing and maintenance for each tool. Even at a bundled rate, you’re probably getting soaked.

Half-way integrated is better than the patchwork quilt approach, but it still creates implicit silos of data, and introduces other hidden costs. It’s like being half-way delicious.

The Whole Enchilada

Speaking of delicious, what happens when you *actually* integrate tasks, wiki, chat, releases, documents, source code, support, and continuous delivery? If you could get all of these chunks of functionality in a single system, how would it affect your experience and productivity?

Isn’t that so much simpler?

There are some big benefits:

  • A seamless experience for managers, development staff, creatives, support and even customers to get involved in.
  • A single source of truth for what’s important, what’s done, and what’s next.
  • One place for your institutional knowledge to live on. On-boarding becomes easy. Hard-won company wisdom doesn’t disappear when someone leaves or changes roles.
  • One search box that is deeply connected to all of your projects, source code, documents, information, tasks and discussions. Find a specific key word or error code no matter where it’s hiding.

There are lots of situations where best-of-breed thinking makes sense. In areas where a specific tool improves your productivity, saves money, or just makes work more fun, it can be worth it. If the need you’re filling isn’t central to your business, then it’s not a huge risk to try (and maybe abandon) something new. But that’s not what we’re talking about here.

The way your team organizes and works together is possibly the most important and valuable part of your entire business. Trying to run things using a patchwork quilt of point solutions might seem cool at first, but it’s probably not where you want your team spending their time.

That’s why we built GForge. Because we do what you do every day, and we think it should be easier.

Come try GForge Next, and let us know what you think.

Note: My editor wanted me to include email as part of this discussion, but it added way too much to the article. GForge does some great things with email, and I will publish something soon to show how and why.

The Same Old, Brand-New Argument: All-In-One or Best-Of-Breed?

Introduction

For at least the past twenty years, IT folks have been faced with the same basic problem when choosing whether and which products to adopt. The term “Best of Breed” is commonly used to talk about products that offer high quality in a narrow set of features. “All in One” products, on the other hand, combine features that may cross business process or technical boundaries.

Different vendors have very different views on whether customers need a bunch of features integrated in a single product, or whether they would rather manage a set for more focused products that they (or someone else) can stitch together.

What’s the right way to go? The answer is, of course, “it depends” — and while this may be accurate, it’s not very helpful without some practical criteria to apply.

The Trade-Offs

Learn To Let Go

First things first — as a customer, buying someone else’s product means buying into their approach, their decisions, and their limitations. You’re almost certainly not going to get *exactly* what you want. Then again, you won’t be building and maintaining your own code, spending money on adding features, and your development staff can be off chasing your *real* business goals.

Look at the Big Picture

Another big trade-off involves the *rest* of your business technology. How does your current need fit in with the rest of your business systems? If you can cover more business requirements with one product, it means fewer integration points. If your requirements are very complex or specific, it might be worth the extra dependency to go after a best-of-breed tool in a given area.

Watch the Uptime

Lastly, consider outages and support. It’s inevitable that you’ll depend on your vendor(s) to come through for you when something goes wrong. Make sure you have a well-defined level of service with each vendor.

Outages can and will occur, and they affect your business continuity. Having a set of smaller, independent services from different vendors might seem like a good hedge against downtime, but in reality more moving parts *always* means a higher chance of failure. If four out of five systems are up, it doesn’t mean you have 80% functionality — interdependency usually drives that number down pretty quickly as you add components.

What’s Right for You?

With those trade-offs in mind, let’s go through a few questions that you can apply to your own situation, to help identify where you might find the most value:

1. How Big (Small) Is Your Scope?

If your needs are pretty narrow (e.g., file storage, web analytics, payment processing), then it’s likely to be well-covered by a best-in-breed solution. If you need lots of features, or a lot of complexity within them (think workflow, document management, billing or accounting), then an integrated option will offer less difficulty to get up and running, even if it has some limitations you don’t love.

2. How Much DIY Can You Handle?

This one is pretty simple — the more pieces you add to your quilt, the more stitching you’ll need to do. For example, you’ll need to keep your list of customers updated between CRM and project management, or maybe get build status in your work chat.

Nowadays, it’s very typical for applications to offer an API right out of the box. It’s also pretty common to have some integrations baked into tools — fill in a field or two, check the “Enabled” box and it’s connected. But the ease of initial adoption can misrepresent the ongoing costs to keep things the way you want them. Here are some examples:

  • Documented APIs are typically stable and reliable, but your custom integration with an API can become fragile over time, as your needs become more complex.
  • Built-in integrations provided between vendors (especially “web hook” type integrations) are always vulnerable to compatibility issues between the vendors, as they add (and retire) features over time.
  • Troubleshooting problems between multiple vendors is not for the faint-of-heart — you will often find yourself stuck in the middle, trying to prove that you have a problem they can solve.

If you’re a completely bootstrapped startup, where you have more time than money, it might make sense to invest that time into getting the tools you want tied together. As your organization grows, however, the balance between time and money often changes, and you’ll need to re-evaluate some of those early decisions.

3. Who Are You Getting Involved With?

Regardless of which way you go, you’ll want to know some things about your vendor(s) before you sign on. Here are a few starters:

  • First and foremost, are they going to disappear one random evening, with all your data?
  • How long have they been around?
  • How do they deal with customers during the sales cycle? The support cycle?
  • Do they solicit/accept/ignore requests from their customer base? Are they responsive to requests?
  • What levels of support (free or paid) are available? Do they promise a specific level of service?
  • Do you know anyone else who is a customer? What do they think?

Depending on your size and level of formality, these questions may become much more important. Newer, smaller, bootstrapped companies may care a lot more about what they can get now, and less about who’s answering the phone at 3AM. Organizations that have to answer to customers, boards of directors, investors or regulatory authorities might have an entirely different view. Uptime becomes much more important once you have paying customers, and people relying on your services.

4. What Will You Need Next Year? In Three Years?

If you’re a new company, patronizing another new company can seem like a great idea. Finding a focused vendor to partner and grow with can be a great fringe benefit — unless they go out of business or pivot away from what you need. Regardless of how good a relationship is at the beginning, it’s important to keep in mind how you’ll get out if and when it’s time to move on.

Some services are easier to change than others, like payment processing or CDN — you can even use two vendors concurrently and make a soft switchover. For other tools, like bug tracking, CRM, or internal tooling (e.g., database, message queue, web platform), changing vendors can take time, attention and planning away from your more strategic goals. All of those distractions cost opportunities, sales, and revenue.

But that’s not even the worst-case scenario. Instead, many teams will continue using tools that don’t support them strategically, struggling along with more and more string and duct tape around a core that is no longer suited to them. This is a quiet, passive killer of your team’s momentum and ability to innovate — especially if certain tools or systems become off-limits for discussions about improvement.

In general, I try to buy software and services the way that parents buy clothes for their kids. Sure, they’re a little too big at first, but if you choose wisely, you’ll find something you can grow into. Maybe even something you never outgrow.

If you’re looking for a task/code/team collaboration tool that you’ll never outgrow, come check out GForge Next: https://next.gforge.com

The Weekly Forge: 10/07/2016

The biggest development this past week is work on GForge AS v6.4.3 has started and we anticipate having it available for current customers by the end of this year.  Obviously we’ll continue work on GForgeNEXT which is accurately reflected in the highlight from last week below:

  1. Git Server Side Merges – Right now server side merges work between any two branches except when the destination branch is master. Turns out the is a bug with Git itself and we already have a patch from the Git development team and we’ll continue testing that out.
  2. Continuous Integration – We’ve begun designing the mocks required for building a Continuous Integration dashboard for all GForgeNEXT projects using Jenkins. This will complete our vision of making the integration between GForgeNEXT and CI systems tighter which reflects how integral they are to software teams.
  3. GForgeNEXT iOS – The first view for the GForgeNEXT iOS app has been stubbed out and work will continue over the coming months.
  4. Dependency Management – When a ticket has predecessors (i.e. blocking dependents) when those tickets are taken care of GForgeNEXT will notify the assignee and submitter of the ticket that work can begin on that ticket.  Those notifications will happen with growls which are also sent via push notifications via Adroid/iOS application. This is a big step towards helping PMs and project leads with automated dependency management.
  5. Improved Link Handling in Docman – Currently in 6.4.2 and prior the links to documents in docman explicitly ping to the most current version (i.e. version 7). The problem is if you email that or include it in a ticket or wiki entry that version may eventually be replaced with newer ones.  We’ve made it so the links in docman will always give users the most current version.  Don’t worry you can still explicitly send the link to a specific version of a file if you want.
  6. A handful of bug fixes for v6.4.3 are being actively worked on.

GForgeNEXT Update for 9/30/2016

Beginning this month our team will be giving weekly updates on the GForgeNEXT development.  This won’t be the painful details just the good stuff boiled down to a few talking points. We should be clear that GForgeNEXT is in open beta at https://next.gforge.com so sign-up today! Before we give our first update we’d like to share what exactly where GForgeNEXT sits.

  1. Teams – You can invite new or existing GForgeNEXT users to your projects.  When you do so, you pick their role and once the invite accepted they can begin collaboration.
  2. Tickets – plan and distribute work across your team.  We honor existing workflow rules, however, administration of those rules doesn’t exist yet. Browsing and filtering of tickets works just fine.  In short while some admin function do exist yet the ticketing system is working well for day-to-day use.
  3. Stand-up Report – GForge provide each project with a stand-up report. See what each team member has accomplished, what they are working on and what they plan on working on.
  4. Git Support – Browse branches, tags and commits through the UI (merges and merge requests are under development).
  5. Continuous Integration – Our new Jenkins plugin uses the latest Jenkins release which will pave the road for new features. Right now the Jenkins plugin accurately reports build activity back to the GForgeNEXT project and this is fully tested and working. Future work will include building a CI dashboard in GForgeNEXT.
  6. Android Support – Access chatroom and tickets all while getting push notifications while you are on the go. (iOS application is under development).
  7. Language Support – GForgeNEXT will eventually support multiple languages.  Right now we support Spanish and English and the language is set based on browser preferences which is nice for new users.

Update for 9/30/2016

  1. Git – Server side merges is code complete and being tested internally. Once this is done we will move right into merge requests.
  2. Notification Center – this feature is similar to what you see on social media sites like Facebook. This week we are adding additional formatting to notifications (date of notification and project it was generated from).  The posts are also now navigable, taking the user to the proper artifact (i.e. ticket, chat, etc)
  3. iOS App – Development began last week.
  4. Responsive UI – We’ve been doing testing to ensure GForgeNEXT renders and functions properly using the small displays on mobile devices.  The only area giving us problems was the mega-menu (the main way to navigate projects on the device)
  5. Tickets – We’re making dependency management a key feature when working with tickets.  The search API for tickets in GForgeNEXT had to be expended to make this possible and we’ve updated the interface to make this as slick as possible.  We will be sure to call attention to any ticket you are viewing that has dependencies.

As always we welcome questions on any of the activity you see.

Fall 2016 HackISU Wrap-up

 

Fall 2016 HackISU Winners for “Best use of the GForgeNEXT API”. Picture (left-to-right): Mehul Shinde, Dig Vijay Kumar Yarlagadda, Chris Matthews, Brendan O’Conner

Last weekend we sponsored our second HackISU Hackathon in Ames, Iowa.  HackISU is run, in part, by both Major League Hacking and HackISU, a student ran organization.  The GForge Group sponsored a prize for “The Best Use of the GForgeNEXT API” and out of all the teams at this fall’s HackISU two demonstrated great projects!

Runner-up: GitHub Migration

The team of Gregory “Charlie” Steenhagen, Justin Wheeler, Nathan Karasch and Jonny Krysh were this semester’s runner-ups.  At the end of the Hackathon they managed to migrate a single project out of GitHub including the Git repository and issues into a GForgeNEXT project.

Winners: GForgeNEXT Chat Commands

The winners for this semester: Mehul Shinde, Dig Vijay Kumar Yarlagadda, Chris Matthews and Brendan O’Conner implemented a way to execute user-created commands that could be ran in GForgeNEXT’s chat rooms.  They demonstrated commands that searched StackOverflow, ran Google searches that both showed up in the GForgeNEXT chat room. They also managed to do simple tasks like create new tickets, update existing tickets and list users assigned to a project.

While both teams demonstrated great ideas our winners edged out the win two ways:

  1. They exercised more of the GForgeNEXT API including use of the user, tracker, project and discussion resources.
  2. GForgeNEXT’s Chat doesn’t implement a way for user’s executed homegrown scripts yet.  This means the execution of any commands isn’t natively supported by our API and the workaround they came up to this limitation was fanastic.  Their engine would poll a given chat room looking for commands (beginning with “/”) and if the command existed it would execute the associated script.  The amount of problem solving that went into dealing with this limitation was impressive.

Overall this semester’s HackISU event was the best we’ve been a part of and we look forward being a part of future event’s.  We’ll conclude with the photo below of our winners who all earned $750 each: