Professional Business Central Developers?

If you, like me, have been part of the Navision community since 1990, then you have seen a lot. 10,000's of members of Dynamics User Group (prev. Navision.net/NOLUG) have come and gone again. Some stick around and with time becomes dinosaurs like me. But a lot of them, we only see 1-3 months, then never hear about again. And while I don't know the exact percentage, but my guess that a lot of them, are no longer working with NAV.

At NAV TechDays 2018 two weeks ago, my friend David Singleton and had a session about The future for NAV developers and consultants. One of the things we talked about, was how our channel will need to double the number of developers within the next five years. If you didn't watch our session, then let me recommend it. Just remember to turn up the volume, as the sound is very low.

If we need to 10 double the number of customers and only double the number of developers, then a lot needs to happen. Most importantly then our industry needs to mature and do it fast. Especially we the developers, we need to become even better at our work. Everything we code in the future must be written with both repeatability and extendibility in mind. We all need to become "real developers", not continue as mostly self-learned amateurs, who barely knows what a design pattern is.

C/Side – a blessing and a curse

Navision and Dynamics NAV have always been unique. C/Side has been both a blessing and a curse. When Navision 3.0 was released in 1990 it's integrated development environment (IDE) was the very first of its kind. Here we had a platform where could customize all parts of the standard application, primary by just changing or adding properties in objects. And in some places, we could also program code. For this purpose, PC&C had created a development language (AL), which they had based upon the Pascal language. In the 1980'ies this was one of the most popular development languages in the PC world.

Most "developers" did not have a formal IT or development education or background and being a "Navision developer". And those who did, could not apply much of that knowledge to Navision. Everything in IDE was unique for our application, everything had to learned again. That made it more common to take an end user, accountant and turn them into a Navision developer, than it was taking an experienced developer and turn them into a Navision Developer. Business and accounting knowledge where more important that actual programming skills. That again let to a lot of consultants also changing the code.

Many, including me, started their career as consultants, and gradually became developers.

It didn't mean that partners didn't know what they were doing.

IBM Business Centers

