It’s Okay To Break Tradition
The Status Quo
Tradition is an interesting thing. It’s the way things are. It’s the way things have always been. You go with the flow, because that’s how things are done. You know it as the status quo.
The status quo is a good thing, because tradition is tried and true. Why else would you do things the same way for so long?
Why—that’s the question. And it is a very important question.
Sometimes the answer is a reasonable one: You do it this way, because it has been proven to be the best way.
Unfortunately, the answer is often a self-referencing let-down: It’s always been done this way because this is how it has always been done. In other words, nobody remembers why, so we just carry on the tradition.
History is teeming with examples of unchallenged assumptions that often leave us wondering why things are the way they are. You’ve likely heard of some of the more popular ones (although some are controversial).
Typewriters were designed with the QWERTY layout to prevent jamming when the operator types popular key combinations too quickly. This makes no sense on computer keyboards today, but the layout is still entrenched as the standard.
NASA rockets have design restrictions that have made their shuttles longer and narrower than preferred. This is a strange consequence due to the origin of railway gauge (the spacing between the two tracks), which has a long history of following tradition, dating all the way back to Roman chariots.
My Personal Case Study
About four years ago, my employer decided to replace the custom software solution for our network of dealer-owners. We had a home-grown point-of-sale with an integrated inventory system, which was built from the ground up for our business. However, we needed to replace our product because it used dated technology and required an integrated general ledger.
Bolting on such invasive and fundamental functionality was not ideal, so our business analysts decided it would be better to replace our home-grown solution with Microsoft Dynamics NAV, which we could further customize to fit our needs.
Fast forward to a year later. Our developers and business analysts have been trained on Dynamics NAV development and basic workflows. We are now working alongside some experienced consultants to begin customizing the product. Things are going well and we are picking up velocity.
Then, we realize something isn’t quite right. We are developing a software solution, but we are not using source control.
Where Art Thou, Source Control?
I remember asking the consultants how companies integrated source control with Dynamics NAV. The consultant said, “Oh, that’s not how it’s done in NAV.” I was blown away.
Dynamics NAV stores all code inside a database via objects (objects are tables, pages, code units, reports etc.). The idiomatic NAV development process has developers work in a shared database so that they have access to each other’s code changes.
Since we were the new kids on the block, we decided to go with the flow and continue working this way. What did we know? They were the experts. So we worked in a shared database and followed the lead of our consultants, trusting that this was the best way.
As the project moved along, we began to run into issues. If someone was working on an object you needed, you had to wait for him or her to finish with it first. If a change to a table or a function signature was made and the object you were working on referenced that object, you would suddenly start getting compile errors.
To put it bluntly, things were horrible.
These issues are precisely what a distributed version control system (DVCS) addresses. We decided that we needed to introduce source control to the project somehow, and ran some ideas past our consultants. They were very opposed to the idea. We heard all sorts of excuses:
- There are no tools for Dynamics NAV that do what you are trying to do.
- If you make your own tool, nobody else will know how to use it.
- Learning a new development process will slow us down too much.
This was dangerous thinking. Although the current development process was widely accepted and worked for the most part, it was problematic and far from ideal.
Where would we be today if we didn’t challenge accepted models to make better ones? Perhaps we would still think the Earth was flat or that the Earth was the center of the universe. Those ideas were challenged by new models that we accept today, but they were initially rejected (perhaps by fear of change).
We decided to challenge the status quo and build our own tool anyway (see Soft Skills: The Software Developer’s Life Manual for a great chapter about facing fear head on). This was right around the time we were ready to walk on our own and continue without the consultants, so the timing was perfect.
We quickly discovered that building the tool required solving some challenges. We kept at it, and after about six months of development, and a few months of using the tool every day—making adjustments and improvements as we learned along the way—we ended up with a process that we were very happy with.
We now had the ability to code within our own local databases without interfering with each other. There were no more half-finished features polluting the code base for the other developers. We could follow standard DVCS practices to merge our changes together, create feature branches, and track the history of our changes. As an added bonus, our DVCS was integrated with our bug tracking software.
Fast forward another year.
We hired another company to help with some consulting as we delve into new areas of the system. At this point, we had our version control tool in full swing and decided we would train the consultants on how to do things our way.
At first, they were a little hesitant and skeptical, but they decided to give it a try and eventually warmed up to the idea. As they became more comfortable with the process, something great happened. They went back and shared our process with the rest of their company.
What a rewarding feeling! If you’ve ever felt something wasn’t right and that it should be improved, don’t be afraid to dig in and give it your best shot. You may face obstacles and strong opposition, but if you are persistent and have strong conviction, you can accomplish great things. You may be surprised how your determination and belief can persuade or even inspire those around you.
A few months ago, some of us attended a workshop that this company put on for their partners. The seminar covered using source control along with a tool they had created as a bridge between Dynamics NAV and Git.
Their new tool was inspired by the tool we had created! They had even come up with some great improvements and features we had not even considered. This in turn has encouraged us to continue making improvements to our tool.
Now, a great portion of the Dynamics NAV development community seems to be very interested in source control. Microsoft has begun to release PowerShell integration tools to make source control easier for Dynamics NAV. Even Microsoft Most Valuable Professionals (MVPs) have been creating similar tools such as these, and using Git with NAV.
Some of us from my company decided to start blogging and sharing ideas about our tool and the source control process as it applies to NAV. We’ve actually been contacted by a few companies asking if we can train them on source control processes and if they can buy our tool. How cool is that?
We didn’t start a Dynamics NAV source control movement, but I’d like to think we were early adopters and evangelists that have helped the process spread. The development process is headed in a better direction, and that is good for the community.
So the point of this story is that you shouldn’t blindly go with the flow. Challenge assumptions, ask questions, and lead by example. Don’t be afraid to hop out of the river and take a look around. There may be a better way to get to where you’re going. You may even inspire those around you to do the same.