Software Craftsman Yule Calender: 21st of December

Todays topic: “The Jury is in on TDD, there are no more excuses”

• Test driven development is superior
• Test driven design is superior

Patient and meticulous grinding at the base level. Driven by the precise execution of core disciplines, reverberating chants of  Red-Green-Refactor down along the aisles of craftsmen.

TDD forces you to taste your own API. The customer comes first. No work is done until the desired task is purposely expressed in jargon meaningful to the client.

You suddenly start to work with a flexible base material. You keep it and yourself flexible by you continuously flexing it.

It is a coding learning experience where the feedback is immediate. Instead of a feedback cycle of hours to weeks, the slap on the wrist is immediate with the guilty misconceptions and the accomplicing mind set still at the scene of the crime.

• Of course it’s a new discipline.
• Of course you will be worse before you get better.
• Of course it takes a different mind set to be the bringer of change rather than hoping to not be awakening the beast.
• Of course you wont find the flow from the get-go.

BUT:

• When you have the assurance of the green light and due confidence in its significance.
• When you play for keeps, knowing that people will have to get by your tests to break it.
• When you don’t have that uneasy feeling of having to go back to recheck something.
• When you know that you check in better code than you checked out.
• And you know it works.

…. then it will start to feel unnatural, and unprofessional, to do anything else.

Software Craftsman Yule Calender: 18th of December

Todays topic "The only way to go fast is to go well."

(Before starting this little series on the software craftsmanship yule calender, I approached uncle Bob to see if he would pitch in. This was one of his contributions. He has several talks of this, much of which is used in this blog post.)

The Paradox:

• How many of us have been considerably delayed by bad code?
• How many of us have written bad code to save time?

Consider a new project.
Everybody is motivated. No legacy code to slow us down. We have the newest toys available. Productivity will be unprecedented blowing everybody away.
And everything blasts off exactly as we thought. Magic sparkles between our fingertips and keyboard. The rest of the team is mesmerized. The project manager becomes bold. His faith in the programmers is restored. They have his back. He's got theirs.

Then, gradually something changes. Estimated starts creeping from days to weeks. Certain things are constantly facing small setbacks both in terms of feasibility and estimates. Developers start checking in code that they hope have seen their last revision for a while. The components starts getting personal with who is fit to be working on them without breaking stuff. Productivity suffers. Arbitrary flexible deadlines are postponed. Inflexible deadlines starts forcing stuff.

The mistrust starts accummulating. The external behaviour of the developers starts to reminisce lazyness and sloppyness. After all, why else would the tasks that was complete in days now take weeks to be half done? If parts of the team has been replaced in the meantime, one might also assume that one is left with a worse group of programmers.

The problem is that the team has created a mess since day one.
The deluded initial productivity was a result of stealing from one of the most unappreciated and obscruely measured liabilities of code ownership: design debt.

Mess accumulates. Mess begets more mess.

How do you deal with mess? You clean it up and you don't make it in the first place.
Don't cheat.
Don't assume you will come back later and clean it up.

When it comes to software, it never pays to rush.

Software Craftsman Yule Calender: 17th of December

Todays word: "Waterfall"

As stated before, it is important to not only recognize the faults of past paradigms, but also the fortés which gave rise to them in the first place.

Such a beast is waterfall. It was originally contemplated because software is difficult to change. That is its premise. Code commiting design. You need good upfront design before committing to code. And you need good requirement specs before committing to the design preceding the code.

All this changes when code no longer commits design. When software, when properly groomed, is painless to change. One of the primary motivations for waterfall does a 180 degree turn overnight.

But still, waterfall may still be suitable and sometimes even necessary.

Suitable:
* Irreduceable designs. Some designs are based on a design vision that would be hard pressed to be achieved incrementally.
* When specs will not change. When there is no reason to assume that there will be any learning curve underway from start to finish. Neither with the developer or the stakeholder. If I can get all specs up front, I will gladly receive them. I just don't think this will be true more than once or twice in a life time.

Necessary:
* Even though well crafted code now responds well to change, there are still elements to solutions which do not. Such as business contracts, hardware and third party stuff.

Software Craftsman Yule Calender: 16th of December:

Todays topic is "The gaffa tape programmer

I strive to hone my coding craft at any opportunity.
I don't see them to be at odds with any other priorities in the coding domain.

However, I do mash stuff together sometimes, what is otherwise known as "Gaffa tape programming".

I don't always strive for complete 100% coverage. I strive to identify pockets/domains within my code that warrant TDD. The more I can fit into those pockets, the better. The more I can compartmentalize the material, the better.

But when the building blocks are in place so that I from the offset can purposely express a end task in the suitable pseudo language that rise from existing components, I "mash" them together.

Yesterday, I noticed that the old comic book series "elf quest" was published on the net. (www.elfquest.com) as it no longer was going to be printed. You could browse the comic book online by clicking "next", "next" etc.

I made a web crawler to scrape it onto my hard drive. Three loops: one "do-while" and two "for-each". No tests.

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"