November 23, 2022
Four benefits of programming together
In a series of blogs, Dennis van der Salm, senior Pega architect at BPM Company, looks at efficient versus effective working, role-based versus skill-based working and different programming styles. In an earlier blog, he wondered to what extent role-based working still works within the IT industry. In this blog, he zooms in on programming styles and talks about what bringing disciplines together can bring you.
‘So you work together and focus on the same thing? That’s not very productive!’ I regularly get this comment when I explain to people how I work. I think differently about that. At the beginning of my career, I worked in a team where we had a fairly standard way of working. Product-owners wrote the user-stories. The business analyst researched those stories. During refinement sessions, the details were transferred to the rest of the team and a developer would work solo on one of those user-stories. Once the developer was ready, the most experienced developer on the team reviewed the code. Finally, the whole thing was handed over to a tester after which it was finally pushed through to the production environment by people from operations. A way of structuring based on The Principles of Scientific Management, as I also described in my earlier blog. How efficient is role-based working really? Let’s zoom in on the role of developers.
Pair programming not so extreme
A few years ago, I read Kent Beck’s articles on Extreme Programming. Well, you are young and the word ‘extreme’ naturally grabs your attention then. My expectations were high, but when I finished the book, I was a bit disappointed, to say the least. Almost nothing in his book seemed extreme. It all seemed like common sense! One of the main topics of the book is ‘pair programming’: two developers working together towards a solution. But what benefits does that actually bring? I see four.
The four advantages of pair programming
1. Ongoing review of code
Reviewing code – naturally – increases the quality of the code and reduces the risk of bugs. In pair-programming, the code is in fact continuously reviewed.
2. Sharing knowledge ‘on the job’
In pair programming, the senior developer supervises the less experienced programmers. Junior developers and new entrants can thus start working immediately and are immediately productive.
3. Knowledge assurance
Because several people have extensive knowledge of the application, less knowledge is lost when someone leaves. This is even more convenient for externals, like me, who work for a client for a few years.
4. A broader sense of responsibility across the application
A solo developer working on a piece of code only feels responsible for that piece of code. If a change is needed at a later point in the process, that particular person has to do it because ‘he built it’. In pair programming, both developers feel responsible for the entire code of the application.
The closer to the solution, the less value
In one of his Tweets, Beck argues that pair-programming works best when little is known about what needs to be done. The closer you get to a solution, the less pair-programming adds. A valid point. The more is known, both in terms of what needs to be done and where the developer’s knowledge is concerned, the less pair-programming will help you. In my own experience, when I was at the beginning of a topic, the pair-programming sessions were more intense and thus had more impact. Once the details were known and the designs and solutions were clear, the impact of pair programming diminished. At that stage, it was mainly about avoiding errors, which is still very valuable because debugging can give you quite a headache!
Nothing to hide
Pair-programming can be quite difficult. You have to let go of your ego. After all, you can’t hide if you don’t know something. There is nothing wrong with that in itself, but it can be tricky. Experimentation and constant conversation is key. That can lead to great results from moment one, but you may also need to improve things a few more times to make it work. Martin Fowlers wrote a valuable article on pair programming, with practical tips. Want to go one step further in collaborative application development? Then mob-programming might be a good option.
Is pair programming a panacea? No. It is a valuable tool that you can use to tackle challenges effectively. Try experimenting with the tools, try to master them and use them in the right context.
Want to know more?
In future blogs, I will explore this topic in more detail. I look at efficient versus effective working, role-based versus skill-based working, and different programming styles. Do you also feel that cross-departmental processes could be more efficient and better and want a quick initial insight into the possibilities? Feel free to contact us!