Software Craftsman Yule Calender: 10th of December

"Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove"

Software Craftsman Yule Calender: 9th of December

"Enhance, do not replace"
part 4


Previously
"Following a plan".
"Not only following a plan, but responding to change"
"Not only responding to change, but steadily adding value".

"Contract negotiations"
"Not only contract negotiations, but customer collaboration"
"Not only customer collaboration, but productive partnership"

"Processes and tools"
"Not only processes and tools, but individuals and interactions"
"Not only individuals and interactions, but a community of professionals"


Today
Being a bit code centric today. During our pursuit of the upper, we find the lower to be indispensible.

"Comprehensive Documentation"
"Working software over comprehensive documentation"
"Well crafted software over working software"


Would you have bought something expensive if nothing told you what it was or what it did?
Would you have bought a car that the salesman had trouble starting? And would it then be of any help that you have a thorough understanding of what the car [i]should[/i] have done?
Would you have bought the car if you opened the hood and was looking at a complete mess (also in the eye of a mechanic). The fact that the car actually [i]starts[/i] will again seem insufficient.

Our profession is first and foremost to produce actively used software that creates value for our business by creating value for its customers. In and of itself, code is not worth anything.
But existing codebase is also an assett to meet future solutions and challenges. For that, we need maintainable and clean code. Code is read more often than it is written.

Software Craftsman Yule Calender: 8th of December

"Enhance, do not replace"
part 3

Building on the existing theme, another gem ensues from the Agile and Craftsman manifesto
While still recognizing the former, we value the latter more.

Thus far:

"Following a plan".
"Not only following a plan, but responding to change"
"Not only responding to change, but steadily adding value".

"Contract negotiations"
"Not only contract negotiations, but customer collaboration"
"Not only customer collaboration, but productive partnerships"


Today:


"Processes and tools"
Processes are important. They provide map and compass in a undefined terrain. You can contribute to a piece of the puzzle without an elaborate concern to every other part. You can interface others in a formal process and know both what is expected from you and what is expected by others.

"Not only processes and tools, but individuals and interactions"
Processes are means to an end.
Initially, a process surrounding a discipline is based on the experience of Yesterdays efforts and challenges. When you start taking ownership of the problem domain, you'll be able to relate to the customer base more directly and able to elicit knowledge and leverage opportunities that might not be available through the process. You'll become approachable from the customer POV.


"Not only individuals and interactions, but a community of professionals"
Eventually, you'll see that process and interaction are not opposites. You will need to define the process alongside the product as an integral part of it. It needs to evolve with the product. The optimum process support a community where actual knowledge, insight and competence within the community are naturally appropriately applied. A community that takes a solidary ownership to the totality of the end product.

Software Craftsman Yule Calender: 7th of December

"The decision making triangle"
This one is from Extreme Programming (XP).

How is a technical decision made? What forces are we trying to unify in all our procedures, phase reports, business analysis, product reviews? How is a feature request spawned and what, when presented, argues for it/against it?

The decision making triangle has three components.

The technician, who provides estimates, cost, risk and quality impact.
The customer, who translates a fluid and chaotic business domain into a concrete set of durable features.
The economist, who manages the entire backlog relating cost effective activities to return of investement, company strategy and resources.

This does not always have to be three separate individuals, and could possibly more accurately be referred to as roles/hats/influences.
If there is a crucial support issue, there is obviously no need for an explicit "customer" and "economist" role in order to respond to the matter.
Also, pair programming has a tendency to encourage being explicit and a more elaborate discourse.
Alas, these concerns should often be explicitly adressed. Not only for the quarterly review, but as an integral part of the iterative and incremental process.

As I imagine most of my imaginary readers to be technicians, we may insist that all those estimates are unreasonable. Often this may be the case, but to bring the best estimate or even the knowledge of uncertainty into the mix, is the responsibility of the technician.

This triangle is the core of the decision process, not the entirety of the team. All of the three roles may have a team of individuals behind them to carry out the respective responsibilities.

