Complexity is also a Bug

Last month I attended the DevOps Days Tel Aviv conference, I took some notes about the interesting stuff people said – like many people do during a conference –  and then I put the notebook away – like most people usually do after a conference…

But yesterday I was going over my notebook, I guess I wanted to check what I still had to do from my endless to-do-lists, and I stumbled onto my notes from the conference.  Among all the scribbles and drawings there was a sentence that caught my eye, something I had written and then forgotten, but that when I saw it again managed to grab my attention.

What was written in this sentence was:

Complexity is also a Bug.

Complexity is a bugComplexity is increasing and will continue to increase

Below the sentence I wrote the notes that the speaker had said in his presentation.

He was a Founder/Programmer/Geek/CEO from The Valley, and he explained how from his point of view complexity in software and applications was increasing, and would continue to increase with time.

The point he was driving to was that, as development companies we have to make choices about who handles this complexity.  He looked at this from a DevOps perspective and so he said that there were 3 choices for who could “take on” this complexity:  Development, IT or the End Users.

To put it simply, applications need to do more: talk to more applications in order to do stuff, do this stuff faster, and do it in more diverse environments.  We are not really doing less of anything (unless you count less sleeping and relaxing).

Being this the case, someone needs to “pay the penalty” for doing more, and this penalty could be handled by any of the 3 teams I mentioned above.

It could be handled as part of the development process, by creating more complex algorithms and smarter code to handle all the complexity.

Parts of it could be passed on to the IT, who need to deploy and configure the system so that it could handle some of this added complexity.

And finally, all the stuff not handled by any of previous two teams would end up being passed to the End User, who would need to work with more complicated installations and configurations, and applications that were less friendly.

In the end, what he was explaining is that complexity is a Zero-Sum game, and as part of our development projects we need to decide who will be handling it.

Looking at complexity as a bug in the product

Complexity is not a feature, it is also not an objective attribute like load level or application response time, but it is not less important than any of the other attributes in our products, such as a nice GUI or a good UX.  Actually, complexity is usually handled via a combination of features and UX solutions.

Having said that, we need to handle excessive complexity as a bug in the products we are testing, but this may sometimes be trickier than you think.

  • First of all, complexity depends on the user.

Try to think about 2 different users:  for example your dad vs. yourself.  My father is a great surgeon, but he is pretty bad with iPhone apps.  This means that something that is trivial to me may be impossible for him to figure out.

On the other hand, if you compare me with some of the developers we have in PractiTest, then I become the guy who cannot get most of our configuration done straight.  In this second case, something that to them may be trivial for me is utterly complex.

  • Second of all, complexity is a trade-off.

I think we have all been in those projects where the Product Owner or Product Manager or even the End User comes and says:  “Guys, we need to release this!  It’s time to make compromises…”

Compromises are just another term being used for bugs and missing features.  These are the cases when the project is already delayed and we need to deliver something out, even if it is not perfect.  And in this cases, one of the first things to be “compromised” is complexity.

This is when we agree that we can release a document on how to configure the system manually instead of having the intelligent self configuration, or that the installation will ask many questions that could have been taken from the system directly.

These are not critical things, but depending on who the user is this may be a blocker for him/her to install the system.  Or in the best of cases only a nuance they would have preferred do not deal with.

  • Finally, it is very hard to handle complexity after the feature was developed.

Imagine you order a car to be custom made for you.  You talked about the color, the shape, the interiors, wheels, mirrors, etc…

Then, when they are showing you the finished car you realize that (1) you wanted this car to be driven in the UK where they ride on the Right Side of the road, also that (2) you wanted to save money by having it work with a Diesel engine, and finally that (3) you wanted an automatic car, and the one they are showing you works with a stick…

Oops!

Just as making these changes once the car is done will be very costly and it will definitely delay the time you get to drive your car…  So is the case with trying to reduce the complexity of the system once it has been done and it is close to being released.

It is true that by working AGILE and with Iterations these issues should be reduced, but they will not be eliminated.  And many times the issues won’t be discovered until the product actually reaches the end user, and so solving the complexity issues or adding new functionality to handle them becomes even more costly and may end up having additional marketing repercussions and costs.

Complexity is an issue that needs to be taken seriously into account

Complexity is a bugAs you may understand by now, complexity is not only here to stay but it will become more of an issue as our products need to do more and communicate with additional products and solutions in order to fulfill their objectives.

Complexity is also something that, if we don’t handle it as part of the product design and development, it will be passed to our end-users to handle – or they may choose not work with our solutions because they don’t want to or can’t handle the complexity we are relegating to them.

And finally, complexity is easier, faster and cheaper to handle early in the process than later on.

But most importantly, given that your users will see complexity as a flaw in your product, it is better that you start considering it as a bug that needs to be reported and eventually handled by your team.

,

  • Pingback: Complexity is also a Bug - Softwaretestingtools.com()

  • Pingback: Testing Bits – 1/8/17 – 1/14/17 | Testing Curator Blog()

  • I had a developer say something that stuck with me a few years back. We were talking specifically about the code being written. He argued that complexity isn’t the issue but whether it was complicated or not.

    Complex is used to refer to the level of components in a system. If a problem is complex, it means that it has many components. Complexity does not evoke difficulty.

    On the other hand, complicated refers to a high level of difficulty. If a problem is complicated, there might be or might not be many parts but it will certainly take a lot of hard work to solve.

    That being said I never thought about the 3 teams that would have to end up ‘paying the penalty’. These are some good thoughts to continue to chew on. Thanks for sharing.

  • I had never heard about the difference in definitions between complex and complicated, but it may be right (it sounds right anyways). Thanks for sharing this and I will make sure to sharpen my definitions 🙂

    In any case, I guess we can all agree that even if we call it complicated, after a product or system reaches a certain level of difficulty to work with it (liked this way of putting it – so I will use it from now on if you allow me) then we should start cataloguing it as an issue that needs to be solved!

  • sachin jadhav

    thank you for info

  • sachin jadhav

    Thank you for info. For more information on visit Nettech India Thane .Call us at 9870803004/5.

Shares