Lajos Moczar: Why I’m screaming about Agile

 

Agile has many fans. Lajos Moczar is not one of them.

As we saw in Part 1 of our two-part email interview, the Ireland-based consultant, author and veteran of all things information technology has previously called agile a “fad methodology.”

 

“Until we have given people a better way to think that results in better products and fewer bugs, I don’t think we’ve achieved much,” he said.

In the last part of our interview, Moczar discusses his approach to testing, as well as his surprising views on DevOps. We started by going back to a statement he made in a June 2013 article in CIO about agile.

You said in the CIO piece that defects tend to pile up in an agile environment. If so, what sort of development philosophy will lead to the best results from a testing perspective, and why?

Lajos Moczar: I tend to insist on two things in my projects.

First, I push product owners to get real about what they want. Unlike agile proponents, I don’t just accept that you can start a project without knowing what you want. That’s just allowing bad practices and crappy thinking.

Sometimes there are exceptions to this, obviously, like in bleeding edge or exploratory work. But that should not be accepted as the norm.

I’ve had huge success in working ahead of time with product owners, customers, business, operations and the like to reduce the “unknown unknowns” as much as possible. In turn, that gives me more stability, both in project planning and architectural designs and frameworks.

Second, I insist on a methodology in which everyone understands how to effectively test software. To help get a new project kicked off right, much of the first couple of weeks is spent by the team as a whole in setting up a solid test-centric development framework and associated testing environments.

Another thing I’ve started to do lately is to include the cost of retesting when I cost changes. People don’t think about this, but when specifications change, sometimes the greatest impact is to the test cases or the harnesses. Defects are more likely to take up permanent residence in the backlog if some structural change is required to the test code.

People don’t like having to rethink these things once they set them up. Assessing the testing impact of change and costing it so the product owners are aware of it is an art form in itself.

What testing philosophy do you favor — such as context-driven testing or heuristic test strategy — and why?

That’s a huge area to get into.

I think some of the modern testing methodologies have gone crazy, like test-driven development. One thing I can say is that I take a tiered approach to testing. That is, I create different levels of test criteria based on input from different people.

A product owner, for example, knows what he or she wants to see in the product and can offer some valuable insight that helps me define the testing context. Customers are also a great source of information like this too, as they will often tell you specifically about things that break in competitors’ software or previous versions.

Operations can provides an operational context. The point is, without context like this, you can easily lose the testing plot.

When it comes to developers, they operate at the narrowest level, meaning in terms of specific code functions. I like my developers to design code and tests as a single unit of work. My philosophy is that if you really know what you are doing in your code, then you know how to test it; conversely, if you can’t do the latter, maybe you shouldn’t be a developer.

What role should automation have in the testing process? Should it account for most testing on a piece of software, or should humans have a large role in deciding whether the software passes muster?

That’s a very good question. The answer is twofold.

To start with, I absolutely believe in automating as much as possible. Part of my approach is to have like-for-like-for-like environments between development, testing, production and the like. Transition between any environments is a “gate” that has rigorous test criteria and this is handled by automated and comprehensive test suites.

The catch, though, is this: Automated tests are as good as the people who write them. So how do you do quality control on automated tests? That is the human role, and I would say that the requirement for more competence is way, way higher now than it ever used to be. If we are going to trust automated tests, we must trust their authors all the more.

What is your view of the merits of DevOps? 

Long before the term was coined, I had a fundamental principle of design: I didn’t want anyone up at 2 a.m. on a Sunday fixing something my team wrote. That meant we had to design the system to be as fault-tolerant and yet easy to manage as possible. The idea of high availability has never been an option to me — it is a fundamental part of good design.

That’s why I like DevOps. I totally agree that operational people should be part of the lifecycle. In my early days I did a lot of system administration work, so over the years I find myself having casual conversations with operations people in various organizations.

It’s amazing how many interesting things I’ve learned about the software they manage – things the software authors would be ashamed to hear. That valuable perspective has been lost for a long time, and I’m glad that people recognize this.