Issue 27

Pragmatism in programming

Mihnea Lazăr
Java Developer
@.msg systems Romania


Pragmatism, as a term, refers to treating a task in a manner that focuses on the practical aspect of the approach, to maximize efficiency. In the field of programming, this term refers to the "best practices" of programming. These often refer to writing clean code and managing the code in a manner as efficient as possible, to make it easily understandable, by the person that writes the code, and by the people that will read the code in the future. The present article will present a series of ideas, with the purpose of improving the way we write our code, and the way we handle the projects given to us.

Cleanliness and broken windows

Inside big cities, it has been noticed how buildings in good conditions can often have buildings in a very poor condition right near to them. Following a few studies done on vandalism years ago, the "broken window theory" was created, which states that a single broken window left unfixed in a building having a good condition can lead to the state of the building degrading in just a few months. The window left unfixed gives, not only to the inhabitants of the building, but also to those in the neighboring buildings, a sense of abandonment, apathy, and untidiness. It is so that a broken window leads to a broken entrance door, graffiti on the outside walls and then to structural problems. This theory was used in the 80s in American states to reduce the rate of vandalism and improve the standard of living of the inhabitants of large cities.

Applied in the field of software, this theory encourages avoiding leaving "broken windows" in code creation. This can refer to a portion of code left unimplemented, certain functionalities left behind, or a part of a web page left uncompleted. Any of these, once the product is launched, will leave a bad taste to the user that will use the said product and encounter a barrier when he wishes to access certain functionalities that will either work incorrectly, or crash the system. Thus, a concern for detail is encouraged in designing the project, not to leave such elements behind. If faced with lack of time for design, certain functionalities must be left unfinished for more urgent tasks, is it advisable to "barricade" the window left behind. This can be done by either commenting the code that would generate an error or a crash, or by adding dummy data, hard-coding, or simply displaying an "Under construction" pop-up.


Code duplication is a common problem that appears in project design, either because of only one person working on the project, or more, due to lack of communication. A few tips to help avoid this situation would be:

  • Documenting the code, through comments, or written documentation;
  • Communicating the work log and problems that appeared, either personally, through periodic meetings, or virtually, by centralizing the problem description;
  • Implementing generic behaviors, that can be reused for multiple types of objects;


The concept of orthogonality refers to dividing an application into components that are as independent as possible from each other. What is desired through this is avoiding the creation of a method or class that handles too many different tasks. In the case of a method, each method should have a single purpose or behavior, and in case of a class, the purpose is for this to handle a single type of behavior of purpose.

Good enough

Often, in working on a project with a tight deadline, the notion of good-enough software is proposed. This involves a greater implication of the end-user in the creation of the software, in order to evaluate as detailed as possible how refined this user wishes the product to be, compared to how quickly he wishes it to be delivered. Some users will desire a product delivered quickly, with basic functionality, on which work can be done later on to perfect it.


In modern times, society had to find a way to make transactions safe and efficient. The solutions implemented for this purpose can also be used in the writing of software. One of the best solutions found to ensure an efficient transaction is to write a contract, or technical specifications, by and for technical people that are in charge of the project, optionally with the help of the business people handling the project.

This concept was developed by Bertrand Meyer, for the Eiffel programming language. It is a simple and powerful method that involves agreeing and documenting a set of behaviors and purposes for the modules of the project, to ensure an efficient and correct functionality. In this way, the purpose is achieving an end product that does exactly what it was desired to do, not more, not less.

Each part of the project, big or small, has a purpose to achieve. Thus, the purposes and expectations can be divided in the following categories:

  • Pre-conditions, for the input data;
  • Post-conditions, the data produced as output, or the actions that will be ran;
  • Invariants, elements that can be modified during the running of the current portion of code, but that will have the same value after the code is ran;

Learn your IDE

Every programmer does his work using a programming language. The better he knows his chosen programming language, the better he can do his work. This code created with this programming language is written in an IDE (Integrated development environment). Each IDE offers a range of possibilities in assisting with the writing of the code. Thus, it is of great importance and utility, that we know our developing environments as well as possible. A good knowledge of the IDE in which one works can greatly ease the tasks that have to be done. Knowing how to work in an IDE without using the mouse greatly improves the speed and manner with which the work is done. The basic shortcuts of an IDE, that can eliminate the need for a mouse, are approximately 10, for a standard IDE, such as Eclipse.

On communication

In the field of software, communication is a key element in our day to day work. We communicate either with clients, colleagues, or machinery, by writing code. It is important to know how to do this communication as efficient as possible. Here is a series of short ideas on communication in the field of software development:

  • Organize our ideas before realizing the communication. Formulate before what we wish to communication, even if we will want to communicate it in writing, in a meeting, or by a question towards a coworker;
  • Know our audience. Once the ideas are formulated, we should take into account the person to which we want to communicate with. Working on a project, each side will look differently at the problem brought to them. Someone from management, for example, will look differently at a problem, and will require different explanations than someone on the technical side;
  • Choose our moment. Lunch breaks are not always the best moment to talk about recent project impediments;
  • Make it look good. If it"s written, proofread it, if it"s said, say it in a pleasant manner;
  • Accept feedback. The answer or the feedback we receive may not always be what we wanted to hear.

Baggage of knowledge

As time passes, programming languages are updated, improved, and even replaced. Each language has its own characteristics, advantages and disadvantages. New projects and products on the market require knowledge on currently used programming languages, which are adapted to current performance requirements. It is thus necessary to maintain a knowledge portfolio periodically updated. Maintaining such a portfolio can be compared to maintaining a financial portfolio, and thus we have a series of ideas applicable for both types of portfolios, about how to best maintain these:

  • Investments to be made periodically, and constantly, to form a habit;
  • Diversifying investments. The more varied a person"s knowledge is, the more valuable a person is;
  • Balancing investments, between the safe ones, with low interest, and the risky ones, with high interest. New technologies would be classified as high-risk investments, but if one such investment would catch on, if there are few people familiar with that technology, these people would be that much more important in the context of a project requiring knowledge on such a technology;
  • Periodical reviews and updates. Once every few months, we can look to see if the new investments still present potential, or if there are other options with higher potential.
  • And, as investment ideas:
  • Programming languages;
  • Technical books;
  • Non-technical books (management, finances, self-development, and so on);
  • Events, presentations, in the field;
  • Publications, magazines, tech news websites;
  • Mentors, for advice and suggestions.

Presented here are only a few ideas on the improvement of the work done in the field of software, in a pragmatic manner. They are accessible ideas, which are good to be taken into account, to enable us to do our work as good as possible, and improve as much as possible the results we wish to obtain.





  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Grab
  • Colors in projects


Mihnea Lazăr wrote also