This is the second post in this series if you have not read the first post you can do so here: AL Developers we need to do better – Part 1 – Fredborg
In this post, we are going to look a little bit more at the workflows that many of us need to improve, so this is not really going to be focused on code but more on things that many of us should do better, myself included.
Stay up to date
Back in the old days of on-premise solutions, we did not have to do that much to stay up to date on new things being introduced to our product , sure Microsoft would come out with a new version once a year, but not much really changed from product to product, and the way that many of us could stay up to date was to attend NAV Tech days, and we would get a sneak peek at some of the new features coming to the product by the MVP’s in our community , and everyone was happy, now do not get me wrong I still think that attending conferences like BC Tech Days and Days of Knolwedge give incredible value, but the problem is that it is not enough anymore , because our product is evolving at a pace that going to a conference once or twice a year is not enough, we need to actively search new information and stay on top of what is new and what is changing, and the way to do this is by following the MVP’s blogs, and another great resource is to follow Erik Hougaard on youtube where he takes a look at new versions from the coding side, and last you need to keep up with Microsofts release notes. Now, this might seem like a lot of work , because many of us also have a family life and social life that we need to take part in, and luckily there is a new cultural movement where there is an excellent focus on work-life balance, so what should we do? well, my view on this problem is that once a company reaches a certain size, you need a person or persons where part of their job is to keep up to date on everything that is changing and the informing the rest of the developers of what they need to know , now I know the problem that many consulting houses are going to say to this, is that it is too expensive because the time these people spend on reading blogs, watching videos and so on, is time that is taken away from billable hours, but this mindset needs to be challenged because we need to think about what is the price of falling behind? one price is that the developers do not use the newest features and thereby not creating the best product for their customers, which can result in them losing that customer to a competitor that can deliver a better product, another price can be losing employees because many developers got into the field because they like the concept of always learning new things and having to adapt , and if they feel that they are a place where it is not possible to grow they will find somewhere else where they can, leaving you with the developers whom either cannot find other employment because they are not attractive to the market because they are not up to date, or they are staying because they do not want to learn something new, which means you will be stuck in the past.
Code review
This really should not need much explanation, but we need to implement code review as part of our workflows , and this has never been easier than now since we all now use source control, and as part of the workflow in source control tools, you can add in code review as a requirement. But what is so great about code review? It is quite simple, code review is not only a concept that is used to ensure that the developers write the best code possible, but it is also a good way to teach your colleagues not only by telling but also by showing because the idea behind code review is not for a senior developer to read the code of a junior developer and then telling him all the things that he has done wrong, but it can also be used for the reviewer to read some code and learn something new, by seeing how the other person has solved a given problem, so you should not view code review as one person checking if someone has made a mistake, but it is just as much a way to share new ideas and concepts. Much like the problem about staying up to date, you are going to run into the problem that our bosses are going to say that code review should not take too much time because it is not billable time , and that is again one of the biggest problems in our field because everything comes down to how many hours can you bill to your customer, but we have to be careful about this line of thought. Now I would recommend that all developers perform a code review on all code, and then once in a while you might have a head of development who would look through the extension as a whole, to make sure that everything is in line with the guidelines that the company has agreed upon, much like you have IT audit, you should internally have a code audit by someone who knows all the guidelines and new technologies, and thereby doing a sanity check on your extensions.
AL Guidelines
In any team or company, you should agree on a set of guidelines that you should stick to; a great place to get inspiration to find some good guidelines and design patterns is alguidelines.dev – Business Central Design Patterns and while in a perfect world, we would adopt all of the guidelines from alguidelines.dev it is more likely that you should choose the ones that make sense, but how do you choose which ones to use, well that is completely up to you; but it is a good idea to have someone analyze the different patterns and decided which ones are easy to adopt and find a person or persons; that is responsible for choosing the ones that your should use and the best way to implement them. That being maybe creating a list of snippets that makes it easy for anyone to use them, and also keep them up to date because there are always coming new patterns and some of the old patterns might no longer be relevant or might need to be updated. Also if you know a good design pattern that is not already on alguidelines.dev you are free to add it yourself since it is community driven.
Full Stack
The days of only knowing one development language or technology are gone, and this is true for any field of development, and BC is no different we as developers need to be open to learning new technologies and accept and learn the low code / no code movement, but we also need to be able to at least have some knowledge of web development and .NET development, not that we should be an expert in every field, but more that we need to know what tools are available so that we can be part of the solution as a whole, it has become very popular to have a lot of architect roles, which is fine, but we should really all be architects on our own solutions so that we can help our customers find the best solutions using whatever tools that are available, so basically we need to be open to learning new technologies and development languages.
Boy-Scout Rule
The idea behind the Boy-Scout rule is that we should always leave the code in a better state than we found it; and what does that really mean? well, it means that we need to constantly refactor our code base, however, some of the reasons why we might not be doing this as much as we should is because, first that if we did not write the code then is it not our responsibility, and to get around this problem we have to adapt the concept that no one owns the code, once it has been pushed to your release branch, that code is no longer your code, but it is the solutions code and therefor anyone is allowed to change it, the second reason why we do not refactor code is, that we are afraid of breaking the code; to solve this fear we need to implement unit test, which is something that we will cover in the next post.
That is it for this post, until next time stay safe.