The thing I want to focus on in this post is the value of a good customer. In this context, it is not the customer with the most money or willingness to spend. I am not necessarily talking about a person outside your own company.

Above all, the customer is not a developer who has received a four inch thick requirements document in his lap.

The customer is whoever who possess the underestimated, yet invaluable, quality of translating a business problem into addressable concerns. A customer is the one who identifies the underlying durable aspects that will form a sustainable business asset.

The good customer is he whose backlog is based on, and traceable back to, true business concerns.
An organization with good customers have a good knowledge of their value flow. They can allow their model to be pull based. There are less assumptions and less liability in their efforts.

The ideal customer is he who will need the least amount of code to make the most amount of money. The ideal customer is he who lives and breathes the problem with a passion, but has a minimum of preconceptions on how it is to be solved.

Software Craftsman Yule Calender: 4th of December

"Enhance, do not replace"
part 2.

Another concrete theme on which one gradually develop to challenge established mentality, procedures and practices. And also challenge your own position.

While still recognizing the former, we value the latter more.

Excerpt from Yesterdays calender
"Following a plan".
"Not only following a plan, but responding to change"
"Not only responding to change, but steadily adding value".


And for today
"Contract negotiations"
"Not only contract negotiations, but customer collaboration"
"Not only customer collaboration, but productive partnership"

More on the value of a good customer tomorrow, which will be "The decision triangle".

Software Craftsman Yule Calender: 3rd of December

"Enhance, do not replace"

In these agile times, there are a lot of concepts that is beneficial to absorb.
But it is not necessary to do so at the expense of past knowledge.
Concepts may appear contradictive at face value, but this only means that they can only be successfully combined within a seasoned decision maker.

It is important to not only know why something in the past was bad, but also why it was good.
Not only knowing a rule, but knowing when to challenge the rule.
To identify our craft is an ongoing process with driving forces in context of existing paradigms. Don't just see the bottom line without its context.
See the train of thought, learn from history and aim to enhance on the collective knowledge that is the craft that you are a part of.
Don't just swap one doctrine with the next.

Identify with each of the following, and allow the natural progression to the next.

"Following a plan"
What can we do if we can't follow a plan? How can then others rely on us?

"Not only following a plan, but also responding to change"
We relate to a dynamic world. Specifications are sometimes truth and sometimes assumptions.

"Not only responding to change, but also steadily adding value".
Why assume that your present knowledge wont change in the future or that it hasn't overlooked or de-emhpasized something in the past?

Software Craftsman Yule Calender: 2nd of December

"Do no harm"
(The hypocratic oath revisited)

The Boy Scout rule is to leave the camp site better than you found it. This goes for coding as well as camping.

Simply check in better code than you checked out. Not much, necessarily, just a little.
Don't create a mess.
Never buy into the self delusion that you can come back and clean it up at a later time.
Don't let the code rot.

All other things in our posession:

• The Architecture document.
• The Design Document.
• The Requirement specification.
• The Test description.
• The user guide.

All these things are mere derivatives of our true core; the code.

Where the code is a mess, everything is a mess.
Where the code is rotten, everything is rotten.

Software Craftsman Yule Calender: 1st of December

"Do not be blocked".

This is so fundamental that I considered a "thou shalt not...."

Don't wait for specifications.
Don't wait for clarifications.
Go with what you have. Influence the decision with what you know and what you can do.
Make functional samples, sketches, proto types. Duct tape is allowed.
Seize ownership. Become integral.
Learn the problem by spending time in the problem domain.
It is allowed to throw away software. Even newly connected neurons is a benefit.
Something tangible and concrete produces tangible and concrete feedback.

Introducing: The Software Craftsman Yule Calender

In this series, one for each workday up till Christmas, I'll explore an isolated piece of what I consider to be important factors of the professional software developer.

There may be repeptitions from earlier posts, but this time its succinct form will hopefully enhance its take-away value.