What's your approach to software design?

Keep the focus on what is important and start small, do not overengineer it, do not optimize it (yet). Open-closed principle helps a lot in the first decisions, consider the upcoming change vectors when defining couplings. Business Domains are helpful, avoid segmenting components by their pure technical nature. Technology can be replaced (and will be quickly with new technologies providing competitive advantage), that's why focus should be on the Business. Test early, be transparent with the progress and open to any feedback. Be human, people is always the main force for innovation and not technology alone.

In my experience, it's a combination of both top-down and bottom-up software design approaches that works best. Ideally, before designing a new functionality what I want is to have a good grasp of what's in my toolbox. So I first check if there are any restrictions. Do I need to use a specific technology? Is the system completely new or an existing one that needs to be extended? Then I do some research on that, and when I feel comfortable with what I know, I start my high level design using a top-down approach. After I've created a few diagrams and I've sketched out the basic structure, that's where I believe the bottom-up approach begins, to ensure that each high level component can be engineered as efficiently as possible.

When deciding between a top-down or bottom-up approach to software design, think of it like planning a trip. If you go top-down, you’re starting with the big picture, like choosing your destination and major stops, then filling in the details, such as the routes and activities. It’s great for projects where you need a clear vision from the start. On the other hand, a bottom-up approach is like exploring each neighborhood in a new city before deciding on the big attractions. You build from the ground up, focusing on small, functional parts that gradually come together to form the whole. This works well for projects that benefit from iterative development and flexibility.

Top-down acredito ser uma melhor abordagem quando se trabalha em equipe pois permite entender melhor o projeto, e, dessa forma, fazer uma separa??o melhor do trabalho para o desenvolvimento. Além disso ajuda a entender a extens?o do projeto, se vai precisar se escalável ou n?o, e agilizar o processo de desenvolvimento.

There will always be complexity in software systems. You probably won't need to design a very simple professional system, because it has already been implemented. To me, the main difference between Modular and Monolithic design is whether that inherent complexity is concentrated (and managed) in the code or in the architecture. A well-designed Monolithic system can be modular enough if you use the right design patterns in the code, but always needs to be deployed at once. A well-designed Modular architecture can be more easily managed by multiple teams with different release cycles, but should be deployable in parts. So the question becomes which of the two approaches works best with your company structure and business needs.

Modular is better approach hands down, BUT ... consider the entire system as a *monolith* to design your modules. Here are some considerations: 1. Take the entire system into account, as a monolith. 2. Break it down into modules, still keeping the purpose intact within the context of the monolith. 3. Define the inputs and outputs of each of these modules. This is the contract. 4. Define overriding principles and tenets, e.g. you may define a tenet that it has to have developed on a specific cloud provider. All modules must follow that tenet. 5. Design the modules, ensuring the contract is still intact. It's like building a jigsaw puzzle. You don't create the pieces first. You take the entire picture and saw off the individual pieces.

In my experience so far, neither top-down nor bottom-up is the ultimate silver bullet for every project. For most projects that I have worked, hybrid approach have worked the best where the overall system is designed top-down keeping in mind the business needs ofcourse but individual modules is done bottom-up. And just to make sure that the both approaches marry in the end, it's always best to have regular check-ins, reviews and feedbacks to ensure the goal alignment and mitigate any potential issues.

It is a critical decision is whether to adopt a modular or monolithic approach. Modular Design: This strategy involves breaking the system into independent, reusable units that communicate through clear interfaces. It enhances maintainability, scalability, and testability. However, it can introduce complexity and overhead in module communication and coordination. Monolithic Design: In contrast, a monolithic design constructs the system as a single, cohesive unit that handles all system functions. It optimizes performance and simplifies the system. Nevertheless, it can make modifications, extensions, and debugging more challenging.

A monolithic application may not always optimize performance or simplify maintenance. In the context of distributed systems operating at scale, transaction processing speeds vary across different segments of the overall process due to constraints in compute, storage, and network resources. Adopting an asynchronous module-based architecture enhances performance by mitigating these limitations. Furthermore, in a monolithic system, upgrades necessitate deployment across the entire system rather than a smaller, more manageable module, leading to increased maintenance efforts. The crucial factor in choosing the design approach during the initial phases lies in assessing the anticipated scalability of the application system.

