Adopting the blind spots.

A clear distinction between the master and the apprentice is the mental model that they operate from. If a relevant concept is clearly absent from your thought process altogether, it can be described as a disability.

I am currently visiting legacy code written by novice programmers. This code base clearly demonstrate a lack of separating microsecond, millisecond and second domains. Disk access, sql server access and web service in the middle of loops. Although there was an elaborate architecture to separate the service level from the data level, comprehension of the penalties involved by ping-ponging between them in the control flow timeline appears to have been void.

The code made absolutely no sense until I started adopting the thought process behind it. And suddenly I was able to leverage the blind spot, foreseeing likely sore spots.

 

Socrates said that the hallmarks of an educated mind is to be able to entertain a notion without adopting it.

Software Craftsman Yule Calendar: 22nd of December

Todays word is “Pair programming”

Two persons, one keyboard, preferably with two duplicated screens.

The keyboard passed back and forth.

The pair does not have to have equal time on the keyboard. Just multiple people present and productive software engineering being performed, then it is pair programming.

Passing the keyboard gives you the off-beat repertoire of focus change, picking up long term concerns. The brain gets its timeout without you grabbing a coffee, visiting the cubicle next to you, checking the mail or opening the web browser.

Between them:

• Blind zones and derailing are reduced to the least common denominator.
• Experience and resources is more than the sum of the two.

“Benefits of pair programming” is obvious to anyone who have given it a serious go. Rather, I’d rather be discussing “the risks of solo programming”.

Having to sell every story, you learn to communicate intent, to avoid tangents, to break out of your mentality in order to try the other perspective on for size.

And it’s social. Software is more and more about people, processes, communication and interaction.

Something that I think this post’s co-author, Anne, agrees with.

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.