Como você avalia o uso de ferramentas de desenvolvimento de software versus a construção de suas próprias soluções?

As part of our MB.OS software development process, we have created a private marketplace to provide software tools for our developers. This is called MB.OS Studio and it’s a modular, cross-platform environment, using Visual Studio Code as a base, and is accessible in the form of extensions. One is called GitHub Copilot, which uses the OpenAI Codex to recommend code and complete functions in real-time. Copilot can vastly improve efficiency, by suggesting lines of code, allowing us to produce code faster. It also helps with the associated documentation. This isn’t a perfect code-writing solution, it still requires user input and review, but it gives our programmers more time to focus on complex problems and the overall software architecture.

To explain one of the biggest reasons for buying instead of building, let’s take an example of an Analytics tool. For your team to build the Analytics tool internally is 1 more added on to the existing 100 things to work on. Instead, if you buy a tailored product, the entire team is focussed on just building the best Analytics tool. Also, we also need to take into account the cost incurred not to just build but to keep adding features, managing the system, cost of not working on your core product and cost of moving slowly in a hyper competitive world.

Unless you're operating in an extremely exotic niche, there are plenty of great tools available, and in general, the question whether or not to use them is like, "should you use utensils when eating food". Of course each organization and each individual should consider carefully which tools best suits their needs. Some tools can be overkill, or actually lead to overhead losses (licence costs/management, compatability and learning curve issues, etc). A good software developer knows exactly what he's missing and is not too complacent to strive for a good solution. If need be, he'll write his own tool that does the exact task he needs, better than any generic tool can. You know the craftsman by his tools.

It’s like suiting. In early stages, you usually wear whatever is available in the market, later on you realize the elegance of suits tailored to your physique. It’s also about the budget. In software, it would depend on the type of business you are in. If it’s an early stage startup, it might be better to pick up tools and work your way through. For large scale corporates, they will probably hire people or a company to build tailored software for them.

Using software development tools gave us quick access to multiple complex functionality in no time. For example using Google Cloud Platform enabled us to build a sophisticated authentication system in the mobile app. Doing the same from scratch would take many weeks.

I value the insights shared by fellow contributors. Software tools come with unique challenges but are also immensely helpful. In my experience, I see these challenges more as chances for growth rather than strict problems. Let me explain: 1. Tool Dependency & Updates: We rely on tools, and updates can bring unexpected changes. Think of it like caring for a car; updates are regular check-ups for smooth operation. 2. Learning New Tools: Mastering a tool is like learning a new language. With time and effort, we unlock its potential. 3. Tool Compatibility: Ensuring tools work together is like orchestrating a symphony. Looking forward to more discussions and learning from our expert community.

It depends! If an in-house solution is already using a particular tool-set, then sure it makes sense to build on top of that. There will be a point where you may outgrow the tool though and you suddenly, though not necessarily obviously, will curve innovation to keep maintaining a tool, not your product. Alternatively, I don't always use tools foundationally for bespoke products. Build natively, if that is for the web or certain view-ports yes that includes HTML, CSS & JS. Why not see how far you get before adding a tool or dynamic functionality. Coding languages are tool-sets too, not just the libraries. Use only what is necessary. Remember KISS.

Initially the software development tools looks a huge burden for all developer, after some time as the software engineering team start to use and continuously refine the tool to cater the needs of software developer will be really appreciated.

I would argue there are challenges rather than drawbacks of using tools. Some challenges are typically easily identified and addressed like the learning curve (addressed with competence development) and the risks that the dependency to a tool creates (typically known when selecting the tool and either mitigated or accepted). Other challenges like how to scale usage (both in terms of operations and way of working) and how the holistic tool landscape should look are far more complex and, in my experience, often the source of more issues. I therefore recommend focusing more attention on these challenges, with communication and collaboration (internally and externally) being a key to success.

When an organization decides on a software development tool, there are many considerations that impact the success of that tool. If it is proprietary, then the organization is tied to the vendor that owns the tool and update or patch cycles may present problems. Open-source tools may allow the organization to perform customizations and updates on their own, but at a cost of a steeper learning curve to understand the architecture of the tool and how maintain it. Other challenges will arise with regard to staffing. Do the developers they hire, have the expertise to work with these tools. Many companies spend a fair bit of their budgets on training so adopting a well known tool, may help reduce the need for additional training.

