Making it on your own and the pitfalls of gem dependencies

by Nikki Murray and Maggie Epps

In the video titled Making it on your own and the pitfalls of gem dependencies, speakers Nikki Murray and Maggie Epps share insights from their experiences as former social workers turned software developers working in a consultancy. They emphasize the importance of properly assessing specific needs before integrating any Ruby gems into a project.

Key Points Discussed:

- Introduction to Gems: Gems can be convenient for addressing common programming problems swiftly, promoting code sharing among developers, but misuse can occur when there is a lack of understanding of their implications.

- Importance of Assessment: The speakers argue that a thorough needs assessment is crucial before blindly opting for a gem. It involves gathering input from all stakeholders—users, designers, marketers—to ensure the right gem is chosen. They assert that assessment should be dynamic and responsive, taking into account all perspectives and potential edge cases.

- Risks of Gem Misuse: They detail the potential risks of over-relying on gems, which include introducing unnecessary complexity, security vulnerabilities, and unknown dependencies. The speakers highlight that about 66% of gems could have vulnerabilities in their versions. Examples include performance issues like memory leaks associated with commonly used gems.

- Maintaining Gems: When considering a gem, its maintenance status, community involvement, and documentation quality are vital. They encourage developers to actively read source code and test cases to ensure reliability and partial solutions don’t become roadblocks.

- Building Custom Solutions: If existing gems do not fulfill specific requirements, the presenters recommend a methodology for creating custom solutions: overcome initial hurdles, assess the problem, conduct research, build and maintain the solution. They stress the need for thorough documentation and evaluating whether the new code could be beneficial for broader use in the community.

- Final Reflections: Murray and Epps conclude by encouraging developers to reflect on their choices critically, even when using popular gems. They suggest that sometimes simpler, tailor-made solutions can be beneficial and could avoid the pitfalls associated with complex, ready-made gems.

Conclusions: The primary takeaway from this talk is the necessity for developers to critically evaluate their needs and the resources they adopt, ensuring thoughtful integration of gems into their projects, or opting to craft customized solutions when appropriate.

00:00:34.510 Hello everyone! Welcome. I'm Maggie, and this is Nikki.

00:00:48.830 We started this talk because Nikki and I are both former social workers who found ourselves working together about a year ago at a small software consultancy. There, we were responsible for maintaining a few different projects and, importantly, for tracking billable hours. We were in a tightly driven and efficient environment, and we encountered challenges we think are worth discussing.

00:01:08.700 Welcome to our talk on gems—use or misuse—and going your own way.

00:01:14.670 I'm Nikki, and you can find me on Twitter at NikkiLizMurray and on GitHub at j_dax. My cats are also on Twitter under Nikki's Cats. I work as a developer, creating fun interactive tools for voters through an organization owned and operated entirely by my cats. Maggie, would you like to introduce yourself?

00:01:39.960 I'm Maggie, and you can find all my handles on Twitter and GitHub under Maps Tamez. I'm also a software engineer at Labor Voices. We provide global brands and their supply chains with an early warning system based on direct feedback from workers through mobile phones. Our goal is to help customers uphold strong safety standards and ensure decent working conditions while empowering workers to have their voices heard.

00:02:05.970 Today, we're focusing on the importance of assessment, which is key. We'll cover what a needs assessment is and how to conduct one. We'll discuss the importance of understanding why we use gems, methods for assessing gems for fit, and what to do if you find no gem meets your needs. This last point will lead us into how to create your own solution.

00:02:35.400 We're beginning with the importance of assessment because if you take away nothing else from this talk, we want you to remember to accurately assess what your problem is and what your needs are before installing a gem into your system. The quote we have states that assessment is an ongoing process which is participatory and seeks to understand the service user and their situation in order to aid planning for change or improvement. Interestingly, we didn't take this quote from a software development textbook; we borrowed it from social work literature.

