Craftsmanship antipatterns

Craftsmanship is young buzzword and pretends to second software development methodology proposed by (enough expected) developers. First was XP.

Scrum and Kanban from other hand are products of managers.

I had fantastic experience of work with team driven by craftsmen last 6 months. It's very interesting that they almost not used boards and meetings. All activity was around code, commits, refactorings and spikes.

We're living in Middle Ages of counting age of our industry. We have a lot of missconceptions and wrong stereotypes.

I'll try to describe those missconceptions which I saw in my personal work of team lead.

It's not polished and raw set of examples. But I want to share and discuss them at this early stage. Blogs were invented for this purpose, right?)

So... first antipattern (in ruby style).

:only_senior_developers_needed

Imagine existing project with big amount of really bad code. Previous team was fired because they have no ability to support acceptable performance due catastrophic state of code. Customer is expecting several very important releases and adoptions for big clients and killing solution was... hire new team consisting only form senior developers. Primary task for this new team is adding more features.

Actually managers tend to resolve in old industrial method many problems in development process or even ideology of existing team - by hiring super star developers.

What is final of this story? Even superstar team can't resolve big technical debt in the project. Several business plans around new features was broken and finally project was cancelled.

Solution: use right ideology and right system of values. Right test suite and continuous refactoring are only possible solutions here.

UI vs behavior requirements

When collecting requirements, we mostly used Given/When/Then textual patterns which represent logic of the system behind the scene.

UI was not recognized as a generic part of User Stories.

But now we started practices of simultaneous discussion of both UI and behavior. Even more, we're thinking that UI and behavior are crossing aspects of each User Story. And UI and behavior very similar to interface and implementation according to OOP concepts.

Controlled detalisation

Software development is process of detalisation. Customers are talking mostly about "WHAT" and uses very high level of abstraction.

Programming is all about decreasing level of abstraction and fixing a lot of details.

There is very dangerous area of transition between "WHAT" and "HOW" domains. Or between Problem and Solution.

BDD is tool for entrance trough this dangerous area.

Craftmanship is all about Controlled Coding Reaction. It includes simplicity principles and constant refactorings.

Non controlled coding reaction leads to explosion of software development project.

If we have weak process of collection of BDD scenarios, or we're writing code for future, or we don't use TDD (primary toolset for controlled coding) - we're moving to space of dead projects.

Craftsmanship becomes a methodology

While Scrum and Kanban are more industry agnostic, XP was the sole software development methodology so far.

It's looks like we can see appearing of new software dev methodology - craftsmanship. It is fusion of TDD/BDD from one side and set of code heuristics for code reviews and refactoring from another side.

This methodology devides development process onto 2 areas - business and coding. And natural boundary between them are tests.

Acceptance tests supports business domain and unit tests or specs supports coding domain binding them together.

This methodology has ideology - details matter.

This methodology is very close to BDD but BDD has more local application for internal protocols inside acceptance tests and unit tests.

Craftmanship it's all about honesty thinking and talking about details and their simpliest implementation. It's about permanent code refactoring and not thinking about future but about better solution for today.