What outdated software development trends should you avoid?

I think the question is somehow misguided. You don't avoid a way of doing things because it is outdated, you avoid it because it doesn't work for your context. As I suspected, I've seen "waterfall" and derived lifecycle models be the primary target here, whereas they are still being effectively and successfully used by companies making large complex products, either pure software or hardware-centric transportation, medical or cyber-physical systems. I think we must shift our thinking from these grand absolutist claims to learning about all of the ways people do software, not seeking "wins", and being open to/advocating for software teams analyzing and adopting what's best for their project and adapting it to their unique challenges.

Capital A ‘Agile’ needs to fade away in favor of ‘agility’. I’ve seen fintech teams adopt the Spotify Model because it’s trendy rather than think, “Is a music service’s project management needs different than ours?” Don’t rush to plop prescriptive scrum on your org.

In the same way as there are dozens of flavours of Agile, Scrum, Kanban etc, there are also a huge number of varieties of Waterfall. The Waterfall described in the picture painted here is no better or worse than a number of agile processes I've witnessed. Dogmatism is what fails almost any process. The desire to stick with a defined set of processes, without being able to adjust to new information. Following a plan that's encountered the enemy. Failing to react when the inevitable happens. Agile isn't a process, waterfall isn't a process. They're opposite ends of a spectrum with a million possible jumping off points.

In large organizations, 80% of the software spend goes on maintenance. Therefore, EVERY development methodology is outmoded. They should all be replaced with Maintenance-Driven Design (MDD) because designing for ease of maintenance is where most of the money is.

Agile, especially agile/scrum with its focus on rigidly timed sprints, is effectively waterfall in practice. Each sprint must be completed before moving to the next, and if feedback uncovers a shortcoming in the basic design, and that can't be fixed in one sprint, forget it. Monolithic architecture... In practice today, a distributed design is just a disconnect layer for what ends up being a monolithic design. No, everything can't just work with everything else. If you want flexibility, you have to design for it. It won't happen by making everything a loose connection. That just yields chaos. And security holes. Legacy code... you're stuck with it. Oh, we'd love to redesign, but... no budget. (And it can't be done in one sprint.)

While the paragraph paints monolithic architecture in a negative light, I believe it's not a one-size-fits-all scenario. Starting with a monolith can be a strategic choice, especially when the project's scope and requirements are still evolving. The key is to design with foresight, ensuring components aren't tightly coupled. This approach offers the simplicity of a monolithic structure while retaining the flexibility to evolve. As the system grows, we can then consider transitioning to microservices if needed. It's about choosing the right tool for the job, not dismissing one entirely based on trends.

Microservices and monolithic architectures have been positioned in opposition for some time, often framed as a battle between the outdated and the innovative. This dichotomy of 'bad vs. good' oversimplifies the reality. Microservices require substantial infrastructure, the resources and expertise needed to implement them efficiently may not be available in all organizations. A monolithic architecture, when well-architected, can be modular and manageable, facilitating future component extraction. In my experience, for small teams or new projects, beginning with a straightforward monolithic approach and evolving as needed can be effective. The choice should be driven by project specifics and available resources, not just industry trends.

I don't think this is an all encompassing truth. The architecture to be chosen will depend on various factors including - Domain - Number of people who are going to use the application (it is not true that an application is always used by millions of users) - Which of the non-functional requirements is most important, e.g. latency vs scalability

An overly bloated, non performant microservice architecture is arguably worse than a monolith. Add in additional complexity, again, you need to know the problem to know if the trade offs are acceptable.

Monolithic architecture is not necessarily bad. What can make it terrible if it is an accidental monolith with tightly coupled internal structure and not built as a well-architected (often called "majestic") monolith. Microservices have tons of challenges thanks to their distributed nature and solving them is not only tricky but takes a huge amount of time. Yes, they have deployment and scalability benefits, but do you _really_ need them? What is the real problem you would want to solve with microservices? You can solve complex problems with great scalability, ownership and excellent deployment cadence with modular monoliths as well, and they are much quicker and cheaper than building the complex environment for microservices.

