Nicole Rauch & Michael Sperber on Software Craftsmanship

In this series of ‘3-minute Q&As’ we give you an insight to some of the world’s leading thinkers and doers in the world of Agile and Software Craftsmanship. We asked SCLConf's speakers Nicole Rauch and Michael Sperber about Software Craftsmanship, whether smarter tools may lead to developers losing knowledge about lower-level abstractions and where they see the Software Craftsmanship movement going in the future. So sit back, relax and take a sneak peek. Oh, and if you like this and want more then you should also check out sc-london.com, where you can immerse yourself in 2-days of talks, discussions and networking with the authors of the blogs...

Q. When did you first come across Software Craftsmanship?

(Nicole) I first came across Pete McBreen's classic "Software Craftsmanship" and immediately I liked the idea - so much that I even co-created a whole conference and subsequently a user group around this topic. The conference is SoCraTes Germany (Software Craftsmanship and Testing) which has given rise to similar events all over Europe in the last couple of years, and the user group is Softwerkskammer, with currently 1600 members and 23 regional chapters across Germany, Austria and Switzerland.

Q. What does Software Craftsmanship mean to both of you?

Software Craftsmanship means to do the right thing and to do it right. Also, we think that it is important that everybody involved in a software project raises their awareness beyond their own horizon, keeping the big picture in mind and engaging wherever necessary. In Software Craftsmanship, there is no such thing as a coder who "just codes", a tester who "just tests" etc. Everybody should be involved from the first meeting with the customer to the end of the maintenance cycle.

Q. What do you see being the future for Software Craftsmanship?

Software Craftsmanship _is_ the future :-) It is already noticeable today that for many companies it has started to become a game changer, introducing a shift in the mindsets that allows to slowly get and keep the old and often crufty codebases under control. Combine it with like-minded methods like Specification by Example and Domain-Driven Design, add well-established development strategies like strongly-typed functional programming, and you get a powerful toolbox for clean and maintainable code.

Q. What inspired you to give your talk?

We have long been interested in creating correct software by a systematic process, rather than by haphazard programming and later debugging and bug fixing. This is an obvious craftsmanship issue, but goes beyond the usual craftsmanship techniques. The technologies for creating software that is proven correct have existed for many years, but their poor usability put them out of reach for many developers. This is changing: That's what the talk is about.

Q. What do you hope people will take away from your session?

- Developers should think about their programs as having general properties (as opposed to just functioning test cases with individual examples), and make those properties explicit.

- Properties can be written as executable parts of a program, and verified with a little help from the programmer.

Q. As tools become smarter, do you see developers losing knowledge on the low-level abstractions?

Given the complexity of modern processor architectures, for the application programmer to understand what goes on at the lower levels has been hopeless for a while now. (Witness the troubles resulting from undefined behavior in C, which are a result of this development.) So it's not a function of the tools getting smarter, it's a result of growing complexity overall.

Q. Are there any projects you'd like people to be aware of? How can people help out?

Developers, in general, should consider functional programming as a means of reducing complexity in their code, and making good craftsmanship vastly easier: So the projects people should be aware of are the programming languages that let them do that, such as Haskell, OCaml, F#, Racket, Erlang, Scala, Clojure, Swift, and others.

Q. And finally, where can people follow you online?

@nicolerauch
http://nicolerauch.de/blog.html

@sperbsen
http://www.deinprogramm.de/sperber

Paul Blundell

In this series of ‘3-minute Q&As’ we give you an insight to some of the world’s leading thinkers and doers in the world of Agile and Software Craftsmanship.

So sit back, relax and take a sneak peek. Oh, and if you like this and want more then you should also check out sc-london.com, where you can immerse yourself in two-days of talks; discussions and networking with the authors of the blogs...

Q. When did you first come across Software Craftsmanship?

I first came across Software Craftsmanship when I was working as a graduate software engineer in the web space, this was before I moved to mobile. A colleague had a copy of the just published 'clean code' by Robert C Martin. I was struck by the perscriptive nature of an answer to every scenario, and it intrigued me to seek out these scenarios and apply the practices to learn and improve.

Later on when I read 'clean coder' it really hit home that being a good developer is not just about the code you write, but how you react to interactions and having a bar for your professional behaviour. This is the side of Software Craftsmanship I really enjoy, the psychology and professional best practices.

Developers have a responsibility to share knowledge and enable others on their team to understand the why and how of their reasoning and this is what I enjoy improving for myself and enabling in others.

Q. What does Software Craftsmanship mean to you?

I might have answered a little already. If we relate back to the manifesto, I see craftsmanship as, not only individuals and interactions, but also a community of professionals and not only customer collaboration, but also productive partnerships. For me, this means showing others in your team, or showing the client that developers/engineers are not just their to code heads down. We shouldn't just leave the business of why the product potentially wasn't what the company wanted to others.

