6 Toxic Behaviors that Sabotage Linux App Success

We have all worked on projects that haven’t been entirely smooth or successful. This happens for a lot of reasons, but I thought I’d share some of the top factors that get in the way of successful Linux application development, and invite others to share their experiences.

1: Doesn’t Play Well with Others

Everyone has their own way of working – but there are certain collaborative principles that we should all deliver on. When code hasn’t been designed to be flexible enough to adapt and work with other apps or platforms, it drives people crazy. We are in the era of openness! Apps built to work in relative isolation only create more work for someone else down the line. Blind implementation of initiatives can cause companies to fail in their app strategies because they haven’t created applications for projects within the context of how their businesses operate.

2: Shortcuts before Security

Loose code is a green light for those looking to sneak into technical systems. We have all seen it: An endless project finally gets signed off on. It looks to be okay initially, but after a few weeks of being out in the wild with users, cracks start to appear in the facade. After closer examination of the cracks, the entire app starts to unravel, and the ugly rush job of tying up all the loose ends and turning shortcuts into long, scenic road trips begins. It’s easy to cut corners to get something done fast. But when a project goes sideways, and it always does, cut corners lead to huge delays and security flaws.

3: Poor Documentation

Documentation is king; poor implementation guidance and poor bug reporting are the jesters. Give your code a chance to succeed by making sure others know exactly which app versions to deploy with it. Be careful to write instructions that noncoders, including UX and DevOps, can understand. In addition, bug reporting and tracking is part of the job. Even if you are sure it’s not a bug you created. Unreported bugs might impact how your code performs. Everyone will look bad when users find bugs.

4: Not Leveraging Supporting the Community

Obviously the open source community is a big part of Linux. All developers are at different levels; some are still learning how to best leverage the work of those who have boldly gone before them. If you are not an expert, there are thousands of professionals and assets available to help with development, including numerous libraries for additional research. Those professionals and assets will save you time and ensure that whatever you build is based on protocols that the community is currently using. If you are an expert, remember that everyone has to start somewhere. Should you encounter someone asking for information in the wrong location, resist the urge to show off how smart you are by shaming them. Point them in the right direction, and thank them for asking for help instead of just hacking away somewhere by themselves and making a mess. No one is ever too experienced to give back. Being good learners and good leaders makes the community stronger and more efficient in the long run.

5: Too Complex without Nailing the Basics

So you know some fancy tricks and want to show off how fast you can crank out tasks – fine. But get the basics right. It’s no good being a lightning-fast coder if you aren’t rock solid in the fundamentals. The most valuable things developers can offer their project, their team and the community are useful new tools that enable flexibility and growth as things change. Nothing kills momentum and team confidence more than starting a new feature and discovering that it involves tiptoeing around old code and re-creating essential elements that should have been nailed the first time around.

6: No Vision for the Future

For any app to survive, it needs to be designed with the future in mind. The final toxic behavior in my list is not having a vision. This means not taking the time to look at industry and technology trends and to make sure the app is built to leverage and move with them. It’s a lazy habit to work on the platform you are most familiar with, rather than on the best solution for the project. Apps that can’t evolve become extinct quickly, but if they are built on robust infrastructure that continues to innovate and advance the apps’ potential, then the apps have a future.