We developed our own operating system to offer best-in-class technology across our entire architecture. Our MB.OS technical foundations include an in-house-developed chip-to-cloud architecture and scalable proprietary vehicle software platform. This decouples the development of hardware from software and ensures safety and privacy for our customers. Taking full responsibility as architects of both software and hardware development accelerates our development and allows for continuous innovation, which results in better products. Our developers can take over end-to-end responsibility and create customer products from scratch to lifecycle management.

Having a solution developed inhouse can help to integrate any test tools for quick quality check and easy to execute and take a report. Visteon has developed solution for quick build and it eliminates few steps which are not required and can drastically improve on the developer efficiency and productivity.

Absolutely, building your own solutions is like being a digital architect. 1. Control & Flexibility: Craft solutions to fit your needs like a tailor making a bespoke suit. 2. Unleash Creativity: It's your canvas for innovation, like composing your symphony from scratch. 3. Uniqueness & Innovation: Stand out by creating unique, value-packed products. It's a journey of creativity, empowerment, and endless possibilities. Can't wait for more insights from our experts!

Building solutions, whether in the context of software development, problem-solving, or project management, offers numerous benefits. Solutions are typically designed to address specific challenges or meet particular goals, and their development can lead to positive outcomes. Building solutions empower individuals and organizations to overcome challenges, achieve goals, and innovate. It offers control, customization, and efficiency, leading to improved processes, experiences, and competitive advantages. While building solutions requires effort and resources, the benefits it can deliver make it a valuable approach in many contexts.

Sometimes, build own solutions could help to avoid critical issues in common tools, an example, build a custom database framework for Java instead using an external solution, as Hibernate, you could assure that your system could prevent a SQL injection. Also you could customize all the flow according of the domain of the system.

Creating your own solutions comes with challenges, like any creative task. Cost: It's an investment, like a DIY project, with potential unexpected expenses. Time: Similar to solving complex puzzles, it can take a while. Quality: It needs careful attention, like maintaining a classic car. While there are obstacles, the sense of control and being unique can be motivating. Looking forward to more insights from our expert community!

Apart from cost, time and quality , home grown tools will always be dependent on the in house resources. If there any change in platform direction or any method the whole tool has to be revisited again.

Building custom solutions offer more flexibility and control than using off-the-shelf tools. It may also provide a competitive, if significantly differentiated from what is available on the market. Furthermore, development of custom solutions are, in my experience, often perceived as fun and exciting by the developers. Thus, building your own solution can increase motivation in the workforce, at least short-term.

When you opt to build your own software solutions, you'll often find that it consumes a considerable amount of time. There's no guarantee of quality assurance, and what can be particularly discouraging from my perspective is the need to address what can be termed as "childhood diseases." This involves tackling initial issues and challenges, which can be mentally taxing and disruptive to the development process.

While building solutions can offer numerous benefits, it also comes with potential drawbacks and challenges that individuals and organizations should consider. 1. Time-Consuming 2. High Initial Investment 3. Resource-Intensive 4. Risk of Failure To mitigate these drawbacks, it's essential to carefully assess the feasibility, cost-benefit analysis, and long-term implications of building custom solutions. Adequate planning, project management, and ongoing evaluation can help ensure that custom solutions deliver the intended benefits while minimizing potential downsides.