00:03:40.260 Models of assessment are common in social work training. Assessing both users and your own team is necessary. The assessment process should be purposeful and specific, tailored to what's appropriate for your situation. It must be dynamic and responsive, meaning it should remain flexible based on input from all engaged individuals. This means that during your assessment process, all stakeholders should be present. This includes users, designers, marketers—anyone who will have a hand in this project. It should be ethical, skilled, and grounded in legal and policy contexts.

00:04:56.300 Additionally, it should empower everyone involved in making assessments, ensuring that they feel heard throughout the process. Assessments must also highlight protection and safeguarding, as privacy is essential. Consider every edge case and possible scenario where users may interact with your product. Providing support for decision-making is crucial too. If you're the programmer making the final decision on which gem to use or create, you need assurance that your choices won't be second-guessed later on. Finally, meetings for assessments should lead to actionable future steps, as endless discussion without conclusions can be unproductive.

00:06:27.920 So, what exactly is a needs assessment? Throughout this session, we hope to help you avoid the pitfalls of using gems recklessly. The first step is truly understanding what you need before you select a gem to solve your problem. This means clearly defining the problem and considering it from multiple perspectives: Is it an issue for your users? Is it an issue for your team members? And why does it matter? Gathering input from stakeholders is critical, whether through in-person meetings or channels like Slack.

00:07:42.820 It's vital to take your users' views on board because they are your primary stakeholders. Different solutions may impact them in various ways, and sometimes we approach problems under the assumption that it's a singular issue, when, in fact, it could be multiple problems. Break down your problem, tackle the most pressing issue first, brainstorm multiple solutions, and seek feedback on these. Once you have determined the best approach, then you can decide whether to use an existing gem, write your own, or incorporate features directly into your project.

00:08:22.820 So why do we use gems? The answer may seem obvious: They're convenient. They allow you to solve problems quickly, enabling more time for other tasks, like petting your cat. You shouldn't solve a problem that's already been addressed; using existing code promotes DRY (Don't Repeat Yourself) principles. There is a community aspect to using gems; by relying on shared solutions, you share the responsibility of maintaining them among many developers, which is beneficial.

00:09:37.180 However, misuse can occur when you have 150 gems installed without a clear understanding of the reasons behind your choices. On average, a Gemfile.lock may contain around 118 gems with a standard deviation of 58, meaning many projects will have between 50 to 175 gems installed, contributing a lot of code you might not have written or can't control. The risks associated with gem misuse include unknown dependencies, the potential for upgrades to break your application, and notably, that the gem may only provide a partial solution.

00:10:44.660 These problems can stem from a culture of urgency in the startup ecosystem where the focus is on getting solutions out quickly, often leading to the adoption of popular gems without full consideration. Other factors include groupthink—this notion that a gem is widely accepted, so it must be good—and a lack of thorough planning, leading to choices that may not suit unique use cases. Impostor syndrome can also play a role—doubting your ability to create a better in-house solution than pre-existing gems.

00:12:00.600 Another significant risk lies in understanding your app's behavior. Many security vulnerabilities associated with gems can reflect weaknesses in systems dependent on them. For instance, around sixty-six percent of gems on RubyGems.org have had at least one version with security risks, which may range from minor to critical vulnerabilities like SQL injections. Regularly assessing gems for updates is essential as a large percentage of gems can introduce security and memory risks.

00:12:57.800 For example, some commonly used gems have documented memory leaks. As a developer, it’s crucial to assess your project for dependencies and recognize that you may end up feeling restricted by the limitations of the gem authors' original intentions, which can result in excessive code for minimal problem-solving. It's easy to believe a gem resolves most of your problems until you discover it's not functional or compatible with other gems in your system.

00:14:24.920 During our discussions on gem assessment, it's essential to consider maintenance aspects, such as how well the gem is maintained. When was the last commit? Was it updated following major Ruby updates? Community involvement is another factor to examine, like GitHub watchers or stars, as well as checking the number of downloads on RubyGems.org to gauge interest. Investigate issue trackers for unresolved problems, as well. Are security patches integrated promptly?