Software Craftsmanship means you have the capabilities to talk to non-technical people, to translate what they want into working software and to translate back improvements or reasons why things may need to change from the coding or framework level. Software Craftsmanship means good communication at all levels; all developers being able to understand the code and all team members being able to understand the developers.

Q. What do you see being the future for Software Craftsmanship?

That is a hard question. As I've matured and gained experience my feelings towards craftsmanship have also changed. It's like the four stages of competence, you start off unconscious and incompetent, not crafting very well and not recognising you need craftsmanship. Conscious incompetent, you learn about craftsmanship but you fail to apply it consistently. Conscious competence, you know what you are doing but you have to concentrate when applying it. Unconscious competence, craftsmanship is second nature, you apply it without thought whilst taking other things into account.

I feel many developers stay at stage 3 'conscious competence' and rigorously apply what they deem as craftsmanship without thought for what else is going on on the team or around them. When you get to stage four 'unconscious competence' you have the freedom to consider other things and understand that perhaps...because of other factors some pragmatism is needed in your practices. This allows for deadlines, demo's, unforeseen outside influence and shipping dates.

Perhaps the future of Craftsmanship will be some backlash to this stage three perfectionism, every now and then I see people Mob programming and this is all about a whole team agreeing on ideas and setting out a rough framework of the code. It's not "crafting" but it should be a tool in a craftsman's toolbox.

Developers should be getting more involved in how businesses operate and applying craftsmanship to the bigger picture. Craftsmanship will have its part in digital transformations. Digital Transformation is basically transforming the organisation around software delivery, as software is the main medium for communication with the customer. That in turn sets a focus on software and craftsmanship. As we see more and more transformation (like Spotify) we will see more emphasise on craftsmanship within organisations.

The future is hard to predict and maybe I'm rambling a bit, but I see the future of Software Craftsmanship in embracing more pragmatism and people starting to talk about outside influences and quantifying value gained from each practice.

The other side of the future is - how inclusive is the word "craftsmanship" and should the whole idea be reinvented/reworded to allow for diversity and difference.

Q. What do you hope people will take away from your presentation?

That learning is a journey, you meet people on the way, share and grow together. Continuous learning is what keeps life exciting and your brain active.

Q. Google and Apple recently added support for testing in IDEs. How do you see these ecosystems developing for XP practices and what more could they do?

I see the ecosystems developing slowly. There is always a big emphasis on acceptance/UI testing when it is enabled inside an IDE, but the real benefits of testing come from the unit tests and the lower levels which don't get so much of a fan fare. I think the next steps for IDE's especially in mobile is to make the loop of testing faster, faster build and execution cycles as well as more stable emulators gives people less excuses to avoid testing. I'd love to see unit tests executed on every save for mobile IDE's (like Android Studio or XCode).

Q. What was the biggest obstacle at Novoda when starting your journey towards Software Craftsmanship?

Client acceptance for Software Craftsmanship, we always found clients not convinced by our methods but soon they see the value in the results, including the speed of delivery and lack of bugs and regressions. It's hard to quantify software craftsmanship, clean code and best practices to a business and most the literature out there is aimed at convincing developers. So turning software craftsmanship values into explainable value for the business was the biggest challenge.

Q. Are there any projects you'd like people to be aware of? How can people help out?

I help run the Liverpool Google Developer Group. I have a dream of a big tech city in the UK outside of London and you can contribute a small step towards this. :-) We are always looking for monthly meetup speakers, you can get in touch at gdg-liverpool@novoda.com and see more here www.meetup.com/GDG-Liverpool/

Novoda is a real believer in open source, we have many OSS repositories including helper libraries and demos. You can check them out here https://github.com/novoda/ and pull requests are always welcome.

Q. Where can people follow you online?

Technical & Demo Blog: http://blog.blundellapps.co.uk/
Sharing & Talking: @blundell_apps
Thoughts & Insights Blog:https://www.novoda.com/blog/author/blundell/

Kevlin Henney

In this series of ‘3-minute Q&As’ we give you an insight to some of the world’s leading thinkers and doers in the world of Agile and Software Craftsmanship.

So sit back, relax and take a sneak peek. Oh, and if you like this and want more then you should also check out sc-london.com, where you can immerse yourself in two-days of talks; discussions and networking with the authors of the blogs...

Q.When did you first come across Software Craftsmanship?

Some time around 2008, I think.

Q.What does Software Craftsmanship mean to you?

A community of knowledge and practice applied in the detail to benefit more than oneself.

Q.What do you see being the future for Software Craftsmanship?