The faster I can get feedback, the quicker I can course-correct if I have errors in my code. A quick correction is far less costly to the business than wasting time "finishing" only to find a massive flaw in the logic. I have to be able to trust the results of testing, no matter whether it's automated or manual. Badly written tests are no help to anybody! Again, the issue of waste, with time spent tracking down bad/flaky tests or human beings getting tired or prone to errors. There's a British idiom that is helpful here - "horses for courses" - different types of testing are suited to different scenarios. A skilled QA or SDET coupled with a talented engineer can inform what to test, the type of test and write a good quality test.

This is poor advice. You should not automate as much as possible. That is not our job. There is nothing wrong with automating testing, and you should have automated tests if they are appropriate. However, there is nothing wrong with having a suite of interactive tests that require eyes-on to verify the work. There can be completely manual or semi-automated. By attempting to automate every test we end up with people running UI tests in CI and dealing with "flaky builds" all day instead of being productive. Practice good structural design rather than monolithic architecture and ensure that each deployable piece has just the testing it needs. Teach your developers how to verify their work, not "automate as much as possible".

Although test automation generally offers more benefits, there are some scenarios where manual testing can be more suitable. For instance, there might be complex scenarios that rely on multiple services, which could be challenging to automate correctly. In such cases, manual testing might be the simpler choice. Therefore, in some situations, test automation can slow down the delivery process. It's crucial to consider the cost-benefit analysis of automation, taking into account how frequently the test will be executed, and of course, comparing the effort of building the automation versus just running the test manually.

Manual and automated testing are not mutually exclusive. In fact, both have to be heavily used for testing serious applications

Legacy code isn't an "outdated software development trend", it's something you've given up on trying to understand. It’s important to acknowledge the amount of experience, knowledge, and problem-solving contained in legacy code. It's a treasure trove of solutions to past issues and bugs, representing a mass of organizational knowledge. Discarding or altering this code without a deep understanding and appreciation of its history and intricacies can inadvertently reintroduce previously solved problems or create new ones. Attempting a rewrite is a huge undertaking and shouldn't be done lightly. If refactoring without good test coverage, be sure to analyse the "legacy" code, and add tests as you go to reduce risk. There be dragons!

I would give a slightly different definition of legacy code. I would argue legacy code is any code that is not covered by tests. If a piece of code is properly covered by tests then we can be sure about its behavior and we can aggressively refactor it. Consequently, if we CAN refactor but just simply don't decide to do so e.g. because it's not a high priority, it's not legacy code. If however, we are afraid to adapt it because we might break the behavior then we do have legacy code. IMO the first thing one could do when tackling legacy code, is to write a suite of automated tests that verifies the desired behavior

Legacy code gets a "bad rap" in the press. That gnarly old code that no-one wants to touch (or in some cases is not allowed to touch for fear of it breaking) probably provides the business value that pays your salary. I'd argue that the ability to tame, understand and manage legacy code, is an almost unacknowledged skillset in our industry. As a profession we need to shine a light on this skill and highlight those best practices and communicate them to our peers. Unless you're able to go File>"New Project" regularly, you're probably working in what a new starter would think of as a legacy code base (because it was written by someone else) so we've got to acknowledge it's always going to be around and learn to get along with it.

The new and shiny is always attractive but it's not always better. If you follow good coding and documentation practices, your code will last you for ages. Think of rewriting code only if 1. The code is messy and undocumented and your dev team is spending more time deciphering old code than building new code. 2. You are struggling to find developers for that particular coding language. 3. You are unable to update / modify existing code to fulfill new requirements. If you do initiate a project to replace legacy code, start small. Replace a portion of the system and Go Live. This will help you test if the new approach is indeed better.

A colleague of mine once rebranded a legacy codebase as a, "legendary" codebase. Sometimes a perspective change is important. "Legendary" codebases have been serving customers in production for a long time. That is more than can be said for any unwritten code that aims to improve upon what legendary code has been delivering at least somewhat reliably. In addition, you can set out to refactor legendary code and realize that, after talking to stakeholders, users, and learning more about the domain, that the legendary code you started with may be just what's needed to handle the intrinsic complexity of the domain. Don't throw out legendary code before you understand exactly why it's been working successfully in production for so long.

I have found that initiatives that attempt to make every engineer a jack of all trades can have mixed results, particularly in larger organizations where the enterprise solution has to work together in harmony. When you have a start up, you might be able to get a handful of unicorns that can do most anything, though that doesn't easily scale. You also have to consider, not all engineers want to do everything. Some like a blank sheet of paper, some like to fix things, some like to break things. You also might want to consider dilution of the intellectual asset. If you are expected to be competent in everything, how do you become an expert at anything?

