# Is there a metric that can be equated to complexity in laymens terms? [closed]

Often times users cannot comprehend the complexity of software. They think that because a problem is easy to describe then it is easy to solve. I want to equate the complexity of a "simple program" I have built with the complexity of a process with a tangible result.

Is there a system that can take tangible processes and assign them a complexity such as:

Building an outhouse = 5
Building a house = 50
Building the empire state building = 5000

that I can then equate to the software in a meaningful way:

thisProject = 5

Maybe the project weight is determined by Cylcomatic Complexity. Whatever it is is not that important. What is important is that such a system exists. Does such a system exist?

Update

I'm looking for a means to compare the complexity of two complete systems. I am not looking for estimation methods. The limitation I see in using "money and man hours" is that the laymen (or maybe even somewhat technical) individual could attribute the reason the project took so long and cost so much money is because the developer(s) were simply not good at their jobs.

Thinking out a possibility...

I imagine a solution to this problem could be similar to Dijkstra's algorithm. Create a flowchart for System1 and another for System2. Give each decision a weight based on how many routes the decision contains. Give each action a weight as well. The cumulative weight of each respective chart can then be used to compare the two processes.

1. For the "tangible process": If some engineer mapped a flowchart for "building an outhouse" then we could use such an algorithm to obtain a "total weight" for the process.

2. For the "intangible process": Assuming the entire program can be mapped to a Finite State Machine then it can be described as a flowchart and assigned a weight as well.

So the outhouse process is weighted at 50 and "my program" is weighted at 60. So it's about as complex as building an outhouse.

## closed as too broad by gnat, jwenting, user40980, Dynamic, amonMay 8 '14 at 14:16

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• tl;dr; version: No. full version: Many people tried. No one succeeded. – Euphoric May 5 '14 at 17:22
• Yes, it's called money. – JeffO May 5 '14 at 18:53
• limitation... "money and man hours" .. developer not good at their jobs.... - outside of software engineering many very complex projects (Think Pyrimids in Egypt to Apollo program for starter) have solved this problem. Why 5000 years later are we still trying to solve it in software? Perhaps this is the problem. - OH - by definition 50% of developers are below average so no good at there jobs - yet we insist on doing everything like that are all in the top 10 percentile - and we think we are smart. – mattnz May 6 '14 at 2:43
• FWIW, Cyclomatic Complexity works well. Especially placed into a chart. In practice I have found that if you place projects side by side in order of complexity then the programmers sentiments regarding the difficulty of the project is in line with the chart. – P.Brian.Mackey Sep 29 '14 at 16:43

Most programming projects contemplated by a single person or small team are not characterised by their complexity, they are better characterised simply by their size.

To estimate something by its size:

• find a typical "unit"
• estimate the time taken to build one "unit" as T
• count the number of "units" as N
• multiply N x T
• if there are multiple kinds of units, repeat for each and add together
• add on some fudge factors for integration, complexity, overruns, rework, etc.

A basic small business system might have 20 forms, 30 database tables, 10 reports, 2 connections to other systems. The final result might be 10,000 lines of code. It might take 200 pages of documentation. Any of these can be used as "units".

Show the customer the list of "units", the count and estimate for each and the total. Then compare it to a big house or a small apartment block with similar numbers of "units".

Size matters more than complexity, but it's still much harder to write a compiler or a framework library than a basic business system and the "units" are much harder to identify.

The closest approximation is time. If a system is small but takes a lot of time, that is typically due to its complexity. However, this is a very difficult metric to capture.

What I have found helpful is to estimate the project. Break that estimate down into pieces. The idea is to break it down into the smallest pieces that make sense, which are normally stories in the Agile methodology.

Nobody can really comprehend that a system requires 5,000 hours of work to complete. That is too big of a number. But break that down into individual stories and each one is easier to digest. If a story is complex and requires more time, that will be easier to explain at the story level than at e.g. the epic or system level.

It is one thing to say that a skyscraper is a complex building: I think we as laymen can agree to that fact, but it is difficult to explain why. It is more meaningful to say that a subcomponent is complex. For example, the electrical system is complex because there will be 5,000 separate offices in the building that are metered individually. The sewage system is complex because there will be 400 restrooms in a vertical building that have to be vented properly.

When you decompose a large problem into small ones, it becomes easier to attach estimates to them as well as to explain why a component is complex.

So no, there is no silver bullet number you can use to gauge complexity. However, you can decompose a problem into smaller, easier to understand pieces and explain those.

• This is a good answer for estimation. However, I'm actually looking for a means to measure a finished product against another finished product. – P.Brian.Mackey May 6 '14 at 2:02
• @P.Brian.Mackey: Man-hours (or money) spent. Done. Assuming both projects were made by the same team, somewhat accurate. – Brian May 6 '14 at 2:22
• @Brian - You may be right. I updated my answer. – P.Brian.Mackey May 6 '14 at 2:30
• I was discussing estimation as a way to compare systems that are not implemented, but I still think it is a valid answer. One can examine a project after the fact and use actual hours which is even better than an estimate. I also stand by my words that "the closest approximation is time" as well as "when you decompose a large problem into small ones, it becomes easier to attach estimates to them as well as to explain why a component is complex." Maybe that could be reworded in the context of this being a finished system, but the idea is the same. – user22815 May 6 '14 at 14:25

Not really.

So far, EVERY software complexity metric that has been proposed has been shown, on real data from real projects, to be strongly to very strongly correlated with raw SLOC: raw number of source lines of code. McCabe's Cyclomatic Complexity turns out to be noteworthy in its guilt on this, with all of Halstead's metrics running close on its heels.

You could make a fancy metric, and say programs with a McWizzBang value of 42 are more complex (or complicated) than programs with McWizzBang = 7, but you're really just saying that a program with a million lines of code is more complex than a program with a thousand lines of code. Well, DUHHHH!

Incidentally, although you weren't asking about it, the same is true for software cost estimation. No matter what you try to estimate, to get to your cost estimate, it turns out that you can get the same bang for a lot less buck by estimating raw SLOC.