Introduction to Software Manufacturing

The goal of the CIYAM software engineering methodology (known as Software Manufacturing) is to give developers a way of quickly producing quality applications through the re-use of tried and tested software components and source code.

The goal in itself is not really much different to what you would expect from nearly any software platform but what is most different about CIYAM’s Software Manufacturing approach is that applications that are constructed with it will not contain any manually written source code.

This perhaps requires repeating to underline its importance, there simply is no manually written source code in a completed software application that is constructed using CIYAM’s Software Manufacturing methodology.

No manual source code - really?

This is a point that many find rather hard to swallow and it needs to be carefully explained so it is clear as to exactly how this works (as there is nothing “magical” going on here).

Beyond the standard application modelling artifacts (such as classes, fields, procedures, etc.) there are more detailed artifacts known as “specifications” that provide a means of using source code snippet templates which (for the most part) will be “tried and tested” (read on) that operate with the other model artifacts.

The obvious question now arises - “What if no existing specification (or set of specifications) can be used to generate the source code desired?”. This is a good question and a core part of the difference between this and other methodologies. The answer - if required you protoype code manually and after thoroughly testing it works you transform this code into one or more new source code templates and create one or more new “specifications” which will provide the information necessary to generate the source code from the new templates.

Thus manually written source code has become new source code templates and specification types. This is not so hard to follow but once understood tends to lead to the next question “Doesn’t that require more work to write the code?” and the short answer to this is “Yes - indeed it does!”.

Why insist upon this extra work?

At first it can seem as though this approach is just burdening software engineers with yet more work (and this will be especially viewed this way if the code is not seen as being likely to ever be re-used in the future).

Here then are the major reasons (and reasoning) as to why this approach is insisted upon:

  1. It discourages manually written code.

If the software engineer knows that all manually written code will need to be turned into source templates and specification types before being accepted then they are far more likely to instead work with the existing (and thus more “tried and tested”) source templates and specification types.

The encouragement for re-use that the above discouragement implies has the side benefit that if there are bugs or deficiencies in existing source templates and/or specifications then these will be more quickly located and repaired/improved (with all existing software gaining these changes immediately upon their next regeneration).

  1. It encourages mimimal amounts of new manually written code.

This is perhaps just a further extension of the first point but is separated out to make it clear that for the software engineer writing new source code templates and specification types that work well with other existing ones will greatly reduce their workload and therefore will likely become a natural preference to writing large amounts of source code that will then have to be converted into complicated source templates and specification types.

  1. The benefit of artifact renaming support as well as future re-use.

The creation of small source code templates and specification types that work well with others can help ensure that even code thought to be quite “one off” may find a later re-use (at which point that extra work will have paid off).

The other often overlooked advantage to having all the source code being generated in the manner that is being done by CIYAM’s Software Manufacturing methodology is that the renaming of model artifacts (such as classes or fields, etc.) will require only software regeneration (so no time will be wasted doing search and replaces).

How is this better to traditional approaches?

The encouragement of re-use of well tried and tested software source templates over the manual creation of new source code is fairly obvious but here are a few other reasons.

  1. The “copy and paste” approach to writing software is replaced with a “select and generate” one.

It is not hard for any software engineer who has worked on non-trivial software applications to understand the evils of “copy and paste” (as generally this activity actually becomes “copy, paste and replace” as the source code at the destination is rarely going to be identical to that of the origin). An even worse problem than the “oops - forgot to change that” when using this approach is the fact that if one or more bugs are hiding in the original source then you have the sometimes quite difficult task of trying to find every place where this code was copied to in order to make the same changes needed to fix them.

Of course to this point an immediate response is “but that is what using objects/procedures/templates/etc.” is supposed to provide (in terms of having a single implementation) and to a large extent such approaches can and do address this, however, there are limitations to all such language constructs which is why in so many places one sees small isolated “code fragments” (or snippets) appearing via the clipboard (as well as just the common “lazy programmer”).

So programmers faced with a “no copy and paste here” rule will either quit in frustration (maybe a good thing) or instead try to work out which specification types might provide source code to perform the function that is required (the “select and generate” approach).

  1. A new and very clear division of duties suitable for different kinds of programmers.

As programmers become more familiar with the “select and generate” approach to rapidly creating software it is quite possible that they end up with less interest in wanting to create new source templates and specification types whilst other programmers may find more interest in doing just that (with the experience and skill levels of individuals being an equally important factor in deciding who will do what).

Traditional software development approaches are usually clear about these divisions of duties when it comes to creating new or to changing common (or library) code but as pointed out above when manual coding is allowed to be performed it is not so clear as to when a snippet should become part of the common code (which will require more time to be allocated to code reviews).

By making it not possible to “sneak in” some code fragment/snippet the software construction process itself is able to assist in making sure only well tested such things are included via specifications (which will require less time to be expended on code reviews).