Be careful of swinging too far to the other extreme: expecting everyone to be able to do everything. Advocating for a cross-functional approach doesn't necessarily imply that every team member should be a jack-of-all-trades. Instead, it suggests a model where team members maintain their areas of expertise while being able communicate, collaborate, and share knowledge easily. For instance, while a developer, tester, and designer have distinct roles, creating a collaborative environment and culture where they can learn from each other, share insights, and contribute towards common goals is valuable. Aim for a handful of T-shaped team members, allowing deep individual specialisation, but collective broad growth.

One thing that is not mentioned is that the main issue with siloed teams, which gets eliminated when creating cross-functional teams is the existence of handovers between teams that in turn create WIP. Work in Progress reduces delivery flow. So with cross-functional teams, we are faster to deliver which makes the team able to react faster to changing customer needs. However, when we create such cross-functional teams that are fully responsible for the whole product lifecycle we increase the cognitive load on the team. To tackle that we need to have those teams focus on a specific business stream/domain and also have supporting types of teams e.g. platforms that will aim to reduce their cognitive load

Teams will often have a siloed view if they never understand the world of other teams. One thing I've done as a Scrum Master to help mitigate this is to set meeting cadences to help teams better understand what's going on outside their world. Helping developers understand product/sales concerns and product/sales understand the technical work happening behind the scenes helps to validate the hard work each team is doing, removes assumptions, and creates stronger camaraderie across organizations.

Siloed teams pose a significant challenge in modern software development. Operating in isolated compartments inhibits collaboration, hindering the seamless flow of information between development and operations. This approach results in slow deployment cycles and communication gaps, impeding the overall efficiency of the development lifecycle. To counter this, embracing DevOps practices becomes imperative. DevOps promotes a holistic, collaborative culture, breaking down silos and fostering a shared responsibility for both development and operations. By integrating DevOps principles, organizations can optimize deployment speed, enhance communication, and ensure a more streamlined and efficient software development process.

I'll be controversial and suggest that we should get rid of deadlines. Deadlines are rarely if ever met. They cause strife, confusion and can damage team morale. If you've ever met a deadline it was likely either because it was shifted several times as you got close to missing it, or you sandbagged the estimate making it easy to hit the deadline. Neither of these are healthy software dev practices. Teams should focus on publishing an ordered roadmap and constantly communicating progress and issues to stake holders. Everybody should know what you are working on, what you've done recently, and what's coming up. If somebody wants something done sooner, you can negotiate a change to the roadmap transparently with all stakeholders.

I think you should stay away for fully custom development whenever possible. Today there are so many proven solutions for different features like authentication, logging & monitoring etc. Custom solutions usually require more time to develop and are painful to maintain. Still from time to time I see that developers are building fully custom solutions instead of utilizing the standard practices and protocols available in web.

Neglecting code maintainability is a critical pitfall in modern software development. Failing to prioritize clean code practices leads to accumulation of technical debt. This debt manifests as complex, hard-to-understand code that hampers future development efforts. In the absence of a focus on maintainability, teams encounter challenges in implementing updates, fixing bugs, and introducing new features efficiently. To address this, emphasizing clean coding standards and incorporating regular refactoring into the development process is paramount. Prioritizing code maintainability ensures a more agile and adaptable codebase, reducing the long-term cost of development and fostering a sustainable and efficient software development environment.

Drop time-boxed development. I've seen plenty of stories in a scrum setting that get split into multiple stories, simply because it doesn't fit in a 2 week sprint. This results in stories that get merged and feature toggled at the end of the sprint, and continuous to stay that way for the next couple of sprints as it only starts to deliver value when all related stories are completed.

- Security scan the code as part of CI/CD - Run test cases for each code submission and build - Use tools that provide you traceability. Example: Traceability should show me if a test case is written for a production bug. Traceability between story and test cases. etc... - Know what code is executed by test cases. Code coverage. what's percentage - Have smart automation testing. Execute tests based on the code change. - Do not carry use case baggage, just because you carried. Possibly there are better ways of supporting those use cases.