arthurnardy.dev

Personnal website of Arthur Nardy, software developer, mainly specialised on business problems implying complex systems, data processing, and applied mathematics

What is a software (and its source-code) ?


This paper was first published on the website of my employer “Amiltone” in french. I here propose a less SEO-friendly translation to English.

Computers experienced increasing democratization from the 1980s in the West. Firstly it was a work tool available to a minority of business executives. Then it became a tool available to privileged households. It even became a new source of distraction with video games. Then it became classic to have one at home. Then it became mainstream to have one in your pocket at all times. And lastly it has become natural to wear one on your wrist.

Thus one would expect that even people with no technical background, would have at least a small understanding of what software is. This expectation is even stronger in the generations like mine that grew up with computers and the internet. After all, it seems like a given that even people who are technologically alienated from their cars understand what a steering wheel, a pedal, and an engine are.

Yet, surprisingly, no.

No, not everyone understands what software is. This misunderstanding is more often partial, but sometimes total. Software should not be confused with computer program. Computer program a simple chain of instructions executed as is by a computer machine. There is of course this technical dimension to the software, but there is also an economic, sociological and even psychological dimension.

Since information asymmetry is an obstacle to a client’s success, it seems important to break it down as much as possible. At the end of this reading, we should all be able to ask ourselves the right questions to have richer discussions between the different actors of a software project, and in particular between businessmen and technologist.

A bit of etymology…

From the 1950s, Anglo-Saxons learned to distinguish between “hardware”, the permanent material part of the computer, and “software”, which is the easily modifiable part of the computer. In France the “Plan Calcul” will lead to the creation of a neologism binding the words “logic” and “hardware” to insist more on the “formalized logic” aspect.
It is out of step with the idea that Anglo-Saxons have of it. Worse, technical developments (such as the virtual machine) have made it possible to decouple even more strongly the software design from the hardware aspect.

Etymology alone does not allow us to fully understand what software represents nowadays. But it helps us remember that software is not a fixed, hard-to-change entity that must punch its weight on an organization. It is something malleable, which must follow faithfully, day by day, the evolution of the business and its intentions.

An economic dimension

Do not confuse “program”, which designates a chain of instructions intended for the computer, and “software”, which includes a set of programs and subroutines, as well as all the data persistence and associated configurations.

But what does software really provide? The answer is the same as to the question “What is IT for?” “: to speed up!

Automatic information processing (i.e. computer science) is the technological response to be provided to organizations that need to quickly coordinate a large number of players. These organizations might be

  • An engineering office that want to quickly simulate complex physical phenomena. 
  • A public administration implementing laws and services for citizens.
  • A car renter who needs to manage its car fleet.
  • Any other actor dreaming of only one thing : to speed things up.

But IT solutions only make sense if they are designed beforehand to be aligned with the business.

  • What are the company’s economic incentives?
  • Who are the collaborators?
  • Who are the end users?

These discussions must be at the center of the discussions with the developers so that they can appropriate the business problem of the clients. This leads to a happy consequence: the features delivered correspond exactly to the need and allow an immediate return on investment. No more internal negotiations to organize depreciation, the features save or bring in money immediately. This completely changes the financial discussion and brings a lot of positive impact.

A sociological dimension

Software can accelerate an organization, giving it a certain competitive advantage over its competitors. An organization capable of moving quickly is an organization that can adapt quickly to market demands.

Software is therefore about supporting organizational choices and speeding up information between its various components. This will be a natural tendency anyway, because as Conway’s Law states: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” For example, if a small start-up is structured around 4 services, the software to manage this company will boil down to 4 successive components.

A debate that has not found a definitive solution, and on which the business decision maker will have to ponder, is the inverse Conway’s law. This inverse law suggests that if a system conflicts with the existing organization, teams will change organization, constrained as they are by the new system. Except that in an organization, the informal actually has the upper hand over the formal. You do not believe it ? How many companies have deployed integrated management software (ERP), only to realize that their teams had set up a parallel solution in Excel, and only opened the software to fill in the compulsory fields ?

