A Method Is Not A Methodology

While the focus in IC development is generally dominated by technical challenges, teams are often overlooking the single most critical requirement for success: people.

Neil Johnson – Principal Consultant, XtremeEDA

More Than Technical Details

This is not a technical article. It does not propose any technical solutions nor does it propose technical advancement in our field. It does not it even identify or make reference to any particular technical challenges in IC development. There is nothing technical about it.

But we are engineers! We love technical challenges. We embrace technical challenges. In fact, that is likely the reason most of us became engineers in the first place. The challenge of making something new, something bigger, faster, stronger – even cheaper; that is why most of us are here.

And to be sure, there are huge technical challenges in IC development. One problem in the IC development community, however, is that some technical challenges tend to consume us, almost dangerously so, to the point where we ignore or dismiss the context of the challenge. To that end, the purpose of this article is to simply remind people that there is more to IC development than overcoming technical challenges.

To convey the point, I have chosen to launch a mild assault on a word that is becoming increasingly common in IC development. That word is methodology.

For functional verification engineers, methodologies became commonplace with the introduction of HVLs. There was the Reference Verification Methodology (RVM) and the e Reuse Methodology (eRM) to get things started. Those gave rise for a brief time to the Advanced Verification Methodology (AVM). Finally, and likely here to stay for a significant period of time, are the Verification Methodology Manual (VMM) and the Open Verification Methodology (OVM).

There are differences between them, but as a group their purpose is similar: to increase productivity by addressing various technical challenges found in functional verification. Being such a lofty goal, each is impressively tagged as a methodology.

I have accepted the use of the term methodology in this context. Each embody a tremendous amount of detail and expertise. They are very powerful and more than adequate as a basis for implementing advanced verification techniques. Methodology seemed like a perfect descriptor when you consider their breadth and highly integrated nature.

Recently though, I ran into a new definition of methodology that I was not expecting to find. In “Agile Development: The Cooperative Game” (Cockburn 2007), Alistair Cockburn describes a methodology as:

“everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.”

Obviously, this definition of methodology does not apply to the aspiring yet more conservative claims of VMM and OVM. This definition of methodology comes from the idea that a “methodology is a social construction” (Cockburn 2007) meaning that people play the most important roles and are crucial for success. A team cannot simply adopt a methodology to be successful. Nor will any one methodology succeed to the same degree with two different organizations. A methodology must to be forged and accepted by a team. It can obviously require tools and techniques to address technical challenge, but it is people that run the tools and apply the techniques thereby determining the outcome.

The context around all the technical challenges we face invariably involves people, plain and simple. That cannot be a surprise to any of us. We all know it – and likely complain about it from time to time – but we do little to address or improve it. We leave it to our managers to take responsibility for people – or project resources as we are commonly referred to. To get started, consider a few ideas that have been recognized in agile software.

Success Modes

Cockburn 2007 identifies a set of human success modes as they relate to software development. These success modes are what inexplicably motivate people to recognize key moments in a project and do whatever is needed to get done. They are:

  • Being good at looking around
  • Being able to learn
  • Being malleable
  • Taking pride in work
  • Taking pride in contributing
  • Being good citizens
  • Taking initiative

Pride in work is a great example of what can motivate a person to become successful. A person who is emotionally invested in their work and takes pride is what they deliver does a better job than a person who does not (Cockburn 2007). An IC development team, therefore, with a collective pride in what it is committed to deliver should have a much greater chance for success. This should serve as motivation for teams to encourage a pride in their work and a true connection to their accomplishments.

Sitting Together

A huge part of the agile software movement has been the acceptance of eXtreme Programming (XP) and the first practice in XP is sitting together (Beck 2004). The creators of XP recognized that the physical distance between people is often overlooked as a physical impediment to effective communication. While you may have two very happy individuals in cherished corner cubicles with windows on 2 sides, the view from the 23rd floor will not do much to foster teamwork if it means a 5 minute walk between them. Swiveling your chair around to confirm a design detail with a teammate that sits 10 feet away is far more effective.

Pair Programming

Also high on the list of XP practices is perhaps the defining characteristic of an XP team: pair programming (Beck 2004). Pair programming relies on the assumption that two people writing code together at a single terminal is more productive than both of them writing code separately. The word productive here is important to emphasize. Writing code faster may not be the case, but anyone can bash away on a keyboard. Writing code that is faster to production is what is important. So with two people analyzing syntax and design and implementation details simultaneously, a pair can write production ready code faster.


When it comes to VMM, OVM and others, let us continue to call these methodologies. While doing so, however, acknowledge the fact that people and team dynamics are integral parts of these methodologies even though it is not explicitly stated by their creators. Arguably, failure is just as likely as success when it comes to using these methods – yes methods – which suggests a predisposition to neither.

But rather than make an argument for a more correct use of the word, it is simply suggested that people reconsider their own definition of “methodology”. Accept the fact that people – not resources, actual people – play the largest role of all when it comes to a successful IC development. How do people fit into your new definition of methodology? What is the cost of ignoring that people form the core of any methodology? Can you buy, assume or impose a methodology?

Search beyond the boundaries of IC development for examples of how methodologies have been successfully applied. Agile software development is a great place to start with its many examples of how people and communication are so highly valued.

Regardless of whether your project is headed for success, failure or somewhere in between, don’t fool yourself into thinking it wasn’t people who were responsible for it!


A Giant, Baby Step Forward: Agile Techniques for Hardware Design, Neil Johnson, Bryan Morris, SNUG Boston, 2009.

Agile Software Development: The Cooperative Game (2nd edition), Alistair Cockburn,  Addison-Wesley, 2007.

Extreme Programming Explained: Embrace Change (2nd edition), Kent Beck, Addison-Wesley Professional, 2004.

OVM User Guide (Version 2.0.3), Cadence Design Systems, Inc., Mentor Graphics Corp., 2009.

Verification Methodology Manual for SystemVerilog, Janick Bergeron, Eduard Cerny, Alan Hunter, Andrew Nightingale, Springer, 2006.

© Copyright Neil Johnson – all rights reserved

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.