Software Craftsmanship: Need of the hour
The word craftsmanship usually brings to mind images of a sculptor chiseling intently to perfect a beautiful sculpture, a potter shaping the neck of an elegant vase, a watchmaker tinkering with the minutest of gears, and so on.
You don’t picture someone writing code. You don’t imagine someone gathering requirements from a client, or identifying test cases.
That’s because conventionally, software is valued by its utility, not its structural or aesthetic beauty. Software is deemed great if it solves the problems of its customer or user in the best way possible. It is deemed great if it delights its customer by providing or adding business value.
At the heart of every software development project is the customer’s need or the business problem which the software will address.
So what matters most is how well the software addresses the customer’s need and is it user friendly, fast, secure, stable, reliable, scalable or maintainable while doing so; not how well named the classes are under the hood.
And yet, leading lights in the field of software engineering and computational thinking have suggested that software engineering be practiced as a craft.
The idea of “software craftsmanship” has evolved from a brief pitch in an essay, to the basis of many seminal books, to the foundation of a manifesto and now a global movement!
At Technogise, one of our core values is craftsmanship. As technology partners to our clients, we are committed to build well crafted, elegant solutions for them.
Why?
Is there a need for software craftsmanship?
YES… and here are the reasons why:
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
SOFTWARE CRAFTSMANSHIP IS VERY MUCH ABOUT THE CUSTOMER
The concern that most critics have with the software craftsmanship movement is that it threatens to put “code over customer”. It risks putting software at the heart / centre of a project, rather than the benefit it is supposed to deliver.
This concern though is unfounded because software craftsmanship never de-prioritizes the customers or their needs. Indeed, half the manifesto is about the customer!
It talks about steadily adding business value to the customer (not just responding to change) and creating productive partnerships with the customer (rather than just collaboration). That is an apt extension of the (already) customer driven Agile manifesto.
An application can only be considered well crafted, if it brings about the benefits the customer intends it to.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
SOFTWARE CRAFTSMANSHIP DOESN’T COMPROMISE UTILITY FOR BEAUTY
Critics argue that software craftsmen, in their pursuit of writing that “perfect piece of code” (…all SOLID and XDDed…), may lose sight of whether their code is doing perfectly what it is supposed to do.
Again, this is incorrect because software craftsmanship never claims to place structural beauty above utility. A “perfect piece of code”, first and foremost, does what it is supposed to do in the best way possible.
The manifesto espouses “not only working software, but well crafted software”. Critics probably do not read the “only” in that sentence 🙂
Do any of the design principles / engineering practices associated with software craftsmanship negatively impact or compromise the utility of software? Not at all.
When done right, software craftsmanship results in making applications more user-friendly, fast, secure, stable, reliable and scalable. Not less usable.
And if a craftsman makes an application less usable because they want to “adhere to a principle”, then they haven’t really understood software craftsmanship.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
SOFTWARE CRAFTSMANSHIP SHOULD HELP DELIVER SOFTWARE FASTER
Another concern with software craftsmanship which is cited often is that it compromises timely delivery.
This is because more than practices or principles, software craftsmanship involves adopting a new mindset. It definitely takes time, and an open mind, to change a mindset which has approached software development and delivery for years in a certain way.
But then this was true for Agile as well.
In the initial years, teams were unwilling to implement TDD because of the time it took them to even start thinking in that fashion. The time taken to adopt the TDD mindset caused delays in delivery and risked engagements. But now, teams which practice TDD (…not as gospel, but pragmatically, as it’s meant to be…) are delivering as fast, if not faster than they ever did before.
It’s true that customers don’t care about your practices. They want the software they need, on time. But then, every innovation in software aims to deliver the best software in the fastest time. How can the aim of software craftsmanship be any different?
Think about it! Programming practices and languages seem to be evolving with the sole focus of writing less lines of code to achieve more. A task which took 25 odd lines of Java 7 code to execute can be done in 3 lines of Scala. Principles like DRY / KISS and practices like TDD are keeping developers from writing any extra / unnecessary code. Tests and paths to production have been automated.
If anything, the software craftsmanship movement is, and will be, focused on faster deliveries.
Again, a craftsman who delays delivering functionality because of being indulgent with his / her code, either hasn’t understood software craftsmanship… or isn’t doing it right.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
IT IS VERY MUCH ABOUT OTHER ENGINEERS TOO
Earlier, we mentioned that software engineering isn’t a conventional craft because the product is valued by its utility, not its structural or aesthetic beauty.
Now, we will make the case that software engineering should INDEED BE CONSIDERED A CRAFT and must also be valued by its beauty.
That’s because while the software you create is used by a customer, it is maintained by other software engineers. And just like your responsibility towards the customer, you have a responsibility towards these engineers. The least you could do is create code which is easy to maintain and support.
All this focus towards naming conventions, indentations, simplicity, domain driven design etc. makes your code easy to understand, navigate, support and maintain. The uglier the code under the hood, the harder it is to maintain. As responsible professionals, shouldn’t you avoid giving nightmares to your fellow professionals?
By the way, maintenance of ugly code is also costlier; requiring more personnel for longer durations. There are software industries, even economies thriving on large scale maintenance projects.
Guess who has to pay for these extra maintenance costs? That’s right; the customer, who was at the centre of your project.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
SOFTWARE CRAFTSMANSHIP NEEDS TO BE A CULTURE
Look at the bigger picture and you will realize that adopting a culture of software craftsmanship can transform the way many software industries are run… and perceived.
Today, there are many software industries which thrive by maintaining or supporting software created by others. They are not reputed enough for (…and therefore not trusted enough with…) creating mission critical software from scratch.
This is because of their pervading culture which believes in mechanically churning out code and being satisfied with it as long as it is “working”. A culture which doesn’t bother putting enough intellectual thought into making code “better”.
On the other hand, the culture of software craftsmanship makes people explore and understand why they are coding what they are coding. It makes people value their code and explore ways to make it better. And only an industry with that culture of exploration can be trusted to innovate and create revolutionary software.
This is why software craftsmanship needs to be propagated. This is why the manifesto encourages building a community of software craftspeople, who can in turn spread this culture.
In countries like India, where the IT sector is still primarily driven by “support projects”, it is the need of the hour.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
THE ONE REASON WHY THIS MOVEMENT NEEDS TO TREAD WITH THIS CAUTION — PEOPLE
As Dan North puts it in his influential critique of software craftsmanship, people are romantics with big egos.
The word “craftsman” itself has a sort of elitist vibe (although less elitist than “artisan” 🙂).
Will this movement give rise to prima donnas with a false sense of entitlement? You bet!
Will there be those who let their romanticism towards code overshadow their pragmatism towards delivery? Absolutely!
This movement needs to tread with caution therefore, making sure that its practitioners lose neither their humility nor their pragmatism in their quest for craftsmanship.
Other movements have suffered when their followers turned irrational fanatics. That infamous eulogy to TDD was understandable.
Maybe the manifesto could have a disclaimer which says “you won’t be a craftsman if you are not humble and pragmatic” 🙂
Then again, pompous arrogant fan-boys are gonna remain pompous arrogant fan-boys, no matter which movement or “technology fad” they are associated with.
Prima donnas are gonna remain prima donnas regardless of what they call themselves. There is no cure for it… 🙂
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
A FINAL THOUGHT — COULD CRAFTSMANSHIP BE EXTENDED, IN SPIRIT, TO EVERY ASPECT OF SOFTWARE DELIVERY?
When you consider coding a craft, you value your code and strive to write better code every day. When you consider testing a craft, you value your tests and make them better every day. So why not consider requirement gathering a craft? Why not consider business analysis, or visual design, or project management, or devops, or deployment a craft?
If elevating an activity to the level of craftsmanship can make people value that activity and strive to do it in the best way possible, then maybe we should consider extending this pedestal to every aspect of software delivery.
This will only give rise to a smarter software industry in the time to come.
