Why Should Software Designers Understand Science?

Few years ago, I used to be a software designer. Then I went to the university to learn the basics of science: a doctoral degree. Now I’m a software designer again. Did anything change?

The Scientific Revolution has not been a revolution of knowledge. It has been above all a revolution of ignorance. The great discovery that launched the Scientific Revolution was the discovery that humans do not know the answers to their most important questions.

-Yuval Noah Harari. Sapiens, A Brief History of Humandkind. 2011-

I went to the university because I had a strange feeling about the work I do. I liked my work (and still do) and spent many hours on Hacker News gazing on all new cool things that were happening in the developer community. However, I had little understanding on how to determine which of the cool things were useful enough to spend more time on.

At the same time, I was a bit anxious about the working practices we had in the company I used to work for during those years. I read about all the amazing practices other companies were using, such as continuous integration, test automation and cloud that could make my work so much easier and pleasant. However, I did not have the abilities to convince our management and customers to invest in improving our work practices. In addition, I felt it difficult to assess what was the impact of my work to the world. Was I really doing the important stuff or just tinkering around?

So, I started to do my dissertation focusing on continuous delivery, a very much hyped working practice at the time, now partially replaced by devops. I learned the basic research methods used in software engineering research, read the literature about continuous delivery and did a few case studies in real companies and software organizations developing software products and services.

There really are no best practices that suit all software engineering projects

I may later write about all the intricacies I learned during that time. But my main learning was that there really are no best practices that suit all software engineering projects. You cannot use the same practices from project to project. Instead, you have to tailor each project based on the team members, customers, existing product and technologies and so on. This is summed nicely by Alistair Cockburn, one of the initiators of Agile Manifesto:

People’s characteristics, which vary from person to person and even from moment to moment, form a first-order driver of the team’s behavior and results. Such issues as how well they get along with each other and the fit (or misfit) of their personal characteristics with their job roles create significant, project-specific constraints on the methodology. This result indicates that people’s personal characteristics place a limit on the effect of methodologies in general.

Every project needs a slightly different methodology, based on those people characteristics, the project’s specific priorities, and the technologies being used. This result indicates that a team’s methodology should be personalized to the team during the project and may even change during the project. 

-Alistair Cockburn. Doctoral dissertation: People and Methodologies in Software Development. 2003-

Of course, best practices are not totally worthless. You can still use them as a toolbox from which to choose when tailoring the work practices for your own projects. But the practices should be contextualized instead of generalized; you should understand in which contexts have the best practices been used with what results.

How do you then decide, which practices to use?

By experimentation. And this is where science comes in. Because science is not all about ignorance, like Harari continues:

Having admitted ignorance, modern science aims to obtain new knowledge. It does so by gathering observations and then using mathematical tools to connect these observations into comprehensive theories. Modern science is not content with creating theories. It uses these theories in order to acquire new powers, and in particular to develop new technologies.

-Yuval Noah Harari. Sapiens, A Brief History of Humandkind. 2011-

So, instead of someone else applying science to tell you what best practices you should use, you should apply science yourself in your own projects to decide what to use. Experiment, measure, learn and gain superpowers. With similar methods, you can also verify the impact of your work. In addition to mathematical tools, you can use hermeneutics when it comes to analyzing qualitative observations. But that’s another blog post.