Expert On Everything

I’ve read an interesting article about how agile leaves security features off the hook.

Security features are usually counted as a non-functional requirements. Non-functional requirements have been a thorn in the side of developers for years. But as with everything, it’s goes a bit deeper.

Non-Functional requirements are hard to define. You can define uptime, but how do you make sure your design supports it? Or you want a secure product, but what does that really mean?

A couple of things happen here: The product manager usually does not know enough about non-functional features (they usually are business matter-experts, and these non-functional things are not core to the product). Sometimes, they don’t even know how define what they want, it just needs to be there.

In many of those cases, the one who does take the decision is the developer. This is usually a bad thing. In agile teams, the team makes the decision. This makes the product owner very happy, since the interpretation of what is secure or stable is now a team decision, rather than his own. People don’t like to make decisions, especially on stuff they don’t fully understand, and here the team stepped forward instead.

As a team, it feels better if everyone agrees that we should concentrate on building what we know, rather than on what we don’t. We can specify that later. That’s how the security features get dropped in priority.

Unfortunately feeling better doesn’t create a stable or a secure product.

Let me state this clearly:

If the product owner wants a secure product, he needs to understand security. If he wants uptime, he needs to have the tools to understand if the solution the team suggests is good enough. If he doesn’t, someone else will make it the decision for him. And by this, he exposes the product to all sorts of risks, from actual security breaches to legal risks.

Product owners set the priorities to what the team works on. If the team reduces the priority against their will, the product owners are not doing their job.

“I can’t be expert on everything!” You say.


But you need to be on everything in your product.

That’s what responsible product owners do.

Things Don’t Just Happen

The more I put time into product management, since, that’s my day job, you know, I’m more aware of user experience.

I’m talking about small features or behavior that if you ask any reasonable person, and by that I mean non-programmer, you’ll get a WTF look.

Kevlin Henney shows this kind of photo, and now that it has happened to me, I thought I’d share. Let me set the scene for you: Frankfurt airport, the departure flight screen (bottom-right) goes BSOD. You can actually tell from the error what’s going on, only you need to be a programmer to enjoy it. For the rest of the people it’s a waste of  a good screen. For the airport, it’s a waste of electricity.

The whole purpose of the error is to help the lucky recipient something to handle or report. Yet somewhere down the line, the end programmer forgot that the end user doesn’t hold the “How to handle BSOD” guide book for happy life. The sad thing is that the reporting part also doesn’t happen. What do most people do when with a BSOD? Restart. Regardless of the error. They can’t really read the error, it’s in an alien language.

Another example of experience gone bad. I was calling someone (who shall remain nameless) in a company (that shouldn’t but will). Here’s the voice mail message I got: “You have reached the voice mail system of company X. The person Y does not have an account in the system. Try calling later”.

Let’s see: how does it help someone who wants to reach Y. Part I: Confirmation - I got to the right company. Part II: Useless information. Part III: A very helpful message for someone who just arrived at the 21st century, but not for many others.

How do these things happen?

I can take the easy way out: A programmer decision, rather than a product manager. Developers communicate in Developish (both occurrences apply). So a programmer happened to find an edge case, needed to do some “error handling” and logged the error.

Usually that’s the case. I know at Typemock we’ve journeyed from error logging to helpful suggestions. We’re still getting better at it.

But the voicemail message wasn’t just a developer covering an edge case. Someone actually recorded the idiotic message. So there were a few people involved in approving and getting the message to me, and none of them asked a simple question: Is this helpful?

If you want to drill a bit more though, you’ll get  a sense that either no one was thinking about it, or didn’t think it was important enough to make a fuss about it. Keep your head down, do your job, and don’t rock the boat.

In either case, professionalism lowers its head, waiting for the business storm to pass.

That’s sad. If we’ve learned anything in the last few years is that we can create good quality products that customers like, through proper development practices and discipline. Agile has told us that in order to make that happen, you need to be at least vocal, if not a boat-rocker.

But products like that are mediocre. They don’t put the customer experience first, but rather “do their job”, and “report”.

Much like quality, product experience is part of everyone’s job. If you code a feature, you need to understand the customer. That means, for example, that “DISK_NOT_BOOTABLE” is not helpful for a normal person. We’ve past the age where a product manage defines everything and the programmers execute the plan. It doesn’t cut it.

And sometimes you are the customer (in the voicemail case). Is that the message you want to receive?

Then be vocal. Shout “this is the most stupid message I’ve ever heard, and I seem to find it as helpful as a SysRq button on my keyboard”. (Really, what do we need it for?)

It’s called Responsibility.

If you consider yourself professional, it should be part of you.

Expectation Maintenance

When software projects fail, we grow the divide between business and development.

Let’s analyze a bit, shall we?

Why is the divide growing? The divide is basically a metaphor for trust. Mostly, the two sides don’t trust, or sometimes understand, each other. Their goals don’t coincide, and  are not communicated correctly. Add to that some human nature, and we’ve got ourselves some fine mess.

