This Masquerade
Can Software Craftsmanship be Nurtured?
Craftsmanship is not limited to carpenters. Even suggesting it is limited to the building of a physical construct is an ignorant statement. My inner perfectionist always attempts to guide me down the path of doing the right thing in everything I do. Naive as it sounds, this also applies to the software that I build. Craftsmanship is defined as the quality of design and work shown in something made by hand. Users do form subjective opinions on the quality of the software they use.
Software is not tangible, so measurement of our level of professionalism is challenging. Nevertheless, that doesn’t mean we can just hack it together. Wiser people than me have highlighted the importance of building software the right way. This week in particular, thoughts around the Agile community and their relationship with craftsmanship have triggered considerable debate. Here I ponder how to identify software artisans, and whether mastery of these principles can be nurtured.
Let Me Be The One
There are indeed individuals already out there that take immense pride in building high quality software. All technology firms want to hire the best talent. Those who continually strive to increase their software development acumen are the talent organisations wish to attract. Is it safe to assume that our hiring process will distinguish between cowboy coders and professional programmers?
Identifying a passionate technologist doesn’t guarantee that they will build software the right way. People may say the right things in an interview, but it’s important to extract if potential engineers practice what they preach. Beware the situation of an interview turning into a game of buzzword bingo. Asking probing questions is the sole method of validating whether they have experience in applying these techniques.
To measure the mastery of any potential engineer, live coding exercises in interviews should be mandatory. Our recent hiring has focused on coding exercises both before and during on-site interviews. Nevertheless, this may not be enough. You can discuss design and implementation considerations, but in a few hour interview candidates are less likely to showcase practices such as TDD. Only once they are producing code as part of your team can you truly assess their degree of professionalism.
It’s Going to Take Some Time
Once these sprightly software engineers have been integrated into the team, managers are able to critique their level of craftsmanship. The true test is when they are put under pressure to deliver. Agile methodologies such as Scrum and Kanban provide techniques to ensure a constant work rate. Limiting by time or concurrent tasks is intended to protect programmers. Regardless, I still see managers pile on the pressure to deliver user value. It suggests we are treating programmers as mindless zombies, responding to every order by frantically rapping on the keyboard.
I’m afraid to admit I’m also guilty of this phenomenon. To meet the deadlines imposed by managers, developers are delivering features far too fast. With such velocity, quality is compromised. I’m not just talking about conceding on test coverage. That is merely one attribute that limits the ability of our software to stand the test of time.
Insufficient discovery time will result in building of features that may not scale to the intended use case. Bad smells will also creep into the code. Any artisan engineer will tell you compromising on craftsmanship in this way is not worth the accumulation of technical debt. Like any mortgage, you will have to pay down your debt eventually. Rather than being threatened with foreclosure, the system will become difficult to maintain. Working on indebted code bases fosters developer frustration that may ultimately result in your better engineers leaving.
We’ve Only Just Begun
Not all engineers will be skilled software virtuosos from day one. I certainly wasn’t when I first walked in the door as a bright eyed graduate seven years ago. I’m still working on building my own skills. Talent should be hired not only for the skills they have, but their potential to improve and become pragmatic programmers.
Craftsmanship is fostered through culture. An established team can still be encouraged to improve their craft if nurtured. Reading is vital in our quest to improve as software engineers. Although practice makes perfect, only writing code will never make you the best developer you can be. Honing your craft requires seeking additional sources of wisdom, and contemplating the ideas projected. Books, blogs, tweets, tributes. All will provide insight. Teams should become comfortable sharing resources. It is not just a managers responsibility to assign out reading material. We’re not in school anymore kids!
Writing code regularly is essential. Continually assigning the same tasks to the same developers time and again will encourage skill stagnation. Personal tinker time is also a great mechanism for supporting the technical development of engineers. Michael Lopp advocates keeping a Tinker List of the technologies you wish to investigate in Managing Humans. Managers and programmers alike need to experiment with new technologies. They must also scrutinise the inner workings of frameworks which they currently use. Dedicate regular time to trying out technologies and techniques. Only then can we continue to master our craft.
Thanks for reading. Claps are always appreciated!
