Software development is a challenging discipline built on millions of parameters, variables, libraries, and more that all must be exactly right. If one character is out of place, the entire stack can fall.\n\nAnd that\u2019s just the technical part. Opinionated programmers, demanding stakeholders, miserly accountants, and meeting-happy managers mix in a political layer that makes a miracle of any software development work happening at all.\n\nStill, it\u2019s impossible to list the endless innovations that software alone has made possible. And much of that depends on the efforts of coders and the people who manage them. Over the years software teams have figured out a few rules for getting the job done. From elaborate methodologies to emergent disciplines and philosophies, the rule books of software development help make it possible for everyone to collaborate and get to the finish line with something that works.\n\nAlas, for all the innovation, there are still failure modes \u2014 ways that software developers and their managers get things wrong. Sometimes the methodologies are misapplied. Or the good ideas are taken too far. Sometimes developers just forget, sometimes purposely, what they\u2019re supposed to do.\n\nThese sins of software development can derail just about any project. Pay attention because the only way to ensure your team can build great things is to pause and consider the not-so-great code that can be created when we fall prey to these missteps and temptations.\n\nChoosing the wrong methodology\n\nAll software development methodologies have fans who are passionately devoted to the rules that define their favorite way for organizing a team. The problem is often in choosing the right one for your team.\n\nOne big mistake is imposing these rules from the top. If coders are big believers in a different approach they\u2019ll often grouse and complain with cynical disdain if they\u2019re shoehorned into using another. Alas, another mistake is letting programmers in the trenches choose their favorite because they may not understand what\u2019s best for the whole team.\n\nChoosing the right methodology won\u2019t fix all problems, but it will reduce the amount of friction that comes from organizing the workflow. The team will know their role and they\u2019ll understand just how to code inside of it.\n\nIgnoring scalability\n\nSome software development issues can be fixed later. Building an application that scales efficiently to handle millions or billions of events isn\u2019t one of them. Creating effective code with no bottlenecks that surprise everyone when the app finally runs at full scale requires plenty of forethought and high-level leadership. It\u2019s not something that can be fixed later with a bit of targeted coding and virtual duct tape.\n\nThe algorithms and data structures need to be planned from the beginning. That means the architects and the management layer need to think carefully about the data that will be stored and processed for each user. When a million or a billion users show up, which layer does the flood of information overwhelm? How can we plan ahead for those moments?\n\nSometimes this architectural forethought means killing some great ideas. Sometimes the management layer needs to weigh the benefits with the costs of delivering a feature at scale. Some data analysis just doesn\u2019t work well at large scale. Some formulas grow exponentially with more users. The computations overwhelm the hardware and clog the communications.\n\nDevelopers don\u2019t always want to think about the big picture. It\u2019s too easy to just dive in and start creating. But smart development teams and their managers spend time anticipating these issues because if they don\u2019t they fail later.\n\nFalling for the latest trend\n\nSoftware developers can be notoriously attracted to new and flashy ideas. Maybe it\u2019s a new kind of database that offers more complex queries. Maybe it\u2019s a new programming language that will fix all the bugs caused by the old one.\n\nSometimes these ideas have merit. Many times, though, they end up slowing development as everyone tries to learn the new technology. Sometimes the new ideas have hidden flaws that become apparent only after everyone is knee deep in the muck just before the project must be delivered.\n\nCaution is often the best rule for adopting new technology. There\u2019s a reason why some of the biggest and oldest companies continue to run software written in COBOL. Trends come and go, but working logic in running code doesn\u2019t wear out.\n\nRetaining too much data\n\nProgrammers are natural pack rats. They love to store information in case it\u2019s needed in the future. Keeping it around because \u201cyou never know when we\u2019ll need it\u201d, though, can be a recipe for a security leak or a violation of users\u2019 privacy.\n\nThe problem can be even greater with personal information like birth dates or other details. Some areas, such as financial records or health records, are heavily regulated making it easier to run afoul of the rules.\n\nGood software architecture involves planning ahead to minimize the amount of data that\u2019s stored. It protects everyone and can save storage charges, while even speeding up the system by reducing the amount of data in motion.\n\nOutsourcing the wrong work\n\nThe debate over building or buying software is a time-honored one with no definitive conclusion. Still, software developers often choose poorly. Maybe there\u2019s a perfectly good solution at a good price and they are too prideful to set aside their custom stack with its expensive in-house team. The opposite also happens. Some managers buy into an outside vendor\u2019s product line only to watch the vendor jack up the prices dramatically when the lock-in is complete.\n\nUnfortunately, deciding just which outside tools to use is a constant challenge for software development teams and their managers. Hiring the right outside source is genius, but adopting the wrong vendor is a ticket to a high-priced prison.\n\nAvoiding testing\n\nEffective software developers and their managers know that testing is a constant challenge and just as much a part of the job as writing recursive code or designing an elegant data structure. Testing should be included from the very beginning because unit tests and integration tests are vital to ensuring code stays viable throughout the development process.\n\nBut testing is also important for handling large loads. It\u2019s too easy to write code that runs smoothly on our desk when we\u2019re the only user. If the application is going to have hundreds, thousands, or maybe hundreds of thousands of users, you need to ensure that the code is efficient and the deployment is able to handle the large scale.\n\nMany teams bring in quality assurance testers who watch for the kinds of mistakes that programmers make. They know how to, say, set a parameter to zero just to see whether it causes a divide-by-zero error. They know to purchase 3.14159 shirts or -4000 socks just to see if it breaks the code. This attention to testing is essential when the use cases get so complicated that it\u2019s hard for any single human to think of all the variations and write clean code that anticipates them all.\n\nUnderestimating the power of planning\n\nMost code requires some devotion to planning. Alas most coders often just want to jump right in and start machine-gunning code.\n\nOne of my friends tells me that it took him several years to recognize that the best step is to stop, plan, test the plans, and plan some more. Writing plans may seem tedious but it can be 10 times faster to try out ideas when thinking abstractly. He\u2019s now a very successful manager.\n\nPlanning also means including the input from the other teams and stakeholders. They\u2019re going to be the ones using the code in the future, so spending time discussing the project and learning their needs will save plenty of frustration afterwards. This is the best way to avoid many of the sins listed here.