Over the years people have asked about breaking Helm up into a set of smaller tools. For example, one for templating, one for application metadata, one for packaging bundles up, and so forth.

To understand why Helm doesn’t break things up, which is a lesson for other projects as well, let’s look at an analogy…

Crossing A River

Imagine a group of people needing to cross a river. Some people will just want a bridge to go over the river. Others will want the wood, nails, saw, and hammer to build the bridge themselves. This second group will use the tools to build their own bridge. In addition to the bridge they may build buildings, art, or numerous other things.

Different groups of people will want different things. The first group, that just wants a bridge, may have other things they need to do and there can be many of these people. If they put in the time to each build their own bridge there will be a lot of different bridges. If they had something else to do, such as go to a neighboring village, their time to do that will be less because they put in a bunch of time to build a bridge.

The second group, that wants the parts, will be able to experiment, try new things, and build some amazing things. For them, having the tools to build different things is empowering and their primary effort can often be to create these new things.

Relating To Software and Helm

This analogy showcases different types of people whose goals and needs are different. When developing software it is important to know who the end users are. One thing can’t be built to solve all problems for all people.

One of the lessons I’ve learned is that most organizations are focused on their particular problem space and want the supporting parts to just work. The rise of Software as a Service and Functions as a Service illustrate this. People want to spend more time on their particular problem and not on supporting elements to building a solution.

When it comes to Helm we have identified who our users are. From the analogy, it is people who want to cross the river and not people who want to build things like bridges.

Applying This To Your Projects

If you are building a software project I would suggest figuring out who your users are and what their needs are. This may be very different from your own. I would suggest putting these in writing and taking some time to collect data on these folks.

Knowing what end users need is a great way to apply focus to what needs to be delivered and what would be useful.