Software Craftsman Yule Calender: 15th of December

Todays word is "Lean"

We're paid to produce and maintain code, right? So, by producing code we are productive. And by maintaining the same code, we are even more productive.

Well, not really. Without manifesting any business value, this is at best a zero sum game.

Code has cost of ownership.

Code made on assumptions is a business risk.

Code of poor quality is a liability.

Code or poor quality that must be maintained is a design debt.

Ill conceived concepts confuse, distract and disrupt within an organization.

As coders, we need for our managers to understand the nature of the beast that is code so that they can make informed decision.

Developers often complain about management, but have you ever considered that they may just be on the wrong page of their finance text book? That such-and-such wasn't really an assett aquisition scenario, but rather a risk management scenario.

Lean is about identifying business value to facilitate focused effort. Lean is about amplifying learning, defer decisions, delivering early value and respond with minimal overhead.

　

• Define and identify values.
• Define, indentify and innovate value streams.
• Promote value flow.
• All activity should have an active stakeholder downstream. Pull based.
• Refine the process.

Software Craftsman Yule Calender: 11th of December

Todays word is "Agile"

Let's start by saying that if you have a cross and rigid definition about how to be agile, then that is a red flag already there. Some corner stones exist, though.

Iterative
Short cycles. Complete cycles. Reflecting the entirety of your business. From concept to deliverable. From "not done" to "done" or "not done and here's why..." . Not "half done" or "done, but...".

Incremental
The business assets shall have a net increase. Liabilities shall not exceed the investment of the ongoing cycle.

Cross functional teams
The team shall have the competence, ability and means to produce. The need for predicted external involvement shall not be of a nature or quantity than what can be assigned the SCRUM master. This is mostly to remove impediments, not engage externals with detailist assignments.

Self managing teams
Specialized assets within the team should naturally gravitate towards the appropriate tasks that requires them, but not at the expense of the team members assuming a collective ownership to the entirety of the end product.

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".