Interview with Sandro Mancuso - Software Craftsmanship

Thinking of code as a beautiful work of art is a mistake. But at the same time we need to start seeing coding as a genuine skill that deserves professional recognition, says leading Software Craftsmanship advocate and JAX London speaker Sandro Mancuso.

This interview was originally published on the JAXenter webiste

So in your JAX London workshop you’ll be helping developers to write better, more crafted code. Speaking as the founder of the London Software Craftsmanship Community, what kind of an impact do you think the craftsmanship movement is making to improve the level of code?

Craftsmanship is still a young movement and its impact is still small when we take into consideration the whole software industry. Agile took more than 10 years to become mainstream and I believe that Software Craftsmanship is a natural complement to Agile.

Agile changed completely the way we run and deliver software projects and it has been a massive step forward in our industry. Unfortunately, part of the original Agile message was lost, mainly when it comes to delivering quality software. Methodologies and practices that were more focused on the process side of Agile became far more important than the ones that focused on the technical side. For many organisations Agile is synonymous of Scrum and XP practices and well-crafted software are nowhere to be seen. Software Craftsmanship not only brings the balance back to Agile but also brings a massive focus on professionalism in software development.

SEE ALSO: An introduction to Interaction-Driven Design with Sandro Mancuso

Software Craftsmanship is helping developers to understand that they are highly skilled professionals and that they should be proud of being developers. Just saying you are a great professional doesn’t make you a great professional—you need to be recognized as such. The professional recognition comes from customers and peers according to their satisfaction and how skilled you are. As developers start seeing themselves as professional software developers, the more they will pursue excellence. As they pursue excellence, the better they will become and the bigger will be their positive impact in the software industry. And this is what Software Craftsmanship is really about.

Why did it take so long for the IT community to begin thinking of software as a craft? And was Agile’s goal of “working software” not enough?

According to the history, as some of the first software projects were mission critical, long, and very expensive, people approached these projects as they approached similar projects in other areas, and in the 1960s, that was engineering. Companies had also inherited the knowledge acquired during the industrial revolution and had very hierarchical structures where the factory workers were at the bottom. It took a few decades of massive hardware and software evolution for our industry to see things in a different way.

Agile’s working software is a bit weak on its own. We need to look at some of the 12 Agile principles to understand what working software means. There we can find things like "valuable software", "deliver working software frequently", and most importantly "continuous attention to technical excellence and good design enhances agility."

The 17 Agile originators understood that working software actually meant high-quality working software. The problem I see with Agile today is that many Agile coaches out there have never been a software developer or at least have never been a good one. For this reason, they prefer not to talk too much about software and XP practices when advising companies. Very few Agile coaches today would be able to sit down with developers and help them to test-drive their code, configure their build pipeline, or suggest better design approaches. They prefer to restrict themselves to regurgitate a few things they read in the Scrum guide and, every now and again, with a superiority attitude, tell developers that they should do this TDD thing, as if they actually knew how.

I’ve often heard that programmers are treated like handymen in South East Asia – like a plumber hired to do a specific job. Do you ever wonder if the craftsmanship movement could limit the notion of the software programmer to being a simple craftsman?

The simple answer is no. Firstly because I don’t think that the way programmers are treated in South East Asia will change how programmers are treated in Europe or US. In fact, I believe it’s the other way round. Europe and US are changing how programmers are treated in South East Asia.

I’ve worked in quite a few places where we had offshore teams and, according to my experience, more and more companies in South East Asia are adopting Agile and Craftsmanship. I personally visited some of them to introduce these practices and I know of many other European and American professionals that did the same. We are also seeing more and more big Agile conferences in that region, a sign that things are changing over there.

Considering the increasing business importance of the programmer in all technologically reliant enterprises, is software craftsmanship becoming a more important concept – especially considering its ambition for “steadily adding value”?

Absolutely. Large companies are finally learning how inefficient they are and are heavily investing in Agile and Craftsmanship. I’ve personally seen it happening at investment banks, media and telecom companies, and most recently, the in UK government, which is an example of Agile and Craftsmanship adoption when it comes to governments. Still a long way to go but it is definitely happening.

The craftsmanship debate often lends itself to discussions of code as an ‘art’. Do you believe it helps to think of and discuss code as something beautiful?

No. The more I think about it, the more I’m convinced that it is a mistake. And unfortunately I was guilty of that myself. Thinking that code is an art or something beautiful is a very erroneous, romantic and simplistic view of software development. And the same goes for engineering, craft, trade, etc. The software industry is far more complex than that and software development involves a multitude of skills. Some times it feels good to call it an art but that is far more related to our egos than anything else.

A single software project may contain elements of engineering, craft and even art. Certain pieces of code are a work of genius and beautifully crafted. Others are a piece of boring and mechanical shit but that do the job very well. When it comes to being a trade, it may be true for some but for many of us, being a software craftsman is far more than that. It’s commitment to excellence. It’s a lifestyle.

At the end of the day, as professionals we are expected to deliver high-quality services to our clients, which is normally achieved via well-crafted software. It’s not important if we call it art, craft, engineering, or trade. That wouldn’t change anything for me. I prefer craft because that is the metaphor I like the most but as with any metaphor, we can always find cases where it doesn’t apply or is just wrong. On a personal level, what I really care about is that I love what I do and that I’m lucky enough to be paid for it.

This interview was originally published on the JAXenter webiste