Besides having a superior accounting package for the "new" PC's, then one of the main reasons why Navigator got both rapid growth a very good reputation in Denmark was that it was sold by IBM Denmark through a network of IBM Business Centers. These business centers were the only partners, who could sell both IBM PC's (PS/2's) and IBM-Navigator to Danish businesses. And they did it well.

To become an IBM Business Center, the partner had to undergo a rather long certification process. Their sales people, technicians, consultants and developers had to participate in week-long training, before they could go for the actual certification tests. Developers where not called developers, but system engineers and where basically trained to become Navigator specialists. We had to know everything from installing, setup, migration, training to development. It was neither easy, nor cheap to become a Navision partner at that time.

The program worked great and was a very trusted. And most IT managers knew, that if they just stayed with IBM, then they would never get fired for choosing a bad brand. Everybody trusted IBM back then.

Are certifications the answer?

Certainly not! It was not the certifications in the IBM Business Centers which made the difference. It was the week-long trainings, it was the way that IBM Denmark helped implementing a complete methodology covering all aspects of the partner – full package. It gave the whole company a boost in professionalism, compared to most non-IBM business centers, who instead had to sell the Navision "copy" XAL (XAL = eXtended Application Language from Damgaard).

Microsoft stopped certifying Dynamics NAV professionals a couple of years ago (2013?), when they dropped this requirement from their partners. Next year Microsoft will bring them back, according to announcements at Directions.

If these certifications are going to be the same type of test with typical multiple-choice questions, then they are worth nothing. Sure, it will require that you either study or go online and find someone who sells the answers for the test and then just memorizes the answers.

Other than showing that you can memorize, then they really show nothing. The only thing that truly works is training, mentoring and real-life practice.

C/Side retirement

In 1-2 years, Microsoft is going to retire C/Side. It will then no longer be possible to use C/Side or C/AL to make changes. We can then only use Visual Studio Code and the new AL language to program our changes.

That does not mean C/Side is dead. According to their terms, then they will continue to maintain it five years from its last release. If C/Side is retired in two years, then there will still come updates until 2025, even if no new functionality may be available. And there will for sure still be customers running it in both 10 and 15 years. Just was there is still customers running the DOS version, here 23 years after the Windows version was released.

That is going to be an important factor for Microsoft, to be able to get from 330,000 NAV customers to 3,300,000 BC customers.

For many years C/Side has been one of the reasons, why it has been difficult to attract new professional developers in the market. Methodologies and practices, like Agile, Scrum, SCM/versioning, object-oriented design, clean code, design patterns, test-driven development and CI/CD, have been known and used in other parts of the IT industry for decades. That's what students learns at the universities these days.

Sure, Agile and Scrum has made its way into our world, and we have visionary NAV community members like Luc van Vugt, Mark Brummel and many others current and former MVP's, who have showed that it can be done in our world too.

I'm looking forward to C/Side's retirement. What once was a blessing, has turned into a curse, that eventually, would have meant the dead of Navision. I just hope that more people in our channel had already embraced these new standards and methodologies.

Dinosaurs wake up!

Most NAV and BC developers do it the way they always did. No use source code management (SCM), DevOps or Docker, no focus on clean code, design patterns or test codeunits. Maybe on some projects, but not on everything. "Who would pay for it?" they ask. To them it is just means more costs, more stuff preventing them from billing out hours. They need to see beyond that.

We cannot make great high-quality software build for repeatability, extendibility and maintenance, if we do it the way we have always done. We have the tools, we need to stop seeing it as an extra cost, when all studies have shown differently. Even if you only do once-off projects, then it does cost more to do it right.

From before they were born

Why would graduate's, who studied 2-5 years to become professional IT developer's, want to forget almost everything and go to work in an industry, where almost everything is based upon the almost 25-year-old user interface in C/Side? Very likely from before they were born!

With a development environment in Visual Studio Code, that is no longer. Not only a (familiar) modern user interface you can use both on Windows and Mac, and no matter if you code JavaScript's or AL code. We get build-in Git/Github SCM, easier CI/CD with Azure DevOps, Pipelines, Containers and much more.

All these "standard" tools, that we now have available, will make it easier to attract new developers.

Except that alone will not do it. Even if they have the right tools, as soon as they find out that the projects and the development is done the way it was done 25 years ago, then they will accept the next job offer they get.

We either change the way we look at our profession or forget about attracting the best graduates and candidates. And forget making Business Central a success.

A Navision developer was not a real developer

I started as a NAV consultant/project manager in 1990 and first became a Navision developer in 1992. Still it took many years, before I started seeing myself as a real developer. I even studied programming in college, and I have over the years used over 10 different programming languages, excluding AL, C/AL and the new AL. In Navision most of our changes were simply changing a property or inserting a new field. Or a new report, with a few lines of code. Not a lot of "real" programming.

We didn't have to care about frameworks or all sorts of things to create UI or access our database. Instead we had all sorts of integrated tools to help to most of the actual code for us. Unless we exported as text, then we never saw the actual code.

We didn't have the tools to do it the right way, nor did we mis them. A new developer may initially have requested new tools, but we quickly learned them, they didn't need those tools for NAV development and that they just slowed us down.

We mostly did once-off projects and didn't have to care (much) about future upgrades. Eventually in 4-5 years that would be an issue, but not now. So, who would write test codeunits for anything? Today we know we were wrong, writing code we did, always ends up being spaghetti.

If I look back at those days, then although much have changed, then we still need to consider our-selves more as real developers.

We do not follow best practices

As Business Central developers we need to learn to respect our profession, to follow the same basics, standards, rules or whatever you will call it.

Most other professions do have some set of basic standards they must follow. You don't have to be a doctor, electrician, lawyer etc. for that to be the case.

For developers, especially NAV developers, that is not the case. We have no set standards, except the implicit "follow-the-money"-rule with often a very shortsighted perspective. We are not required to follow best practices or do our job to our best abilities.

But back in the early days our methods and practices where best practice, should I say best possible practices. Today we know that it is possible to write source code in a much higher quality, without using more time. Doing that would be "to our best abilities".

We accept buggy software

It is generally accepted that we deliver software containing bugs. Sure, as developers, we test it to our best abilities, but it's not really going to be acceptance tested until the "test phase", eventually by the consultant or when installed with the customer. Our input, our requirement may only have been a few lines and a screen shot, often with plenty of opportunities for our own interpretation, sometimes good, others not. Acceptance tests may not even have been described and signed off by the user/owner.

If we find a bug, and we will, then we write it in our Error Log, we have systems where customers can register their errors online.

If we were better at our job, then there would not be errors

Developers are expected to make software with bugs, and other people are expected to find and report them. It is not something we like, but everybody (?) knows that software has errors, so it is accepted.

We should not accept to have to deliver sub-standard, sub-quality software, when we know that there is a better way.

If we are told, not to do our best, then how can we respect our own profession. And if we, the developers, do not respect our own profession, how would anyone else, including new candidates?

Except of course, making it un-ethical to create bugs and unclean code, then I am not the one to dictate these standards. Uncle Bob has come up with his suggestion to a Programmers Oath (see link below), which could be a great place to start.

It should NOT be something that Microsoft is dictating to their partners and developers.

What should Microsoft do?

Microsoft have their #ReadyToGo program for partners, providing videos and training and more. They continue to improve our tools and make the industry standards available for us.

I would hope that they put more focus upon promoting methodologies and best practices for Business Central. Their NAV (C/Side) design pattern site did not get updated for a very long time and no new site for BC. Why not do this in a closer relationship with the community, the MVP's? Blogs are great, but they often get lost in the web. And don't limit it to design patterns.

And forget the certifications. If anything, then certifications is a hinderance from the required growth in our industry. It will move the focus on passing a test, instead of really becoming better and more professional.

They need to make developers feel that they can do everything with BC and AL, that they can do with any other platform. But better and easier.

Business Central and the development platform must become even sexier, to attract the best professionals.

What should partners do?

Nothing really happens without them. It is them who must see that Business Central is not NAV, and that extensions and Visual Studio Code is a much bigger change, than just a new language and development environment. Its an opportunity to grow. Developing everything as generic as possible, with test codeunits and CI/CD, is not an extra cost, but a way your software can be sold to many customers, instead of just one. Even if you are not building it (initially) for AppSource, then if you already have tests etc., then getting there will be much easier. And once Test-Driven Development, test codeunits, clean code and design patterns have been worked into your developers, then not only will the code be much better with less errors and much easier to maintain, but it will end up costing you less.

If they are hiring new developers directly out of college, then they should not introduce these to C/Side, much better that they focus on one environment. The partners need to figure out how many of their dinosaurs they need in BC. Even if learning AL is not a real challenge to most current NAV developers, and that we for sure are going to need dinosaurs in AL too, they are better of keeping them in C/Side.

The dinosaur developers need training in the modern way of developing, even if they have written code for 15 years or more. And they may need time to become just has effective with the new methods. Or keep your dinosaurs on NAV, only bringing over a few as architects and mentors, and hire new developers familiar with the new methodologies and practices.

And don't forget that successful test-driven development, requires the developer, issue/feature-owner and analyst to define/describe the tests/requirements together, before any code is written. It requires the whole team to be familiar with the "new" processes. The changes effects everybody, not just developers.

What should developers do?

I hope that all of us will find more pride in what we are doing, that we become better and more professional NAV and BC developers. We all need to invest hours of learning, its no excuse that your employer does not provide it for you in your work hours. There is an old saying, which says "You get paid to work from 9-5. What you do after work get your promoted?". While this may not get your promoted, then it will allow you to keep your job, if you want to make in the BC world.

Practices like TDD, is a whole new way of writing source code. It's almost like learning to write a bike again. At first you will feel that it slows you down, you may fell a few times, you may curse, before you finally get it. And when you do, you are not going to understand, how you ever been able to write software in any other way before. You are going to hate how code looked just short time again.

If you don't really care about all this and you just want to continue to do things has you have done "always", then stay in NAV. As said before, then you will still have plenty do the next many years.

If you still want to embrace the "new" development methods and practices, if you think it is important that we become more professional developers, then it's really easy. Start to study everything on clean code, design patterns and refactoring. Most here is rather generic, even if not all design patterns can be done with AL, so there are 100's of hours of video on YouTube. I can recommend anything by Robert C. Martin, Kent Beck, Martin Fowler. There are also many blogs about NAV design patterns and even TDD with C/Side.

Recommended for more information:

Youtube: The Programmer's Oath by Robert C. Martin (Uncle Bob)

YouTube: The future for NAV developers and consultants (David Singleton and Erik Ernst)

Blog: Luc van Vugt's dynamiXs, about automated tests, test driven development etc.

Blog: Mark Brummel, clean code, design patterns etc.

Site: Dynamics NAV design patterns