00:15:20.200 It's beneficial to read the gem's documentation and source code thoroughly. The quality of its tests is also a significant factor. Ensure the tests examine edge cases that align with your needs. Review the contributed tests; they can offer insight into the gem developer's intentions and expectations. Having a well-documented project and code of conduct is crucial to ensuring positive interactions with maintainers and contributors when inquiries arise.

00:16:35.500 If you find that a gem fits most of your needs, consider contributing by adding the specific functionality you require in a pull request. Until it merges, you can use a local copy or point your Gemfile to your branch on GitHub. Check to see whether it solves your problems in a way that will satisfy the users of your project. When assessing whether a solution will be accessible, also consider your own level of comfort in using it.

00:18:48.000 After identifying that none of the existing gems fit your needs, we may approach crafting a solution ourselves. This involves overcoming the initial hurdles of the design process. The methodology we propose is: overcome, assess, research, build, and maintain. It's essential to recognize that feeling overwhelmed at the beginning is normal, but it means you are on the right track toward building something useful.

00:19:46.600 Return to the core problem: accurately define what behaviors your system currently exhibits and what you aim to achieve. Analyze potential edge cases that may not have been covered by existing gems, and contemplate the risks of your personalized approach. While you consider what hasn't been addressed in other processes, research what previous gem authors have documented about their problem-solving methods.

00:20:59.700 Explore other resources like blogs or articles where similar problems were tackled. Following your extensive research, proceed to build your solution while maintaining best practices. This includes modeling each component and maintaining thorough documentation. It's vital that your code remains approachable for others, ensuring they can quickly grasp why you've approached the problem in a specific manner.

00:22:12.900 Always check if the solution needs to remain embedded into your app, or if there's merit in transitioning it into a separate gem. If so, think about how abstracted your solution can be, enabling it to be useful beyond your immediate use case. If your solution could benefit others, consider open sourcing it, adding a contributor code of conduct, and engaging the community to foster collaborative development.

00:23:20.780 When finally publishing your gem to RubyGems.org, reflect on how easy it will be for others to get it up and running and contribute to the codebase. The documentation should clearly specify what your gem solves and any limitations. You should also maintain clarity regarding what Ruby versions it is compatible with, ensuring users can effectively assess its usability.

00:24:40.000 As you're maintaining this gem, assess whether a new developer could easily familiarize themselves with your work. Consider whether your tests are solid and well-documented, so future developers won’t face hurdles just to understand the functionality. Regularly reflect on why certain decisions were made; future colleagues may ask themselves why certain paths were chosen, and having reasoning available will facilitate continuity within projects.

00:25:57.000 It may become necessary to simplify overly complex solutions, as maintaining clarity and simplicity will enhance long-term usability. Regularly engage in the assessment of your gem, keeping in mind that ongoing evaluations are crucial. A key takeaway here is that when using a gem, though you're enjoying time freed up for your own work, you're still bound by the decisions made elsewhere. Ultimately, if the gem maintainer makes significant changes, you have to adapt your solution accordingly.

00:27:55.000 Before concluding our presentation, we welcome any questions regarding effective assessment, team evaluations, or recommendations for gems that are particularly useful or unhelpful. For example, many gems available for building APIs are frequently recommended, but there is a risk that relying too heavily on them may not yield the best outcomes for your specific context.

00:29:24.600 We want to highlight that suggestions to use popular solutions like Devise or Grape may not always align with the actual needs of your project. While these may seem like quick fixes, they can introduce unwanted complexity when they aren’t necessary. Our discussion encourages everyone to consider their unique requirements and the possibility of implementing simpler solutions on their own to avoid the pitfalls of blindly adopting gems.

00:34:22.000 Thank you, everyone, for your attention.