Good programming, good human communication

By Gianfranco Alongi, Ericsson AB (Sweden)

 

Many believe that programming is about proving their own skills by pounding out pages of code in a frenetic 'tick tick' of keystrokes and that the aim is to write super complex code with obscure optimisations that require astronomical intelligence to comprehend. It is true that this is a possible aspect of software programming, but it is far from what we should aspire to as professional programmers.

'The programmer' originated in a time where feedback was slow and machine interaction as well as machine speed was a bottleneck. The feedback loops where long, tedious and the cost of miniscule trivial mistakes was very high. Naturally in such an environment, excessive (by our current standards) precision was key, and was rewarded.

Now that we live in a rapid changing, high complexity (RaPLEX) environment, it is no longer the machines, but the human who is the bottleneck. It is – therefore – time to break old inbred habits of silently working away in solitude. The silent 'nerd' in a corner is a relic – an eternal self-fulfilling prophecy, a construction of the past when the extreme focus and attention to detail was necessary due to the sad limits of computing. Still, the idea of the silent nerd lives on, and is used in an unfortunate way, to keep programmers at the bottom of the professional hierarchy.

Programmers are clever and creative people! And clever and creative people like to work together. We practice it all the way up to university - but for some reason we are not allowed to continue this excellent strategy at work.

This is wrong – and I will tell you why.

Programming requires knowledge, creativity, skill and experience

Programming is a highly intellectual and creative activity in which error correlation to changes gets increasingly difficult as the complexity of the software system increases and the rate of change increases. The programmer needs knowledge of the domain problem as well as having the creativity and, a problem solving strategy, to find solutions and the skill to encode a (potential) solution into a machine understandable representation.

As the programmer gains experience, he or she will be able to rely more on heuristics and pattern matching for problem solving – thus effectively increasing the speed at which work is done.

Programming is problem solving, not solution encoding

Programmers use keyboards in order to interface to machines in order to express a structured chain of thought through and interpreted, or compiled language, for the machine.

However, this act of typing is secondary: merely a necessary evil that the surrounding world tends to interpret as the act of programming. This is understandable, as keyboards and languages are the least abstract parts of programming. But programming is not about typing on a keyboard, or about writing statements and expressions. Programming is about problem solving – about formulating algorithms.

Maintainability cannot be ignored

Experienced programmers know and understand that making it work is only the beginning of the lifecycle of the software code. In order to ensure long living products maintainability is a primary aspect of any commercial or widely used software system. There are many things that make code maintainable - such as readability, clarity and expression of intent.

Code is maintainable when it is understandable by other programmers than just the original author. Other programmers should be able to revisit, understand as well as change the code easily even after a significant amount of time has passed.

Thus, maintainable code is understandable and simple, fitting well into the overall design and does not deteriorate the architecture. This type of code is a high quality solution to a problem.

The hard part of programming: high quality solutions

The main problem of programming is to solve problems, secondary the aim is to produce maintainable representations of these solutions. For programmers, it is not typing on a keyboard, or saving files that is the hard part of the day to day job. The challenge lies in finding the best solution and then encoding it in a maintainable way - thus not increasing software entropy. This is the hard part.

Collaboration optimises the hardest part of the software process

When programmers work together to solve a particular problem the cognitive processing power is dramatically increased! This makes the hardest part of the job (finding the best solution and encoding it in a maintainable way) easier, but does nothing for the trivial part of the job (typing on a keyboard).

There is an overwhelming amount of primary, secondary (tertiary and deeper) positive effects when engaging in 'paired' and 'mob' programming, but one worth mentioning here is the effortless process of learning and sharing good practices.

The discussion is over

Over the years, I have had to defend and argue for the eXtreme Programming practice of Pair Programming (PP) or the more recent Mob Programming (MP) technique which has been widely shared by Woody Zuill. However, the discussion of whether to allow or disallow close cooperation between programmers is immediately over when you realise - and accept -the fact that programming is about problem solving and not about typing.

Questioning the value of PP, MP or any other collaborative technique is the same as questioning why smart, skilled and experienced people should be allowed to solve hard problems together, learn from each other, and ensure that the best possible solution is found and encoded in the best possible way.

Collaboration requires communication

The only way our brains can collaborate is through communication, either direct or indirect, synchronously or asynchronously. But in order to ensure speed and correctness, feedback loops need to be short and thus synchronous direct communication is the most qualitative way of collaborating, while asynchronous indirect communication is the worst.

Every brain is a standalone processing unit, capable of searching for solutions - finding a correct, or incorrect solution, correcting other solutions and encoding solutions. But the value of having several brains involved is significantly lowered if they cannot collaborate in the best possible way - synchronously and direct.

The distributed network of brains at our fingertips

A company is essentially a distributed network of brains that (hopefully) work towards the same goal, but in different ways. Since these brains are inside biological robots, they are separated and sometimes isolated. In the best of worlds - each brain would have instant access to the knowledge and experience of each other brain in the network, and even being able to "borrow" cognitive processing capacity from the other brains.

However, this is of course not possible - yet.

What we can do to leverage this untapped potential is to communicate more - embracing the humanity within us.

Ergo - effective programming is about human communication

Programming is not about typing, it is about problem solving and encoding the solution in a maintainable way. Finding the best possible solution is the obligation of the professional programmer. The best solution may originate from someone else, or through collaboration, it should not matter for the professional. The professional programmer will ensure the best possible solution and the best possible encoding of it - so that the longevity of the software system is unharmed.

It is the duty of the professional to harness the vast network of brains at hand, seek out the experience and knowledge of others, while also sharing and teaching at the same time.

Harnessing this power cannot be done efficiently if we don't embrace communication.

It is therefore now the duty of the professional to communicate.

Authors Bio

Gianfranco Alongi is a Master Software Engineer at Ericsson AB (Sweden). He describes himself as a Polyglot Software Craftsman and very passionate Functional Programmer with a strong interest in Agile Programming Practices and a passion for structure and esoteric topics. He finds great enjoyment in Clean Code developed using TDD. Since discovering APL a couple of years ago, he has been working on a TDD framework for APL, and exercising it to write applications in APL. He is also the founder of the Software Craftsmanship in Stockholm http://www.meetup.com/Stockholm-Software-Craftsmanship/

For more information on the TDD techniques Gianfranco is advocating or his thoughts on Maintainability, we recommend you watch his presentation at Dyalog '13 in Florida or his presentation at Dyalog '14 in Eastbourne:

• Test Driven Development in APL (Dyalog '13)
• Let's Talk About Maintainability (Dyalog '14)