I know what you’re thinking: “The DevOps visionaries at Sketch Development only know about eight software development challenges? I’ve already discovered dozens by myself!” Yes, the potential challenges of software development are almost limitless, but many are merely symptoms—symptoms that can be traced back to some common root causes.
Markets, and the technologies they’ve come to expect, fuel a sense of pressure and a constant need to innovate. There is little room to let common software development challenges derail progress. Development teams that don’t adapt will continue to be plagued by the following eight challenges...at a minimum.
Many teams immediately turn to staff augmentation as a solution to software development challenges. There are certainly cases in which many hands make light work, but smaller teams are actually more effective in most cases, especially at the start of a project. Instead of assembling an army of developers, what you need is a talented, dedicated team.
To take a real-world example: Much of the success of DevOps teams at AWS can be attributed to the two-pizza rule: The idea that it’s easier to be collaborative, organized, and efficient if your team is small enough to be fed with two large pizzas. Small teams with broader skill sets are almost inevitably better at addressing a broad range of challenges than pulling together a very large team of specialists.
There are a lot of great companies turning out impressive software. Poor product quality won’t cut it, and modern businesses have to achieve technical excellence to set themselves apart.
When developing the product, the increased pressure could lead to perfection paralysis. The pressure also leads to feature creep, which is especially self-sabotaging when there’s already too much to do and not enough time in which to do it.
Teams can overcome this by focusing on the product’s core benefits. Then ongoing iterations refine quality, focus on immediate goals, and make incremental changes to features based on user feedback.
Partially because there’s so much great software in the world, there’s little tolerance for bugs, and waiting to eliminate them until just before the software goes live is a recipe for disaster. Unfortunately, though, complex projects make it hard to find all of the bugs and discover where they’re coming from. It may require multiple rounds of testing and fixing, which takes time and resources. If the workflows aren’t built to handle this, support work like testing and bug extermination derail the development process. Instead, build time into every development cycle for testing and bug fixes so your team can correct problems as you go along.
Software today is table stakes. Any company that offers a forward-facing service needs intuitive client portals, and workflow management tools to produce those tools and apps. Whether your organization is developing an internal or an external app, all of your stakeholders expect and demand quality. But what does that amount to?
Often, the “quality” users are looking for is different than you think. They don’t care if you cram in a bunch of cutting-edge features they don’t use. Customers need a simple, reliable product that is purpose-built to meet their needs. Engaging with clients, integrating customer feedback, and making continuous improvements is more important than flexing programming prowess. It’s how Google Docs took market share away from bloated MS Word products, how WordPress crushed Drupal.
This is not to say you should roll out half-baked products. In fact, it means the opposite. Steve Jobs put it well when he said, “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple.” It’s about maximizing the work you’re not going to do.
Project managers, product managers, and IT department heads have a lot to keep track of. Competing ideas and differing priorities make it hard to keep everyone on the same page. Long development cycles make it even harder to measure when a project is going off the rails.
By the time leaders realize they’re not steering, the project may have become completely rudderless. Different parts of it may not even be compatible anymore, and there’s a serious risk that costs are about to explode.
Instead of trying to manage projects, it’s easier to manage products. Leonardo da Vinci said, “Art is never finished, only abandoned.” Similarly, software products are never finished, but they should be usable and useful at several stages. The project mentality tries to cram living products into unnatural confines, defining them by timeline, budget, and milestones. Instead, quick iterations and bite-sized work help harness change and manage it more smoothly.
Employees and stakeholders can become so personally invested in legacy systems, they become utterly reluctant to change. Often, those same employees either helped build those systems or are just overly comfortable with them. Tools that tie into or depend on legacy systems also have to change as legacy systems are updated or replaced, and the work can feel like it’s snowballing. Incremental change helps with any of these problems. Learning the difference between harnessing versus resisting change helps leaders modernize software in useful ways without losing control of the products.
While we love innovation and technical excellence, the bottom line is the bottom line. How can you be sure your investment in this project will yield returns? How can you capture those returns before a competitor finds a way to take a bite out of your market share? Getting to market quickly gives you a chance to find niches and fill gaps before anyone else has a chance to encroach on your profits.
The single best way to simultaneously manage the budget and create working software is to generate a minimum viable product (MVP) as quickly as possible. If all you ever get is 80% of something that could work, and keep adding features from there, there’s never a point where folks will say: “This is good enough.”
Budgets and timelines will always be important in business, but not when they’re arbitrary. The most successful DevOps teams are realistic about budget and timeline. When the primary goal is to create working software, teams are free to identify which features they have the time and resources to build.
Agile DevOps teams can’t always avoid common software development challenges, and those challenges exist in agile environments and on agile teams, too. The trick is to meet the challenges head-on and roll with the changes by building small, adaptable teams and using quick development cycles. This is a top-down mentality that starts with product owners, project managers, and IT department heads.
If leadership isn’t also adopting an agile mindset, “agile methodology” and “DevOps” might as well just be buzzwords. After a successful agile transformation that yields successful products, leaders receive a host of benefits, including:
Some teams might need a quick coaching session, while it might take some ongoing training for others to get in shape. The most important thing? Don’t freak out.