Is TDD Evolving?

that-word-inigo-montoya-word-think-means-princess-bride-mand-demotivational-poster-1260739585Something strange is going through TDD land these last couple of weeks. First it was Uncle Bob,with a new TDD theory – making tests pass in a certain order, actually helps incremental design, leading to a better solution. This is a very interesting post, and if he’s right, he might have discovered the cornerstone of ALM 2.0.

Following that Mark Seemann’s TDD Apostate questioned the assumption that TDD is a magic bullet for good design. A week later, Michael Feathers posted on the same subject from a different angle: how language and design granularity affect the resulting design of the code.

What do the three posts have in common?

TDD is not what we thought it was.

  • Uncle Bob says there is a blind spot in the current TDD process. If we could just identify it, it would help us get to the great design systematically.
  • Mark Seemann says TDD is not a good design tool by itself. It could be if you’re a good designer. But by itself, it’s just a process.
  • Michael feathers says TDD is affected by the environment, namely your code starting point, and even the language it’s written in.

Let’s not jump to conclusions. TDD has not failed. It has not even changed direction (at least until Uncle Bob or Michael Feathers prove me wrong). But it is the first shift in over 10 years in one of the most uncontested practices in XP or any agile methodology. Apparently, we don’t know everything about it.

TDD does not guarantee a good design. If you know what you’re doing it will probably work. If you know about SOLID, if you suffered from code maintainability in the past, you’d probably get a better design eventually. But it’s up to the driver.

TDD is still THE responsible way to develop software. It’s main value: It makes you think before you code. But it won’t prevent you from messing up if you don’t know what you’re doing. Placed in inexperienced hands, it will blow up in the face. Without knowledge in software design, it’s just a technique that produces tests.

I’m really interested to see where TDD is going next. For the time being, I suggest we go back to the original TDD acronym, though, where D stood for Development. Until we know better, let’s not make promises we can’t keep.

Gil Zilberfeld

That One Little Bug

skype-bugThe first thought I had, reading about the Skype meltdown last week is: here’s another opportunity to score points for unit testing. Nothing like a a single bug causing so much havoc (or silence, in this case) to get developers attention to the catastrophes waiting to happen.

But I decided to go deeper. There are few lessons in what happened to Skype, and indeed, a few more services we’ve become so dependent on lately.

The power of one bug. The Skype bug managed to disrupt businesses, not just consumers. I rely heavily on Skype for business calls. And like many others, was left stranded. Would you  build your business around such a fragile infrastructure? (the answer is of course yes, we won’t really change our ways. We’re too addicted. But we’ll think twice, and maybe spread the risk so we won’t get hurt too much next time).

The cost of one bug. Think about the damage to Skype and its likes – this small bug will have investors thinking twice before putting money in infrastructure companies. Who want their name tarnished like that? I always talk about how a bug’s cost to the company is huge once it’s out of development. Case in point. The reputation drop alone is immeasurable.

At some point people see the light. Could this bug have been prevented? Maybe. With proper practices, like code review, unit tests, acceptance tests – it may have been found before. I don’t know if Skype does them, and I recommend they do. They did see the light according to their CIO – they need more testing.

Overcome by complexity. Could the consequences of the bug been foreseen in advanced? I expect that if they did, Skype would pour in all their resources in their power to prevent the bug from seeing the light of day. The world of software has become so complicated, there’s no way to test every scenario, and even perform a calculated risk estimation. In unit testing you write tests for certain scenarios. It’s simpler to anticipate and comprehend these scenarios in the unit level, and therefore make sure that code is protected. It’s still a tool to beat the odds, rather then anticipating and comprehending much more complex scenarios.

Built to last? Software is evolving so quickly, we need disasters like these to take lessons in how to build systems. And these lessons are very costly. Architects, as expert as you are, this is a good opportunity to take a good look at your company’s architecture. Will this happen to you?

Communication is everything. At first there was silence. Not just from Skype’s customers. From Skype management. For 24 hours, there was no status reports, no idea what’s going on, and when is this thing going to be over. At times of trouble, more communication is needed. More messages would have at least make an impression that Skype is actually doing something to handle the crisis.

The path to improvement. Now they are talking, and explaining the cause, and how things deteriorated. It’s not just Skype that needs to learn and improve. Other companies can learn from this as well. I applaud Skype for dealing with this openly. They show us no just that they intend to improve – they show others the way too.

It will take time until most companies will understand the impact of bugs,and the much lower cost of preventing them. We can learn how to communicate and understand where visibility helps. We can learn from these disasters and improve.

Until next time.

Gil Zilberfeld

My Next Big Thing

yesIf you’re like most people you’re under-resourced. You have many more tasks than you can handle. Your team is fully booked. And the work keeps pouring in. They ask:

“What should we do first?”

