“ROI is Dead!” Video from ACE!

I should have put that up earlier, because Paul Klipp had posted it a day after it was recorded.

Paul (and the volunteers) did a marvelous job at ACE. I hope to go there next year again.

Managing the Expectations from Agile–Interview on InfoQ

I was interviewed by Ben Linders from InfoQ. I talk about how organizations look for agile to save them, what they expect, and what’s needed for actual success.

This is the first part, stay tuned for the second.

Managing the expectations from agile

“New Agile” Slides from #AgileEE

Had great fun presenting the New Agile today at Agile Eastern Europe in Kiev.

Here are the slides.

And the original (longer) session slides are here.

Also check out the New Agile Posts on the blog:

“ROI Is Dead” Slides from #ACEConf

Had a great time presenting at ACE!

Here are the “ROI is dead” slides.

The Power of Testability Compels You (Not)

Once more I get into a training session on unit testing, and once more I hear “It feels wrong to change my code just for testability.”

My immediate reaction was “because the design you have right now is so good, right?” (yes, I said it out loud).

Let’s break it down.

Good Design, Bad Design

Any design is a choice. All problems have multiple solutions, and the current design you have was the chosen one. It may also look like a giant god class (or a demon class, like our subject in the picture). It’s like that because you (and others) have made design choices over weeks, months or years not to tidy it up. You may have excuses:

  • I didn’t write this code
  • If I change it, it may break something else
  • It’s an architecture created by someone else
  • I don’t have time

All may be valid, and still – excuses. You, as current caretaker of the code, decide whether to  continue with the current design or change it.

Once we’ve passed that, let’s assume you want tests around this code, because why was I invited in the first place?

Ch-Ch-Choices

The reason you want tests is to enjoy their benefits. First among them: The ability to change the code with confidence. Tests (of any kind) raise your confidence about the status of your software. When you change your code for fixing bugs, adding features or just plain refactoring, you want to know things that worked, still do.

So now the question is: If you want tests (a wise choice), what are you willing to do to get them? Is changing the code part of the cost?

Again, it’s a matter of choice.

All code is testable. With tools like Typemock or PowerMockito, we can mock whatever we want. Therefore, we can write tests around code that’s packaged in any design. Or we can use less powerful tools and require to change the code in order to test and mock. There are always tradeoffs. Price, for example.

Here’s another: One of the problems I have with PowerMockito is that it sometimes throws a VerifyError (that’s unverified byte-code error, not the method-was-not-called error) which mere mortals don’t understand, and don’t know how to work around. So I’d rather persuade people to use regular Mockito than face unsolvable problems. And Mockito requires changing the code, where the “It feels wrong” discussion started.

On the other side using the power tools and leaving the code as-is is also a choice. If you built tests with PowerMockito or Isolator on crappy code, and leave the code crappy even though now you can improve it, it’s a choice (a crappy one).

Tools don’t make people write better code. They don’t allow bad code to thrive either.

Your design. Your decision.

Space–The Final Frontier

When we bought our house, we designated one of the rooms as “ the computer room”. It was kind of small office, with a couple of book shelves. Then, with the children, we’ve added more cupboards and shelves and computers. It was no longer the computer room, it was a storage room.

“Where is X?” X is found most of the time at the storage room.

And boy, we’ve gathered a lot of Xs. Because once you have space, the decision of keeping or getting rid of something, doesn’t even come up. When it does, the answer is usually “well, maybe someone will need it someday”. And we keep it. As we keep oodles of Xs and Ys.

There’s something magical about storage room: It may be limited, but seems to have infinite volume. There’s a lot of stuff in it, but I probably won’t be able to find any of it. With all the mess, things stacked on top of each other, papers to shred and/or sort out, cables of all types that I just may need one day, I know that if I need something it’s probably easier to buy,  rather than search for it.

In knowledge work, we usually keep stuff in virtual places. And there’s no limit to those.

For years I’ve worked with different bug reporting systems. Those things have infinite space. So it’s makes sense we should document every bug properly, because some day we’ll need the documentation for resolving it.

Vulcans Never Bluff

Not all bugs are created equal. The minor ones, the ones “we’ll fix if we have the time” usually don’t get fixed. There’s a reason they are minor bugs. But we put the same effort into documenting high risk and low risk bugs.

It gets even funnier.

We document the bugs, because we want to have all the data for the programmer to fix it, right? So what happens when a major bug occurs? We quickly call someone to see the bug happening before we document it, because we don’t want them to miss it happening live. So in the important case, we’re documenting after we’ve shown the problem, and in the regular case, we document something that may not be fixed.

But the bug doesn’t just go away. Every bug in the backlog is waiting to be upgraded to “work in progress”. But in order for the bugs to be approved, they need to be triaged. And if bugs don’t get over the hump the first time, they will be re-discussed and re-reviewed, usually by more than one person, and usually more than once. What a waste.

Fascinating

Here’s a strange premise: What would happen if your bug systems was a limited resource? If it could contain no more than, say, 30 bugs?

Let me make it even worse: What if the total space for features and bugs in your backlogs were a total of 30?

You’d really need to make a decision, to really forget a bug or a feature idea.

Prioritize.

As a product manager, I decided that there was too much information, ideas, bug reports and feature requests floating in different locations. So I limited the list. Some people were terrified.

“What will happen if we’ll need the information on that bug?” - If it’s a real issue it will come up again.

“But we won’t have a full picture!” - That’s a risk I’m willing to take, as long as I don’t have to re-read a bug description for the 15th time.

Today’s ability to store infinite pieces of information is in contrast to how our puny brains work. It needs small pieces of data to manage. It needs to focus, not disperse.

We don’t need more space, we need less.

Spock would agree.

PS: Now we’re looking for a new house, with rooms for the children, and an office. Oh, and maybe there’ll be a separate storage space too!

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