We use cookies to offer you a better experience. Click "Privacy Preferences" to read more about how we use cookies, and how you can control what data is collected during your visit.


Privacy Preferences

LeBLANC and NIH: Guide to smooth adoption

LeBLANC and NIH: Guide to smooth adoption
When you introduce LeBLANC and the machine-created application to your development team, you should brace yourself for the not-invented-here. We are human. This is a natural reaction that occurs on almost every adoption, as your development team has just been taken out of its comfort zone.

Not-Invented-Here

The Not-Invented-Here (NIH) syndrome is a well known phenomenon commonly encountered in the technology and development sectors, where teams or individuals exhibit a preference for internally developed solutions over external ones, regardless of the relative merits or efficiencies. This bias can stem from a variety of factors, including a sense of pride in one's own work, a perceived threat to job security, or simply a lack of familiarity with the external solution. While the desire to innovate and create is fundamentally positive, NIH syndrome can lead to inefficiencies, increased costs, and missed opportunities for leveraging existing technologies and methodologies that could accelerate project timelines and enhance outcomes.

What to expect?

When adopting LeBLANC, the initial situation is very much like that you’d be given responsibility to maintain an application created by someone else – the reactions are the same.

First, you’ll start hearing tens of different reasons from your architects and developers why you shouldn’t adopt LeBLANC: The architecture of the application is wrong. It’s using the wrong database, and the wrong webserver. It doesn’t use this pattern or this library that we are used to. It’s written in programming language we don't like. I don't even like the color of the user interface. These examples are all taken from real life adoptions.

The fact that the application is here, now, and works without single flaw, doesn't matter. It's not done in a right way.

Why NIH is nearly impossible to avoid?

There are hundreds of different of technologies, tools, libraries, architectures, patterns, styles, programming languages and components, that could have been used to create the same result. Because of this combinatorial explosion, nothing we provide can ever satisfy any architect or developer personal preferences - It’s statistically near impossible, like winning a lottery.

Overcoming the resistance

Overcoming this resistance requires careful management that address the underlying concerns driving the NIH syndrome, promote a culture of openness and learning, and demonstrate the tangible benefits of integrating LeBLANC into the development process. You get access to our Explore-documentation when you subscribe to our services, which gives you practical ideas on how to deal with the NIH you’ll encounter.

By our experience, the NIH-phase will last roughly two months. This is the time it usually takes for development teams to get familiar with the rationale behind the design, and the conventions used in the generated application. We at LeBLANC will help you though this phase – we’ll explain the rationale, teach the conventions, show the nuts and bolts so your development team can adapt, and get up to speed as fast as possible. We are used to this, expect it, and are well prepared for it.

Can our development team make it?

You can do it!

Yes they can!

A developer kept complaining about code intendation, which was not uniform across the generated source files. The mood escalated, and the whole team almost went on strike as the system wasn't implemented in a way they would have preferred or used to.

Yet, slowly they adapted. After the project was finished, the team was asked: Would you like to go back to the old way of doing everything manually?

The answer was No.

Our guiding principles on technology

Everything starts with understanding. If you are considering adopting LeBLANC, these are our guiding principals in design decisions:

  • Use of battle proven architecture in thousands of similar line-of-business applications.
  • Provide standard solutions to requirements recurring in every application.
  • Keep the architecture as simple as possible (but no simpler than that)
  • We enable (and not block) you to customize and extend the application in any way you need to.
  • Components are selected according to MS best practices and are proven to work seamlessly together in implementing secure and scalable systems.
  • The runtime platform allows to both extend and integrate with anything Azure offers, for example in terms of adding security, analytics or AI – anything your system may require.

Path to successful adoption

Adopting LeBLANC may bring initial resistance due to the natural discomfort of moving away from familiar practices, but this phase is temporary. Through careful management, open communication, and support from our team, your developers will soon appreciate the value of the approach. By focusing on proven architecture, flexibility, and enabling customization, LeBLANC offers a solid foundation for building secure, scalable business applications.

In the end, the benefits of reducing manual work, streamlining processes, and having a system designed to be extended to meet your needs will outweigh the initial challenges. With the right approach, your team will not only adapt but come to rely on the efficiencies and capabilities that LeBLANC brings.

Happily adopted!

Author's note: Sorry for the overly cute images. Got carried away with Midjourney. Hope you understand.