What should we work on first to go into the product? Bugs coming in from support calls? Maybe this cool new feature? But this new feature will take few weeks to implement. Maybe we should be working on the smaller tasks to help track usage of the other features? Or maybe just we should work on examples and documentation, as our customer feedback suggests?

That’s the tough job of the product owner. Sure, talking to customers is fun, but in the end, this is the guy who actually decides what goes into the next release. Deciding who gets what first, and who will wait impatiently. Big responsibility.

Starting this month, that’s my responsibility at Typemock.

Actually, there’s more than that. But I’ll save that to later posts. I’m very excited about this new challenge. And I’m going to learn a lot on this road, stumble a few times for sure. An agile product-centric company, creating products for agile developers -  Man, this is becoming so much interesting than before.

Stay tuned. Interesting stuff ahead.

Gil Zilberfeld

Agile’s Secret Ingredient

Today's secret ingredient is...I’m a big fan of Manager Tools. I’ve been listening to the podcast and recommending it to anyone, manager or not, for the last five years. A recurring topic in the podcast is Manager Tools co-founder Mark Horstman’s laws:

  1. It’s all about people
  2. More communication is better.

And there are more, and I invite you to listen – amazing material.

Working on the latest Typemock webinar, “Agile Starter Kit”, I realized that these two laws are basically  fundamental for agile practices. They appear in this part of the agile manifesto:

“Individuals and interactions over processes and tools”

Once you understand this, the next step in leading change toward agile is this:

Be Nice.

That’s right: Not just unit tests, continuous build or demos. If you want to get people onboard, you need to be nice to them. Be respectful. Listen to them and communicate accordingly.

Once you understand this and start acting this way, you can actually take on processes and technologies. And you’ll be much more successful.

Below you can find the webinar and slides.

Agile Starter Kit from Gil Zilberfeld on Vimeo.

What is the #1 Benefit of TDD?

tddI was asked this question last Wednesday, when I led a TDD open session at the Israeli Software Craftsmanship User Group.

My answer: It makes you think before you write code.

In fact, next time somebody asks you what TDD stands for, you answer:

Thinking-Driven Development.

Sure, all the benefits are there: structured incremental progress, good coverage, and confidence when refactoring.

But over and over again, when I see people starting to think about their first test, it comes back to me: It’s the think-before-you-act thing.

In that session, we did the kata for counting code lines (3 times with 3 different groups). And three times, almost at the beginning, questions came up:

  • What constitutes a line?
  • In what language are we writing?
  • Do we count blank lines?
  • does an “if” block counts as one line, even if it spreads over four lines?
  • Does a line need to contain compiling code?

And so on. All of these questions came up before the first test (empty string, zero lines) or immediately after it. This kind of thinking and discussion before writing the code is what makes quality code.

So repeat after me: TDD is Thinking-driven development.

See how it rolls off the tongue?

PS: You can read a recap in Hebrew about how awesome I…, I mean, the meeting, was).

Gil Zilberfeld

Big Wednesday

It will be for me.This Wednesday, December 15th, I’m going to be a bit busy.

3pm Israel time, that’s 2pm CET, and 8am EST I’m giving a webinar about steps you can take right now toward agile. I really like to learn real world actionable stuff, and this webinar is where I’m giving back. Do you want to know what to do if no one joins your stand up? 

Register here.

software-craftsmanship-manifestoAlmost immediately following that, I’m off to the Israeli Software Craftsmanship User Group  (6pm IST). This time we’re going to have a sort of a baseball game – we’re going to have four bases. I’m manning the TDD table. We’ll also have a DRY table, code review table, and a TBA table. That’s “to be announced”, not a new design acronym. People will swarm from one table to another like big flocks of birds, getting a taste from each delicacy.

And if you’re living in Israel, or planning a quick visit to Tel Aviv on Wednesday – come join me. Register here.

I’m also doing other stuff on Wednesday, like work, but other than a few people I plan to meet, your not invited. Use the two other links to say hi.

When Worlds Collide: Agile Vs Kanban

When-Worlds-CollideI’ve witnessed a sort of agile/lean clash incident at our standup. Reviewing our kanban board, as tasks completed, others were left on the board. Instead of completing the tasks in progress, a developer decided to pick new tasks to work on, entering them into process.

The Clash 

Agile promotes team empowerment. Developers are encouraged to pick their next tasks, based on their best judgment. In this case, the developer picked tasks that were easy and quick to complete – clearly using his best judgment.

Lean teaches us to minimize work in progress. If there’s a task in the pipe, it makes sense to complete it first prior to starting another task. Adding value.

I don’t think there was a violation of the process here – there was no task prioritization, and the work limit was not breached.

But it does show that a mindset change is required to travel between the two realms. Which is kind of ironic, because agile is all about successful change.

Gil Zilberfeld

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More