Agile was supposed to be cure. By collaborating and showing results, it’s supposed to narrow the gap. Trust grows on each side, and everyone is happy.

Trust is gained from success. Does mistrust grow from failures?

Not exactly.

Mistrust comes from crushed expectations. The business people believed them what the developers told them about the delivery date. The developers believed the business people will not change the requirements, or would incur the needed cost. When that didn’t happen the expectations of both sides were crushed.

(by the way, don’t think that the same didn't happen when we had a successful project. Only then, we had the bitter taste of crushed expectations replaced by the sweet taste of a released project).

So we like success better. Big surprise.

Unfortunately even agile doesn’t promise success every time. And so, at some point, regardless which side you’re on, you’ll end up with some expectation shattered.

How do you narrow the divide after it’s grown?

The funny thing is, agile has that answer too.

Agile project success depends on discipline. Continue writing tests, even under pressure. Continue doing the stand ups, even if it’s known exactly what the plan is for today. Continue doing retrospectives, even if it’s not convenient to gather all the team together on one day on site.

That’s what we need to do: pick up all the fragments of expectations from the floor, then continue doing the same things that help us be successful the next time.

Because they will. And the divide will shrink.


This post may seem like it belongs in the self-help section. While this is true, remember that the writer is a cynical bastard, and if he writes this stuff, at least he believes it.


If you want to hear more from the cynical bastard, find him at the “Software Passion Summit” next week in Goteborg, Sweden talking about this stuff.

A Culture of YAGNI

My natural habitat is an agile software development company. I usually meet with people who are already agile, or aspiring to become agile. And then there are other times, where the “real world” hits me on the head, saying I should leave my little pond for a while, and see what’s really out there.

For the last few days I’ve been doing some very important work in a, let’s call it a government agency. People here do not develop software, but they are software users (and abusers, read on). Nice people, but they have been corrupted by a very strange force.

They don’t know what YAGNI (“You ain’t gonna need it”) is, but they practice it religiously. They put a lot of time, effort and energy (real energy – passion, anger) into working on stuff that isn’t used. They know it, yet they do it anyway.

What makes so many people work on waste? These are intelligent people, mind you, not simple drones.

People who tried to inject any agile methodology or practices and failed miserably know the answer: It’s that vague thing we can’t put our finger on called “organizational culture”.

This organization has top-down management, command and control style. The workers are managing a lot of information. A lot. This information is collected diligently over time.The collection of data, as well as filtering it up to management is the primary business goal of the organization. The organization understands there’s a data overload, so upper management requires data filtering.

But here’s the catch: Because no one is ever sure what the top man will actually ask for this time, they provide all the data, in different formats through different filters, so if there’s a question popping up, it is available in just a few clicks. And as you probably guess, no almost never looks at that information.

If we translate it to actual actions, the guys take the raw data from one system (a giant excel sheet), copy-paste to a PowerPoint slide-set, then hide/unhide stuff, copy that too, make sure the links are working correctly. In the activity I was part of, the data changed every few hours so the operation needed redoing over and over again. All this extra formatting work almost never gets viewed, because management is, rightly, looking for the most filtered data.

“Are they crazy?” you ask. “All you have to do, is just provide the filtered data, and if someone asks, and only then, hit the raw data and get some answers. That’s the logical thing to do”.

When culture and logic collide, logic rarely wins. People get used to the “crazy question of the day” and they adjust. They prepare to mitigate (which is usually a good thing), but in the process they spend too much time on the wrong work.

There’s a saying: “It’s better to ask forgiveness, than to ask permission”. I always say that if you’re a team leader, fighting the organization to get agile adoption, do the guerilla agile dance. Make the changes, hope that no one notices, and then show results.

But it’s not as easy as I make it sounds. Because culture is a very inclusive club. People within a culture accept people who fit the culture, growing the core group. When you’re fighting against the culture, it’s in all directions: upward with management, downward with your team and sideways with your peers. Some will help. Others won’t.

It’s not easy. In this organization, there’s no way of changing the culture in the apparent future. Waste will continue, because people feel safe in what they do, despite of the waste.

You might face the same problem in your organization. My advice still stand: Find allies, work to show results, get promoted and recruit and train the people who will help make the sweep.

If all that fails, because of the culture, it may be a sign to look for another organization with a different culture.

Upcoming Events

It’s update time again. Here’s the plan for the next few months:

March 19-20: Software passion summit, in Goteborg, Sweden. I’ll be talking about the ultimate question in software: “When will it be done?”. I hope to provide some answers as well. This is a new conference, and by the looks of it, is going to be very special.


April 25-28: ACCU, in Oxford, England. This session is going to be a back to roots for me. I called it “From Crappy to Classy: Legacy Code Resuscitation”. Basically, it’s just taking some crappy C++ code, and through tests and refactoring, making it beautiful. And there’s no fun like C++ refactoring, everybody knows that!


In an undisclosed date in May, I’m going to be back in the Israeli .Net User Group (which has also been resuscitated), talking about unit testing. Formal name: A new hope.

And who knows what will happen in June?

Stay tuned.

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