The substance and focus will remain and evolve, but I suspect that it may find itself going by another name or becoming allied or integrated into other bodies of practice.

Q.What do you hope people will take away from your presentation?

That there's more to katas than just deliberate practice. Katas and small well-framed problems offer an opportunity to experiment, to deepen knowledge, to get creative and think laterally, to find simplicity, elegance and aha! moments in something familiar or seemingly trivial. And fun.

Q.How do you see katas being used by people at different experience levels?

I see them being used as warm-ups, as a social activity, as a way to kick the tires of new tools, languages and practices. At the most common introductory level they seem to be, unsurprisingly, about learning TDD and pairing. This remains true at other experience levels, but with other levels people seem more likely to use katas as vehicles for other ends, such as experimentation.

Q.Are there are any other methods that you would recommend to supplement katas?

Yes: immersion, conversation, presentation (giving and receiving), reading and writing. In other words, the traditional other ways of refining and exploring skills and knowledge.

Q.Are there any projects you'd like people to be aware of? How can people help out?

At some point soon I plan to start collecting contributions for 97 Things Every Java Programmer Should Know. Like 97 Things Every Programmer Should Know before it, I will be looking for short contributions on anything from the mechanics of the code to the people and practices that surround it.

Q. Where can people follow you online?

@KevlinHenney

Sandro Mancuso

We caught up with Sandro Mancuso, author of ‘The Software Craftsman’, founder of the London Software Craftsmanship Community and keynote speaker at SCLConf, to get his thoughts on Craftsmanship and growing & supporting a community of nearly 4,000 members

Q.When did you first come across Software Craftsmanship?

I heard about it in early 2009, when the first Software Craftsmanship conference was announced. I could relate to the values straightaway and in 2010 I started the London Software Craftsmanship community, the first in Europe.

Q. What does Software Craftsmanship mean to you?

For me, Software Craftsmanship has different aspects. The first is the mindset, a more ideological way of to see our profession, the desire to do things well, and an eternal journey towards mastery. The second aspect is professionalism. The realisation that our first goal is to delight our clients, helping them to achieve whatever they want to achieve in the best way possible, establishing a productive partnership instead of client/supplier or employer/employee. And the final one is career ownership. Craftsmen own their careers, investing their own time and money to improve their craft and also taking control of their own professional destiny.

Q. What do you see being the future for Software Craftsmanship?

Although almost 9 years old as a movement, Software Craftsmanship is yet on its infancy and still trying to bring to developers more awareness about professionalism and the importance of constantly hone our skills. The good news is that more and more developers and companies are trying to adopt the Software Craftsmanship mindset in their organisations and it feels we are going in the right direction.

So far the focus of the Software Craftsmanship movement, mainly inside the communities, has been on technical practices. The work the communities around the world have been doing on teaching, learning and practicing XP practices like TDD, Pair Programming, Continuous Integration, alongside Clean Code, Refactoring, DevOps, Functional Programming, software design, and a few other things must continue. As more experienced craftsmen start mastering these practices, they should start looking forward and try new things. Good practices are only good until we find better ones to replace them and that is the Software Craftsmanship mindset. We need to detach Software Craftsmanship from specific technical practices. Our job is to always look for better ways of doing things, discover new practices, and share them with the rest of the community. This way we can guarantee our industry will evolve on solid grounds.

Besides technical practices, many companies are now realising they are (or are becoming) a technology company. They may sell clothes, they may handle financial transactions, they may book hotels, they may stream videos, but at their heart, they are a technology company. A technology company should not be managed and structured in a traditional way. The Software Craftsmanship movement, that means, craftsmen around the world, must become more connected to the business world and understand that from a business perspective, our technical practices are a means to an end and not a goal. Craftsmen need to step up and start truly collaborating with the business, providing ideas, alternatives, and solutions. But for that to happen, we also need to learn new skills. The same way we put a lot of energy to master technical practices, we should also start learning how a business is run, how companies make money, and how we can help them to be more successful. Being empowered is great but empowerment sucks if we don’t have the necessary skills and no one benefits from it.

Q. What do you think is the biggest hurdle for wider adoption of the Craftsmanship Mindset?

There are many and different places have different problems. A common one is the “it’s not my job” attitude. This can be found in all levels of an organisation including among developers. Another one is the traditional top-down command-and-control management style. In an environment like that, Software Craftsmanship won’t flourish. A small bubble (pocket) may be created in a team or department but the rest of the organisation after sometime normally crushes it when one or two people leave the company or move to another area. The inflexibility, arrogance, and religious attitude of some craftsmen when it comes to certain practices can also put people off.

