Software Craftsmanship (Commentary)

The term "craftmanship" is nowadays used mostly for the arts, or for hand crafted goods, nobody would really think about a programmer "crafting" code, much less a software architect.

Regardless of if software is considered an art, a science, or a craft, we cannot deny that most code we produce, inherently has something of ours in it, let's call it a personal touch. Software Craftsmanship begins with pride for one's work, much like an artist's pride, but it also comes from an idea of "whole".

A software architect cannot stay on the sidelines of the way code is being developed, they must be first and foremost coders. Otherwise, how could anyone be able to feel pride of the code that is being produced in one's project?

Software Craftsmanship also carries the notion of improving any and all code the coder participates in. "Leave the camp tidier than how you found it", as the boy scouts say. This is how craftsmanship defferentiates itself from old regular Agile Development.

This concept contains the core of several others, such as speedy development, quality assurance, Software Architecture, and proper refactoring, all based on the principle of "love for the craft".

Is Design Dead? (Commentary)

Reckless programming is a hobby of every high schooler with interests in computer sciences, or any computer sciences freshman.

We tend to think that if we know some of the quirks of the given programming language, we do not have to think too much about what goes into developing, because we are not entirely sure about how the program is gonna look like either functionally, or in code, we just do what sounds right for us.

Apparently, "reckless programming" shares its main philosophy with the more official sounding (official-ish) "extreme programming", when it comes to complete and utter disregard of design and/or planning. We know what our code's goal is, we'll know if it accomplishes it, we do not really care about how each module or part of the code works towards this goal, or how such modules will change, but we may know how we want them to change towards the goal.

Here's the thing, though, disregard for rules, although fun, also carries the stigma of messy and unmaintainable code. If no planning is done for the development, we cannot expect to have plans for when everything finally fails.

On top of this, if refactoring is not considered, well, we are gonna have to start all over.