Any organization must think about its own transformation, making sure to obtain the support of its members. Otherwise, it may get lost.

A psychological dimension

When an engineer has a tool to design, for example scissors, he must reflect on questions like ergonomics. He will study the shape of the human hand to adapt his tool so that the grip is easy and safe. He may even offer his product in left-handed and right-handed versions. If he does not do any of this, he is taking a considerable risk with his customers.

An individual who interacts with the world, feels emotions, whether positive or negative. The tool can be a vector of positive or negative emotion. If its use is uncomfortable or absolutely not practical, the individual will surely give up the use of this tool, in favor of another solution. This problem of acceptability also arises in the field of software. For end users to appropriate the software, their needs but also their cognitive processes must be taken into account. This is the whole contribution of UX/UI Design (we also speak of Computer Ergonomics or Usability Design).

In the same way that a tool is designed to be ergonomic for the user, the human-machine interface must be consistent with the purpose pursued. The HIM must not betray the intentions of the user, by dispersing it. Except that, where we would worry about the shape of the user’s hand to design scissors, here we must worry about the way of thinking of the user. If a software makes its user crazy, it is obvious that he will put in place all possible tactics to avoid being confronted with this pain. If a user finds it difficult to achieve his goals with software, he will develop workaround tactics in order to save time.

Thus each interface is designed, then tested in real conditions. The collection of feedback will help to bring the software and its HIM closer to what is really valuable and helpful for users. Adherence of end-users to a software depends on it.

A technical dimension

The source-code describes how the organisation want to speed things up.  Everything has to be adapted and contextualized according to the business of the beneficiaries. This is no more and no less than a detailed specification. Yet, developers are often labeled as skilled workers, who must be given a specification by a real engineer. This misunderstanding of the developer profession costs a lot, but can be explained by the history of the industry.

In many industries, the classical pattern of value production is seen as shown in the following diagram:

Engineers and workers have different areas of expertise, and the former have the responsibility of writing a sufficiently detailed specification for the latter. What will be delivered will be what the workers have understood. Nevertheless, in software development, the worker is actually what we call a compiler. Namely, we have a software producing another software. So, the source code is the detailed specification for the compiler. This is why, by imitation, we often find in our industry the following pattern :

This pattern of value production is counterproductive and even dangerous for the success of the software. Developers are engineers in charge of writing a detailed specification. What goes into production will be what the developers understood. They must be able to carry out their activity by being the most directly in contact with customers and final users. Consequently, we must tend towards the following pattern:


The change of perception of development teams is often an upheaval for organizations. They understand that outsourcing software does not mean let of the provider with a detailed specification and a budget envelope. It means buying a team of business partners who will write these specifications.

In conclusion

  • Software is the technical solution to speed an organisation up. It is about making it more competitive than its competitors, and improving the working conditions of its collaborators, who can then focus on what really brings value.
  • A software maps the communication structures of the company, but it also matches the thinking processes of all users. All of this is intended to make the use of the software natural and fluid for the entire organization, its actors, and to guarantee everyone’s support.
  • The source code of a software is its detailed specification, which must be written in collaboration with the development team, and not before the involvement of the team. Otherwise it boils down to doing the same job more than once, while losing information along the way.
  • The source code is not an immovable edifice like a bridge or a building. It follows the evolution of the organisation, day after day. The source code helps the organisation to pivot as quickly as possible in a constantly changing market. The source code allows to make a series of incremental improvements to continue to speed the organization up.
  • With the right governance, the feature delivers immediately the value the customer expected. And this lasts forever (or actually until somebody purposely erase the feature). When software improvement is incremental, we do not need financial amortization or otherwise “unrisking” tactics.

Social Media Auto Publish Powered By : XYZScripts.com