There are so many approaches to developing software and each has its adherents that feel like their way is the only way. I am of the opinion that there is always a correct way to do anything and we sort of label that it in our industry as a best practice. Best implies it is superior to all other alternative approaches. I doubt there are two ways of doing anything that are different in procedure and equivalent in getting the result. If one were to bake cookies, there are undoubtedly a multitude of permuations on how to do this. Some may result in equivalent cookies in terms of quality but they will likely be different in some other aspect, like the time it takes from beginning to end, or the cleanup time required. So sometimes it is not obvious which is the best approach if the end result is the same. It takes measurement to determine that and few people have the stomach. But as programmers, we have all been guilty of shortcuts, like hardcoding data in a source file that really should come from a data file or configuration file. Often these practices filter in during crunch time. We do it to get a project done, but we probably haven't thought about the other factors, like reusability or maintainability. Both of these come into play later on. If you are not reusing code very much, then you are probably sloppy in design or implementation or both. At least that's my take.
I have had a lot of major realizations recently about doing things the right way. For example, I just finished a module that is highly resuable and I will probably make use of it in many applications to come. It took me about 2-3 days to complete and I doubted myself throughout the development. I wondered if this was really worth the extra effort. But I made a decision early on to push through the development of this module, regardless. I could have stopped at several points with the idea that it's good enough. That has been my operating basis for a long time. It's probably in some respects due to my engineering background. Engineering doesn't always seek the best solution but the one that makes a lot of sense considering a multitude of other factors.
So what module did I develop? Well I've been wanting some binary files that could be created from a build script. The binary files are created from a CSV data file and an XML schema file. I created a console program that takes these input files as arguments and creates an output file in a binary format that is compatible with a Delphi memory table component that I use. So binary files created in this way can be read by an application at startup (or first demand) and are held in memory for blazing performance. The other approach was to add fields manually to the component through a dialog box interface that is a bit clunky. It works, but it also means I have to do this for every memory table in every application from now on. It means populating the data in a grid and then saving it to a binary file. That means I needed a helper application to enter data. Sure it's an easy application to write, requiring a grid, a memory table, a data source, and a database navigation bar. This helper application is also not very friendly to reuse because each application may have a different schema, which means editing the memory table fields and so on.
With my new module, I am now able to keep in source control the XML and CSV files and let my build script generate the binary files, much like a compiler generates binary executables. The nice thing about this is I now have a mechanism of great reuse. I can simply create a CSV file (in Excel no less), and document my schema (also very easy) and then put the result in a FinalBuilder build script and I'm done with input data. In my application, I have a helper class that enables me in one line of code to load that binary file and it's in memory for my application to use.
Well I did spend some time doing this, but I also documented my process and I will be using it in a lot of applications from now on. It is a pay now, save later proposition. I believe it is essential to create some future savings in one's development situation. Time invested now will be saved later, and saved later with interest. Of course you have to evaluate whether you will ever get the time back. It may not make sense in every circumstance. You have to use common sense and work out whether it is a correct decision for your immediate scenario. I give the benefit of any doubt to building it the right way. There is a high likelihood that you will find ways to reuse it and your estimates of reuse could be on the low side.
Comments