Adopt a company library to strike a balance between flexibility and simplicity

When choosing a company programming standard, there are always competing choices, with different assets and liabilities.

The main dilemma may be described as “flexibility vs simplicity”.

A general-purpose programming language is more flexible and a specific-purpose programming language, like the so-called 4GLs, is more simple.

A large library or framework is more flexible, while a simple one is … simpler.

An extensible library or framework is more flexible, while a non-extensible one is usually simpler, and it is surely simpler than a library that has been radically extended by a client.

Let’s see an example. A user-interface component displays texts in a font that cannot be changed by the client. Another one uses a default font, and allows clients to set the font, but only at design-time. Another one uses a default font, allows clients to set the font at design-time and also at run-time.

Most applications need to use only a handful of carefully chosen fonts, and sometimes to switch at tun-time between them. If the library forces a single font, or forces to choose the font at design-time, it may be too rigid. But if it allows to choose among all the installed fonts, it may be unnecessarily complex, and it may run against several problems, like the absence of the chosen font on the user computer, or the illegibility of the resulting text.

I think that the best solution is the following.

A very powerful library is adopted, allowing all needed features, even at the cost of being unwieldly complex. At the extreme, it is the API of the operating system and graphical environment.

A specific-purpose library is developed in the company. Such library uses the adopted powerful library, and exposes and API to a category of application software. Such library is developed by a system-programmers, that is programmers who know well the powerful library, but little of application domain.

All application programmers are forbidden to use any library except the in-house developed specific-purpose library.

Whenever an application requirement cannot be satisfied by the current specific-purpose library, that requirement is removed, or the library is extended to satisfy that requirement, but anyway the application code is never allowed to access directly the general-purpose library.

For example, the specific-purpose library declares a handful of fonts, among which the application code must choose the desired font. If another font is really required by the application code, the library is extended by adding that font to its set of fonts.

Using this architecture, there is no absolute limit to what may be done by the applications, but application code remains simple and consistent, and typically also the resulting user-interface comes out quite consistent.

About Carlo Milanesi

I am a software developer in Italy. I have developed financial, engineering, commercial, web, and industrial automation software using many programming languages, mainly C, C++, Visual Basic, Java, and C#. Now I am interested in Rust.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s