Fundamental Pragmatics for Successful Software Developers

Simple tools and concepts can be understood quickly, are easy to use, less error-prone and make us more productive.

We all like simplicity. Simplicity makes work and life more enjoyable.

However, we must be aware of oversimplification, as indicated at the end of Einstein’s beautiful quote.

Therefore: Keep it simple, but not simplistic!

Many famous people advocate simplicity. Here are a few examples:

Most software projects fail. This is a sad and undeniable fact.

If a project is deemed to fail, then it should fail as fast as possible, in order to limit the damages and free up time and resources for other projects that will (hopefully) not fail.

Failing fast in this context means that problems should be detected and dealt with as soon as possible. The longer we wait to address the problem, the more time, energy and resources will be wasted. The cumulative loss increases exponentially with time.

For example, correcting a design flaw in the design phase is easy and cheap. But once the software is in production and used by many people, it is often very expensive and frustrating to fix the error.

Creating perfect software (no bugs, all features fully implemented, optimal user interface, excellent documentation, etc.) is extremely time-consuming and expensive, unless we are working on a very small project. In most cases it is impossible to achieve perfection because of practical limitations.

Even the major players in the software industry with the best developers and dream-budgets don’t write perfect software. That’s why they constantly provide patches and new versions.

Therefore, proceed like this:

Practice shows:

We want happy users. Therefore the best approach is an iterative one that goes like this:

Whenever you create an application, start by carefully designing the data structures and their relationships. Do this before writing code.

Well designed data structures lead to simpler and more maintainable code, less bugs, better performance and less memory consumption.

The difference can be striking.

Immutable data structures are simpler to understand, simpler to use and less error-prone because:

However, immutable data structures are not always the best choice. For example, cloning a whole structure for every single change can be very costly (in time and space). In some cases (e.g. game or GUI applications) mutable data structures are better suited.

Moreover, if two objects need to directly refer to each other, then the objects (at least one of them) must be mutable. Examples would be a parent and child node in a tree referring directly to each other, mutual friends (A points to B, and B points to A), etc. If immutability must be preserved in such a case, then a possible solution would be to have an additional data structure that describes the relationships, such as a set of tuples that represent a pair of objects related to each other.

Limiting the set of allowed values for a data type:

For example, consider the case of a name field for data type employee. By allowing any string to be stored in name , the following can happen:

To avoid these risks, the name field should be constrained. For example, the following simple regular expression eliminates all above mentioned problems:

This regex limits the name to a maximum of 70 characters, requires at least one character and allows only letters and spaces. Note, however, that the above regex would be over-simplified and not suitable in real-life applications that must allow names containing hyphens, apostrophes, and maybe other symbols.

Protecting data against invalid values (especially in case of data read from external sources) is often cited as the most important rule for writing secure software. (for example, see OWASP Top 10 Critical Web App Vulnerabilities and Top 10 Secure Coding Practices)

Example of an attempt for SQL injection in a data entry form:

Example of a Javascript injection attempt:

By choosing the strictest possible value as default value, we are always on the safe side.

More permissive values should need to be explicitly stated (in the code, in configuration files, etc).

For example:

The last example demonstrates that strict default values are not always the best choice. They can be annoying. If the multi-user application is only used by a single person on his/her PC, then the user obviously wants to have full rights by default. Hence, the best default value sometimes depends on several factors.

Example of a strict default value in a GUI:

Storing copies of mutable data at different locations is error-prone, laborious and expensive because:

Banal example: A salesman misses an important appointment. Reason: He entered the appointment into his agenda on his PC, but forgot to synchronize the data with another agenda on his mobile phone. If the data for both agendas were stored in one place (e.g. in the cloud), he wouldn’t have missed his appointment.

Using text files as storage media has many advantages:

However, text files also have severe limitations, especially in cases of big data. Complex queries (with filters and joins), update and delete operations, transactional processing, data encryption and other functionalities might need to be implemented manually and can be very inefficient. When it comes to big data then storing them in a database is often the only viable choice.

Moreover, storing data as characters (instead of bits) can consume much more space and time. Therefore, binary data are sometime unavoidable.

