Markus Werle

When you […] Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. - A.A.Milne

This article is part 2 of a series. Before reading it, please read part 1.

TL;DR

In the second part of this article series, I will compare JIRA to one of its competitors, GitHub. The differences in architecture, data model, and UI design are striking. They reveal something very fundamental about software design and about company culture.

Disclaimers

  • I am still waiting to get paid for praising some parts of GitHub. 😇
  • I am disappointed with how GitHub continues to evolve after Microsoft acquired GitHub.
  • This article is highly opinionated. Please let me know if you disagree on LinkedIn.

The Power of Minimalism

New Kid On The Block

A couple of years after starting my struggle with JIRA, I learned about another platform solution that had gained quite some attraction: GitHub. Getting to know GitHub in its early years, I realized something significant.

When it comes to software tools, simplicity often reigns supreme. GitHub, the popular version control and collaboration platform, exemplified this principle.

GitHub - A Multiverse of Good Design Decisions

While GitHub representatives probably never explicitly mentioned the KISS (Keep It Simple, Stupid) principle, the original GitHub design demonstrates a pragmatic approach that values simplicity without compromising functionality. I believe this to be a key factor in GitHub’s meteoric rise and in its becoming the number one place to go for Source Code Management.

GitHub’s success can be attributed to two critical effects of its minimalistic approach:

  1. Ease of Learning: GitHub’s user-friendly interface made it accessible to experts and novices.
  2. Reduced Complexity: GitHub minimized complexity by offering users a streamlined set of options. This simplicity allowed the platform to reach stability and maturity swiftly. Users could focus on their work without being bogged down by unnecessary features.

Ease of Learning

I had the chance to see how vital ease of learning can be on several occasions when I introduced GitHub to technical and non-technical staff simultaneously. As with a chemical reaction, it is crucial to collect sufficient activation energy to get things going.

Interesting enough, using GitHub’s web GUI to create content only requires a fairly low amount of activation energy. People who had never used a markup language to generate formatted text before needed less than an hour to understand how to write issues, READMEs, or Wiki articles.

For LaTeX text processing fans like myself, the number of features offered by GitHub Flavored Markdown (GFM) are way too limited. But this lightweight markup language can be learned fast by anyone who can read. Its simplicity encourages collaboration and documentation without the need for extensive training.

The positive effect is that non-technical and technical staff can share information via a common collaboration platform.

Reduced Complexity

GitHub’s interface doesn’t overwhelm users with unnecessary bells and whistles. It sticks to the essentials. This intentional minimalism prevents over-engineering and keeps the focus on what truly matters.

Note that GitHub is a tool built on top of one of the world’s most complex and powerful tools, namely Git. Git is like the Wenger Giant Swiss Army knife, but all you need is a blade, the nail file, the saw, and the scissors (git clone, git add, git commit, git push).

The largest swiss army knife of the world
Source: Wikipedia

The GitHub GUI reduces the view of this powerful tool to the absolute necessary.

Issue States

Now, how many states can an issue have? Remember JIRA? Please count all possible “statuses” their documentation lists. I failed to enumerate them all in part 1 of this article series. In contrast, the number of possible states of a GitHub issue is at the theoretical minimum. It can exist in only two primary states: “open” and “closed”.

Of course, this is only half of the truth. As with JIRA tickets, GitHub tickets can have an arbitrary number of labels; from a formal point of view, these are sub-states. Or - to be even more precise - every GitHub issue has one additional substate: a set of labels that can be empty.

Can you spot the difference? The JIRA designers try to catch every possible view you can have on an item in one attribute - a common error in Object Oriented Programming. Finding the right location for the information to be stored has a significant impact on the scalability of the system itself. JIRA architects failed this task. You have to get structural containment right. The initial error led to further complexity: JIRA does not only have a rather large set of “Issue statuses,” but due to later extension of the system, it also provides additional sets of states: “Jira Software statuses” and “Jira Service Management statuses.”

Is that a complete set of possibilities now? While I was CTO of Ducktrain, we successfully used GitHub Issues for everything, even for the procurement process! How would we handle that in JIRA? Will JIRA extend the set of possible sets of possible “statuses”? Will we have “Jira Procurement Statuses”? Can you see the unnecessary complexity introduced in the system? Can you see Pandora’s box wide open? Is there a better way to map business processes to a ticket system?