The use of each paradigm depends on the project. Object-oriented programming is usually better for large projects with complex data structures and interaction between objects. Functional programming can be used for small projects with more basic data structures and a focus on data transformations and operations. Additionally, there are other factors to consider, such as testability and concurrency. Hybrid approaches can be used since in some cases some parts need to be object-oriented and others functional. There are many programming languages and frameworks that allow hybrid approaches that combine functional and object-oriented aspects. In many cases, I believe that the hybrid approach is the best solution.

We have heard from the client these questions "Why is the project taking so much time?", "I think there might be a misunderstanding about ..." etc, more when we are using the waterfall approach because the expectations and requirements of the system change and grow over time, and in most of the projects the requirements are unclear. Waterfall in small and simple projects might work and it is budget-friendly and takes less time. When we work on large-scale projects, it is critical that we involve the client and have more communication with the team. As part of the development process, we may also need to incorporate feedback from users or stakeholders in some steps. As a result, Agile is in line with modern standards.

While Agile offers flexibility and continuous feedback, it demands a ton of communication and a willingness to pivot. Waterfall, with its structured approach, promises predictability and a clear roadmap, but might not handle sudden changes in appetite so well. So, it's not about which one is better, but which one suits your project the best.

Project budget and Project timeline are the leading factors which contribute in choosing the correct design for the software delivery. Low budget and Short timeline could be delivered efficiently (both time and cost) with the waterfall design whereas the Long timeline with good project budget could be delivered gracefully with the Agile approach. Some of other factors which also contribute to deciding the correct approach are: Project complexity, Project criticality

Agile? Waterfall? How about Wagile? In the lifecycle of a product, from concept to maintenance, Waterfall methods often apply well at the macro level. Initial stages like identifying needs and detailing solutions have a more structured, linear flow. However, many claim to practice Agile while still doing upfront design, which is essentially Waterfall transitioning into Agile for software development. In my experience, true Agile delivery allows for design and development to run in parallel. The key to making this work is proper discovery and planning before initiating MVP delivery. Pro-tip: With certain Epics, let the teams decide what can be more tech-led vs. design-led.

I think, there are two powerful tools: design principles and patterns. Design Principles provide a foundation for effective design. They cover essential concepts like separation of concerns, modularity, and SOLID principles, promoting code quality. Design Patterns offer reusable solutions to common problems. They fall into four categories: creational (for object creation), structural (for object relationships), behavioral (for object collaboration), and architectural (for system structuring). By integrating these principles and patterns, you streamline development, ensure best practices, and create robust software solutions.

I think design patterns play a significant part in smooth execution of many projects.. while SOLID is the best framework to follow in detailed design KISS and Dependency Injection are the ones to follow in execution DI helps to write testable code, even if you define to write tests later it really helps in most big projects.

Design tools will save more time in onboard team members to the tasks and visualization is the best way you communicate and present the design to your team or stakeholders. Also, it gives the team a full visual of what you are building and implementing and how the services communicate with each other. do not forget to get feedback on your design after you finish that helps you to get more ideas and improvements from the team and learn from them as well

I am a strong believer in design thinking process of software development. You start with how the system will look like (user interface, user experience) and do a mock up. A graphical app will have mock UI; but a normal app will have the end results clearly articulated. Then go backwards and see how it can be accomplished, designed. In the process you may discover that the initial design of the end result wasn't adequate or practical. Tweak your software design then. This loop will persist throughout the development cycle.

Consider User-Centered Design (UCD): UCD emphasizes involving end-users throughout the design process. By understanding user needs, preferences, and behaviors, designers can create software that is more intuitive and user-friendly.

I approach software development as a creative and collaborative process that aims to solve real-world problems with elegant and efficient solutions. I understand that at times the waterfall methodology is the best fit, but I recommend and follow the principles of agile methodology, such as iterative development, continuous integration, test-driven development, and user feedback. I also value code quality, readability, documentation, and maintainability. I use various tools and frameworks to support my development, such as version control, smart IDEs, apt programming languages, and cloud infrastructure. Fail fast and be eager to learn new technologies and best practices to improve skills and deliver high-quality products is the way forward.

If we understand the issues with software output, issues with the design can be reduced. We make abstract output unlike other industries, where dimensions are known, specs are well defined and hence we know how the output looks like. This abstract nature of software creates issues later on. We can reduce the issues well in advance, if we have end users as part of the design process. And these end users should continue till the end of the development, an approach that can be termed as design thinking approach. Usually end users are not available through the entire lifecyle of development; this absence can be addressed by incentivising the end users through non monetary recognition, such as announcing their names during the software release.

My approach to software design focuses on creating scalable, maintainable, and user-friendly solutions by breaking down problems and applying principles like modularity and abstraction.