A nice example of using text to represent graphics is SVG (Scalar Vector Graphics).

Here is a simple example of an SVG file (SVG_example.svg):

Opening the file (for example with your web browser) displays the following image:

Beautiful code is short, simple, quickly understandable, modular, extensible, reliable and maintainable.

Beautiful code rarely needs comments and reads like prose.

Developers love to look at and work with beautiful code. It makes them feel good.

Writing beautiful code is an art that requires passion, deep commitment, and many years of practice.

Don’t reinvent the wheel!

Before writing new code, be sure the functionality you need doesn’t exist already.

Look at existing libraries and frameworks (maybe written in different languages), tools, other applications and cloud services to find what you need, or to get ideas and become enlightened.

For example, Unix provides many powerful, reliable and flexible out-of-the-box-tools (also available on Windows) for text manipulation. Use them in your application if they are appropriate.

Detect and fix problems as early as possible!

This helps to minimize development time and costs, and reduces the risk for failures and damages in production mode.

A maximum of bugs should be detected automatically. This can be achieved by smart IDEs, compilers, static code analyzers, fuzzy testers, etc. Automatically detected bugs are very cheap to be discovered, and they can’t go into production and cause malfunctions.

Write good unit tests.

Bugs that stay undetected before running the application, as well as all kind of runtime problems (e.g. file not found, invalid input data, etc.) should be detected as early as possible at runtime.

Therefore, check all input for valid values (function arguments, user input, resource input, etc.). Check all return values for error conditions.

If the runtime problem cannot be handled gracefully, then the application should consistently apply the Fail-fast principle by reporting the problem in an appropriate way (i.e. with a maximum of information that helps to solve the problem), and then aborting immediately. This is important because:

Here is an example of what can happen with wrong HTML code, because the Fail-fast principle is not applied:

Instead of displaying the following life-saving warning …​

... a life-threatening message is displayed:

For an explanation of the above outcome (and for more advice about how to fail fast) please read Introduction to the 'Fail Fast!' Principle in Software Development (hint: it’s just a missing > character in HTML code).

Ultimately, the Fail-fast principle helps to write more reliable and safe code in less time.

Therefore, prefer programming languages, libraries, frameworks, and tools that support the Fail-fast principle.

Small, single-responsibility components have benefits for both the author and the user of the component.

The power of the whole is the result of many simple components working seamlessly together.

Resist the temptation to add features that might be used in the future.

Every feature increases complexity as well as the risk for malfunctions. Every feature needs time to be created, tested and maintained.

Moreover it is often difficult to foresee features that will actually be needed later, especially in projects with frequently changing requirements. Adding features that will never be used is pointless.

Remember: Keep it small and simple!

Before thinking "What else can we add?", ask yourself "Is there anything we can remove?"

Instead of writing 'clever code that runs faster' it is better to write simple, correct and maintainable code that runs fast enough.

The approach should be:

Don’t forget: Bad performance is often just a consequence of bad data structures, bad code and/or bad architecture.

Doing the same again and again is error-prone, counter-productive, boring and increases the risk of not doing things that are important, such as unit/integration tests, backups, etc.

Use the best tools you can get for frequent tasks, such as writing/editing code, handling files, etc.

Strive for single-click-execution or, even better, scheduled tasks that run automatically.

It is often easy to automate tasks. Create small scripts (written in your preferred language or using OS scripting), use automation tools such as Autoit, Selenium, or use any other best suited tool to quickly automate your or your user’s recurring tasks.

Flow (psychology) is described as follows in Wikipedia:

Being in the flow (also called being in the zone or in hack mode) can lead to a state of blissful feeling that needs to be experienced to be understood. Flow might be the reason a programmer once wrote in a forum: "I want to code, code, code - until I die."

For programmers, flow can best be achieved under the following conditions:

What does it mean to 'see clearly'? Close your eyes. Can you see the overall picture, the data structures with their relationships, as well as the functions and their interactions? Doubts must be eliminated first - by using paper and pencil, searching the net, asking for help, writing small snippets of test code, or doing whatever else is appropriate to get rid of the doubts.

Can you see clearly now? Then start coding and fully enjoy it!