The Craftsmanship mindset won’t survive in a hostile environment. The adoption of a Software Craftsmanship mindset is much easier when a company already has some sort of Agile culture: people working collaboratively, short feedback loop, inspect and adapt attitude. Without this foundation, it will be hard to change the culture and introduce new ways of working.

Q. Why did you found the London Software Craftsmanship Community?

Back then I was an active member of the London Java Community (LJC). Although I learned a lot there, I wanted to create an environment where developers with different backgrounds (Ruby, C#, mobile developers, etc.) could come along and discuss how they build software. I was not interested in language specific stuff. I was interested in the fundamentals of software development: practices, design, architecture, programming paradigms, automation, any thing that every developer need to learn regardless which programming language they use. I got to learn a few things about Software Craftsmanship from some people in Chicago and UK and I loved it. I could totally relate to it. So the need to learn more and the immediate connection to the Software Craftsmanship principles led me to speak to a very good friend of mine called David Green and together, with the support of our friends from LJC, we started LSCC in August 2010.

Q. The LSCC has grown to nearly 4,000 members. What's changed since the group first met in 2010?

It definitely got bigger. :) LSCC went through quite a few changes of the years.

From the organisational point of view, as the group grew, we had different challenges. At the beginning our meetings were small and we had them once a month at a place I used to work. They were easy to organise. As we grew, we had to decide to either make our meetings bigger or have more meetings. We decided for the latter. More meeting also brought an overhead of organisation. Although many people helped over the years, we recently decided to bring the whole organisation of LSCC to Codurance. This made things a bit easier as we can have dedicated people to make sure the meetings are scheduled and organised.

Regarding meetings, members, subjects being discussed, and community aspect, I have mixed feelings. At the beginning we were a much smaller group deeply interested in Software Craftsmanship, Extreme Programming and Software Design. We had a lot of things in common and learned tons from each other. As Software Craftsmanship became more popular, more people joined the community but not because they really wanted to get deeper in Software Craftsmanship but mostly because it is one of the many “new things” out there. That had an impact on the meetings and subjects being discussed. On one hand, LSCC continues to help many developers to learn the foundations of software development and instigate that desire to do things well. And that is awesome. On the other hand, that aspect of a small community where everyone knows each other and that feeling that we are always looking forward to see each other again to continue the conversation doesn’t exist anymore. But yes, it is still a vibrant community and it is always a pleasure to attend the meetings whenever I can.

Q. Are there any projects you'd like people to be aware of? How can people help out?

Codurance has definitely become my biggest project. For 3.5 years Mash and I have been focusing all our energy on creating a company we love to belong. It’s the first time we are running a business and we are having to learn a whole new set of skills to do our jobs. It can be quite scary sometimes. And as we were getting comfortable, we decided to open an office in another country, which brought a completely new set of challenges.

Things are settling down now, and I have plans to write one or two small books and hopefully start recording screencasts again.

Q. Where can people follow you online?

Mostly on Twitter (@sandromancuso) and the Codurance blog.

Mashooq Badar

We caught up with Mashooq Badar, co-founder of Codurance and frequent blogger on a range of Craftsmanship topics, to get his opinion on Software Craftsmanship, and the balance between pursuing perfection and pragmatism.

Q. When did you first come across Software Craftsmanship?

I came across Software Craftsmanship around 2010 when Sandro Mancuso and David Green were considering starting the London Software Craftsmanship Community.

Q. What does Software Craftsmanship mean to you?

To me Software Craftsmanship is our innate desire as humans, to do a job well for its own sake. It is the goal of creating software that provides value for its users and the business - allowing us to support the business in a reliable and timely manner. Like any other craft we value the skills and practices needed to create great software. Last but not least, it is about a culture of teaching and learning.

Q. What do you see being the future for Software Craftsmanship?

I would like us to start focusing on Software Craftsmanship as a mindset where we value good practices, skills, and technologies but also understand that these are a means to an end for creating software that is timely, flexible, and valuable to the business. I would like to see us steadily raise the bar of professionalism within our industry.

Q. How difficult is it to balance the desire to pursue Pragmatism and Perfection, and how can a Craftsman know where to draw the line?

This an on going struggle within every craftsman and not just the Software Craftsman. Understanding that the software is not the end goal but the value it provides helps us balance the perfect against the practicable. To quote Richard Sennet from The Craftsman, “to the absolutist in every craftsman, each imperfection is a failure; to the practitioner, obsession with perfection seems a prescription for failure”.

Q. Are there any projects you'd like people to be aware of? How can people help out?

London and major cities around the world have vibrant communities based on specific areas of software development, not to mention Software Craftsmanship communities. Our active involvement in these communities will help us all further software creation as a true craft.

Q. Where can people follow you online?

Mostly on the Codurance blog and sometimes on twitter @mashooq.