|
Article Publishing
|
~ modular software construction defeats upfront fear |
For medium or large software projects (example: a single desktop software application) it can be extremely useful and to develop sections of the software at a time, instead of developing the application itself.
Extreme fear and anxiety in a software developer's mind will persist throughout the entire application development stage, if the application is a large or medium sized project, due to the shear size of the project. Developing only section of the application as a separate executable or program, that only completes one portion of the software, makes it much easier to make progress in the development of the entire application. Call this section or separate executable a "module". After the module is completed, even if it is a separate stand alone demo or prototype executable on its own, it can then be pieced into the actual application later.
Example: a software developer is developing a professional spreadsheet editor. It needs to have a built in comma separated format reader in the application, to open CSV files. However the application needs to be developed, the CSV reading feature is only one tiny issue that needs to be addressed: so the developer fears the entire application needs work first. However, it will be more productive in this case, if the programmer has his mind on CSV, to start a separate project that only parses, reads, and possibly writes CSV files - then store that small project on a source control system or save it to a USB stick. That module is now completed, and the code in that separate executable that just reads/writes CSV files can later be cut/pasted into the spreadsheet application. Instead of the CSV read/write feature being added into the monolithic application itself, a separate project is started just to complete that module as a stand alone demo/prototype or even fully functional CSV tool. Then, later when the spreadsheet software is still in development at some stage without any CSV features, the programmer looks through his source control and finds the CSV code, cuts the code out required, and adds it to the main spreadsheet application, hooking it up to widgets, gui, or menu items.
If a software programmer is bored and overwhelmed with the large monolithic application being developed, often it is useful to work on only a small portion of it that he finds interesting at the time, instead of being overwhelmed and anxious about the entire application, which is daunting.
This method of software development does not just mean separating the large program into separate source files, say namespaces, classes, units/modules. That method of development can be useful, however it still leaves the entire monolithic application in a single project, which is overwhelming and daunting. Instead, to reduce the fear and anxiety of contemplating the entire software application, a developer can actually start several small spin off projects that complete sections of the software, which will later be pieced together into a large monolithic executable or application. Even if the monolithic large software application was cancelled or de-funded, or put on hold, now the software developer has several small programs or sections of the application that are still useful by themselves on their own, or, useful if pieced into an unrelated different software project that could use that code. For example, a CSV utility to read comma separated files is not only useful in a spreadsheet hooked up to the GUI menu items and widgets, but also useful in an internet program that displays data on a web page, even if that web page has nothing to do with and is completely unrelated to the spreadsheet software.
It is easier to scroll through a small github/cvs/svn project than a huge monolithic million line, multihundred file one. If the code is developed in small sections or projects that even can run separately in their own executables, now the source code is easier to sift through on source control if a programmer simply looks at one small utility on source revision, instead of the large monolithic project. This comes at a cost of some duplication. There will be code stored in two places instead of just one: in the large monolithic application project, and in the small utility in a separate github project.
One reason software projects are stalled or do not get completed is because the size of the project is massive, and causes developer fear. Some websites have been named after it such as "coding horror". However working on small sections that even run separately as separate programs, does not cause nearly as much (if any) fear, and makes software development fun and enjoyable, as more projects (small sections) are "completed" and finished, rather than the entire monolithic large application being left unfinished for months or years.
It seems pointless some times for a developer to add a small but needed feature to a large application when the entire application skeleton or major main section has not been completed yet: what seems to make sense to a developer is to finish the major portion of the application first, then add small but needed features later. However this can cause the application to simply stay stagnant due to the main section of the application being a daunting task. Instead of focusing on the big picture (large application), a developer can pick a small portion of the software that he finds interesting on a certain day, start a separate project for it, and complete it as a fully functioning small program or demo. Then on another day, work on another section of the program again as a separate project. Later these small separate projects can be peiced (cut) in and placed into the main application, especially if the programmer is skilled at such design where small peices can exist separately on their own (modular design). On other days the developer will have some interest in working on the main monolithic large executable that holds all the code together - these are good days, as, it is the big picture - but these days can be haunting and cause the developer to stall, procrastinate, or be in fear.
Separating small sections of the application into separate standalone programs has another large benefit: debugging or formal verifcation, and understanding of the code. Small sections as small separate programs, are much easier for a programmer to understand in one sitting, than a large monolithic application (possibly hundreds of thousands of lines of code, or dread, millions). A program that has any issues, errors, or difficult areas of research, is much easier to understand, debug, and even formally verify or prove, than a huge monolitic application. A programmer will be able to isolate, fix, and understand any issues much easier if the working source base is only a few hundred lines of code, or a few thousand, than if it is a million. All (or many of) these small programs will still end up in the large monolithic executable at some point, so if an error occurs in the large monolithic executable, it may be easier to troubleshoot it in a smaller program, or determine if the main application code (that holds the application together) is the issue, or just that section of code is the issue. Many times, the main application will be difficult to troubleshoot since it is such a large source base. Also, some times the error will not occur if it is code in a separate small program, due to other application code causing the issue (main application skeleton code). The error or issue may be further understood if some other application code is causing the issue that connects it to this section of the code which does not have the issue, which it was initially assumed... i.e. gui widgets or other code could be causing a bizarre hard to detect bug. So separating the code into small programs (modular), even if those programs are not used separately in the end very much, is extremely useful.
In fact even operating systems are designed in such modular ways: if the operating system was one large monolithic program that had no applications to install (the operating system was all you needed, and it was just one huge program without any executables, files, modules), it would be much harder to isolate issues. Unix developers encouraged developers to write one small application that did one job - this was taken a bit far, to the point of extremism, where unix users had to pipe multiple small programs at the command line to connect to other tools. This can get tedious at times, instead of having, say a large bloated executable that did multiple tasks (there are costs and advantages).
This article will contain more in the future, and needs proof reading.
|
|