Deciding between software tools and building your own solutions is like choosing between baking or buying a cake. Custom Ingredients: If you have unique needs, you bake it yourself or hire a custom baker (build your own solution). It's tailored to your exact requirements. Specialty Baker: When you need something specific but not entirely custom, you visit a specialized bakery (domain-specific vendor). It's like buying software from experts in that area. Ready-Made Convenience: For basic needs, you grab a cake from the grocery store (cloud provider's managed service). It's cost-effective and convenient for common tasks. Ultimately, the choice depends on your project's recipe. Looking forward to more insights from our expert community!

"Innovate where you add value. Leverage existing tools and third-party services for everything else." I find this framing useful when teams are faced with the "build vs. buy" decision. In addition to guiding short term decisions, it can also serve as a guiding light to ensure the team is following their vision-to-values mission statement.

Choosing to build or buy is like choosing to make or buy a cake. If you have specific needs, like particular ingredients or design, make it yourself or hire a custom baker. This is like having specialized software requirements. Build it yourself or hire a service firm if you lack the skills in house. If you need something nice but not too specialized, go to a bakery that specializes in your desired cake type. This is like buying software from a domain-specific vendor. You won't have to build it but will still get a solid feature set. Or, if you need something basic, pick up a ready-made cake from the grocery store. This is like using your cloud provider's managed service. It's cheap, convenient, and sufficient for common use cases.

Build a tool only if: 1. The functionality is core to your product 2. You are willing to commit significant time and money to its development, support, and improvement 3. Paying for a tool would cost much more than developing it inhouse

I would always suggest to go with build own tools by considering the simple method to solve the complex problem. In Automotive embedded software development the tool chains are complex and need a quick turn around, hence it is better to create a solution for the problem that the developer is facing.

writing clean code. This approach doesn’t just involve producing code that machines can understand; but also creating an easily understandable, modifiable, and maintainable codebase for human collaborators as well. Clean coding demands consistent style choices with purposeful naming practices as well as an emphasis on simplicity.

We maximize our software competence with a network of development hubs all over the world. The center of our development network, integration, validation and testing takes place at our Electric Software Hub in Germany. It facilitates an efficient global developer workflow and effective communication with our vehicle R&D and production experts. Our other global hubs individually focus on UI/UX design, AI, infotainment, localization, telematics, automated driving, battery management, cloud services and cybersecurity. Our global footprint helps to get the best talent on-board and ensures that we are close to our customers.

A good rule of thumb is if the solution is part of your company's core competency or competitive advantage, it should generally be a custom build. Otherwise, the value added often doesn't outweigh the typically higher costs of building custom software, especially when taking into account the long-term maintenance costs.

Investment into tooling is not a one-off investment. Tools need to be maintained; life cycle management is far too often neglected causing issues and lost opportunities. Furthermore, the tool landscape and associated roadmaps must be continually reevaluated and adjusted to best support developers and stay competitive in a rapidly moving software industry.

Forcing a choice from one of two options (build vs buy) misses the third option. A hybrid approach can be used as well. The right mix between build vs buy depends on the capabilities you are trying to build. If you lack certain capabilities, no mix of these options will magically provide the capabilities (despite any product claims). You also need to consider whether a platform or discrete set of tools will fit your needs. Your choice may reveal the need for additional capabilities. If you decide to neither build nor buy, an outsourced partner can help you ease the burden by providing essential artifacts (test results, pentesting results, etc) as you need them.

I am really wondering, why all contributions are just talking about tools for creating code. Code creation is the one of the lowest value creating processes in SW Engineering. What about architecture and Design? How to significantly increase efficiency for traceability management? How to easily ensure full test coverage on requirements? This is the real pain of the engineers when it comes to SW in automotive environments especially with safety levels >=ASIL B.

In my experience, there is a key question you should ask yourself to decide whether to build your own solutions or use third-party ones: "What is our business core, and what constraints do we face?" It is usually a good idea to focus your efforts on developing your business core, where your strengths likely lie, and rely on well-proven external solutions to solve secondary standard problems. However, you must know what your requirements are, e.g., performance, compatibility, or licensing, and make sure that any external solution you use meets all those prerequisites. Here, you might face some constraints, like budget limitations or unmet requirements. When there is no viable external tool, then you should build your custom solution.

If there is no tool or library for you. Create it yourself and publish it as an open source, you will see surprisingly how much the library or module you wrote with the participation of other developers in the community can help both you and other software developers.

For me, building vs buying comes down to one question: "What is the problem our business or product is going to solve?". Don't buy something that is a core part of your value proposition. It's hard to impossible to actually differentiate yourself against others when you buy that. Best example is all the startups using the openAI API for the generative AI startups. That's just bad business.

The most important thing to consider is as you create your own code/software it's extremely important to document them correctly. Technical documentation goes a long way in helping future developers to enhance or utilize existing features.