The Software Project Complexity Meter

After quite a few years working on different projects at different organisations and at times feeling that some projects are horribly complex and others easy to work on, I started researching the aspects of a project that make life as a web developer easier or harder. Especially after the two (in my mind) most complex projects completely failed, despite the enormous amounts of time and effort that were spent on them.

In the list there's a bunch of aspects that get a T-shirt size and a weight. Choose the size, add them up and normalise the result to give a value of 0 (least complex) to 10 (most complex). Perhaps it'd be nicer to work with inverse, i.e. simplicity meter but complexity is a bit easier to talk about.

The call on whether a particular aspect is S, M or L is of course your (or your team's) call. The scope can be just you and your work, or your team, or the whole project. It's about what affects your results.

Some aspects are more important than others, so there is a weight. This too is a judgement call. Some things are easier to fix or deal with that others. And some things are much more expensive to refactor than other things.

This is my list. The weighted aspects first.

Number of technologies involved (weight: 2)

How large is your technology stack? We have the basics (languages, databases, platforms, hosting, etc) and to use them there are numerous toolkits. How many toolkits, frameworks, languages, extra libraries, data layers, platforms, testing solutions, build and deploy pipelines are in use? How varied are they? How many layers of the technology stack are there? Whether this is judged as S, M or L depends of course of the amount of experience available. As a rule of thumb I like to think "1 toolkit for each job" is an S. Multiple data sources, multiple hosting solutions, varied testing solutions, etc all add to the complexity. A tech stack with a number of layers in double digits has inherent complexity.

Number of components to the solution you're building (weight: 2)

Your tech stack will be used to build a solution. How complex is that solution - are there multiple and varied websites, portals and apps? Are the use-cases so varied you are delivering multiple products?

Different products are exactly that usually for good reasons. They may share a similar tech stack but they will have varied requirements for usability, design, data availability, testing, system performance, etc. The different requirements are a root cause of project complexity and can be a source of confusion. If you ever find yourself wondering "which repo am I working in?" then there is probably some complexity there.

Bad communication by key staff (weight: 2)

For any project there are key staff members: the project manager, the tech lead, the business analyst, etc. In projects where these key members are not approachable, where the communication breaks down or information isn't effectively passed on the complexity just surges. Dev's are perhaps not known for their interpersonal skills but they do want to do a good job and are focussed on building a solution. If the direction the dev's have to take isn't made clear or their questions aren't answered, they probably will carry on and end up building the wrong thing. Fixing that is hard.

If the communication is super good, the complexity is S. If the communication is lousy, the complexity is L.

Number of new technologies in the tech stack (weight: 1)

How many new (for your team) or emerging technologies are in use in your tech stack? Every new technology, toolkit, framework, etc has a learning curve and some almost inevitable disappointment. Although dev's are generally adept at picking up new technologies and tools, the team still has to go through the learning curve and some mistakes will be made.

Almost nothing new in the tech stack, the complexity is S. Two or more new comers, the complexity increases.

Size of the team (weight: 1)

The larger the team, the more difficult to keep everyone aligned and informed. A large team offers more capacity of course, but also reduces the maximum effectivity per dev. As a guideline I use up to 3 persons in a team gives a complexity S and up to 6 is complexity M.

Complexity of the business (weight: 1)

How well does the team really understand the business? For an an average ecommerce platform the devs of course understand buying and paying. But how about the logistics, the analytics, marketing, promos, guarantees, etc. Or if the business has a less well known nature (bio, medical, aero, etc) can the dev make the right decisions based on data, how reliable will testing be?

Related to this: how clear is the vision of the end result? Is there a clear and accessible vision, does it change too often, do priorities keep shifting? Does the team get reliable answers, designs and architectural decisions?

Illogical process to building the solution (weight: 1)

Of course we never plan for an illogical build process - we all really want a logical way to put the solution together. We want to start with fundamentals, elegant architecture, design the components, design the data, get feedback early, etc. However, in practice things can change, and priorities don't always match up. For example, building a frontend if there is no real data available is asking for trouble. Is the team building the roof before the walls?

Next step

Next step is add up the sizes per aspect. I use this method:

• Number of technologies involved (weight: 2) S=0 M=1 L=2
• Number of components to the solution (weight: 2) S=0 M=1 L=2
• Bad communication by key staff (weight: 2) S=0 M=1 L=2
• Number of new technologies (weight: 1) S=0 M=1 L=2
• Size of the team (weight: 1) S=0 M=1 L=2
• Complexity of the business (weight: 1) S=0 M=1 L=2
• Illogical process to building the solution (weight: 1) S=0 M=1 L=2

Per aspect, take the value assigned to the S, M or L, multiply by the weight and add them up. That will give you a value from 0 to max 20. Halve that number to get the complexity score!

The two projects that went under, scored 8 and 9 on this scale. The projects where I felt the team was happy and in control score 6 or less.

How does your project or team score? Does this match how your team feels about the project?