Distinguish Data and Views

If you want a certain view of your data, create it! But as a system designer, never try to anticipate and map all possible future usage scenarios of your product into a finite set of states stored within the data items.

Let’s have a look at GitHub Projects. After a considerable launch failure due to a missing m-to-n relation in project views to repositories (which is fixed by now), we have a system that allows a specific set of views (called layouts), such as list views, Kanban boards, and roadmap views.

Interestingly enough, you can add metadata to an issue like dates or number fields. But this data belongs to the project and is not stored as an issue state in the issue itself.

The column in a Kanban board a ticket is assigned to is also some kind of metadata (an additional state the ticket is in, but not stored as a state within the ticket). Unsurprisingly, a ticket (aka issue) can be in different columns in Kanban views of several projects.

It appears that GitHub’s data model yields a more flexible product and is more robust against changes in the user story.

What was it made for?

The huge success of the Agile Movement may stem from its human-centric approach. If you are old enough, you might remember the wishful thinking of “Individuals and interactions over processes and tools” that never came true.

GitHub’s huge success may stem from its developer-centric approach or, more precisely, from its focus on the people who actually do the work, not the ones who supervise others.

There is tension between developers’ and managers’ needs. You can guess which party has predominance from the tools an organization uses. For example, extracting metrics and KPIs1 is not something a developer needs. It’s what managers need to fake objectivity for their decision-making 2 or to feel less insecure.

Don’t get me wrong. The tension between developers’ and managers’ needs does not mean managers’ needs have no right to be fulfilled. Having a clear picture of what is going on in your organization and knowing whether there is enough money to pay the next salary round is essential. Coordination between different entities in your organization might serve productivity and unveil potential for improvement.

You should be honest with and aware of the reason for a particular tool choice or tool configuration. Life is hard when a tool does not fit the task, but life is even more challenging if a tool is not used for its intended task but is abused by some people in your organization for supervision or command and control.

So here’s the question: What was GitHub made for? It was made for collaboration. It was made for coordination. It was made for documentation. It was made for traceability. It was made for source code management.

It was not made for command and control. It was not made for supervising. It was not made for performance tracking3. It was not made for people management.

As a manager, I love unified approaches. I love simplified structure and information that fits on a PowerPoint slide because that is what managers do. Three bullet points on a slide to ease tough decisions. Thinking linear, not thinking complex. It helps when I have 200 decisions to make every day.

Is that what ticket systems were made for? What was JIRA made for? Do you understand how its feature set reflects a particular management style and perspective on a company? At one of my customers, the quality team forced completely independent software development teams to align on their JIRA configuration, renaming states (!) to ease the acquisition of KPI data. This kind of behavior is the complete inversion of “Individuals and interactions over processes and tools”.

If you look at GitHub projects with a more critical eye, you can spot the small steps toward features that meet the needs of managers, especially in large organizations. For example, the original GitHub authors turned deaf on any request to add effort estimates to tickets. Now, they are available via the project views. This could be collateral damage of the ongoing #NoEstimates battle, best illustrated by my most beloved “enemy” Peter Kretzmann, who gives his website the title “CTO/CIO Perspectives” (I could not have invented this one), fighting bites and nails in an uphill battle against something that worked for GitHub to deliver one of the most valuable software products of the planet.

As with JIRA, the tides have turned for GitHub. The managers are taking over, especially those who think that “if you can’t measure it, you can’t improve it.” Hence, GitHub now provides supervision labeled with the euphemism “data-driven insights” as if that data really shows you the root cause of your organization’s problems.

Some Advice

If you want to be successful in Software Development (or, more generally speaking, engineering), choose your tools and their configuration so that neither the tools nor the processes designed around them stand in the way of the developers. Drop alleged objectivity through KPIs and other measurements favoring a more human-centric approach.

Yes, try it!

  1. KPIs are super attractive because you can make them look like you are progressing as an organization. ↩

  2. This is why AI is so attractive. Something that uses math (and some inexplicable magic) sucks information out of data and appears to be objective. Let us not criticize the way the data was acquired. ↩

  3. Git, to remain in our original context, was designed for version control. Of course, there are toxic people all over the world who seriously think they can gather objective (sic!) insights from git commit data. I hereby put Alex Circei, a white man, onto my newly created employee blacklist. ↩

You May Also Enjoy