DEV Community

Cover image for How has your relationship with complexity changed over time?
Ben Halpern
Ben Halpern

Posted on

How has your relationship with complexity changed over time?

How do you deal with, avoid, or accept complexity — differently than you might have earlier in your career?

Discussion (32)

Collapse
valeriavg profile image
Valeria

I rarely write in Python, but I follow Python zen:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.

Before that I felt inadequate for writing very simple code in comparison to sophisticated solutions I've seen around.

Turns out the simpler it is - the better🤦‍♀️

Collapse
nhatnguyentim profile image
Hoang Nhat

Thanks for sharing. 👍🏻

And this one got me thinking hard. 🤔
“ Complex is better than complicated.”

Collapse
jamesdengel profile image
James dengel

Think of it this way, you'd describe the relationship you have with your mother in law as complicated, and the reasons are subtle and different and they are all interrelated. And it really helps if you know all the back story.

However you'd describe the way in which aluminium is mined and purified as a complex process. But it can be broken down into steps, each step does not require knowledge of the step before it.

Thread Thread
barthazeleger profile image
Bart

This metaphore is insanely accurate.

Collapse
ziker22 profile image
Zikitel22 • Edited on

You cant avoid complexity as it is dictated by product requirements.
But as you gain knowledge and experience your start to get better in breaking complex scenarios into smaller chunks that you already either

  • know
  • seen
  • read about
  • heard about

and thus the problem as a wholeis easier to grasp.

Collapse
sergix profile image
Peyton McGinnis

(begin rant)

With web development, it's easy to spend so much time searching for the perfect tool that promises to relieve whatever complexity you might encounter with your project. However, that complexity has to exist somewhere, and any new tool you decide to pick up has the complement of additional mental overhead in learning that tool and relearning that tool when you return to it after a while, which isn't uncommon in large projects.

From being a CS major this past year, I've had to readjust my thinking to accommodate different language types. I had a class in assembly this past semester and it really showed the importance of knowing the extent of a system, but how to manage complexity efficiently in any environment, even at such low levels of the software stack.

The problem with modern Web Development and complexity (at this point I feel like I should make this an entire post lol) is that you have to deal with 3-4 different languages in harmony and modern web development encourages strong interop between them (e.g. css-in-js, TailwindCSS) while also preaching "separation of concerns". This leads to confused and convoluted environments, great disparity between codebases that are difficult to maintain and engineers are terrified to run npm update, and tools that you find that you have to ask yourself why it even exists since it covers such a specific edge case.

Every modern web development tool is trying to solve the same problem and no one is satisfied with settling on a solution to manage complexity. That's why we're now seeing so much of "just use vanilla HTML/JS/CSS, it works great", but then you ignore the reason that ReactJS/Vue/Angular were invented in the first place: to consolidate complexity. Web development is a delicate balancing act that requires sacrifice in actually solving some of your complexity instead of expecting a tool or library to.

Collapse
raddevus profile image
raddevus • Edited on

I have found that developers often end up creating complicated solutions (complicated code) when the problem is actually not complex at all.
This results in having this complicated thing you have to deal with (technical debt) that is a layer over the top of what is actually a simple(r) problem.

This is why I try to think, "how can I reduce the amount of code and still design the correct solution &/or fix this problem?"
complicated definition

Collapse
bradtaniguchi profile image
Brad

I've become incredibly paranoid about potential complexity.

Earlier I thought it was bad design/coding/development practices.

Now I've realized most complexity can be solved by determine what the problem actually is, rather than dealing with complexity in the solution. IE most problems aren't actually complex. Identifying them correctly can remove large vast quantities of complexity in any solution you create.

There are some issues that are just plain complex, but most aren't.

Collapse
lepinekong profile image
lepinekong

Seems you discovered the difference between doing the things right and doing the right things youtube.com/watch?v=OqEeIG8aPPk ;)

Collapse
gnomearcy profile image
Tomislav

@lepinekong
Thank you for the gold nugget of a video ;)

Collapse
history_dev profile image
History Dev

There are two levels of complexity I've slowly come to terms with. The first is code complexity which you can handle by analysing cyclomatic, N-Path and CRAP scores.

The second is behavioural and project complexity. This is more difficult to handle as it's more theoretical and there is no definitive answer. To deal with it you need to be flexible, adaptable and humble. I'd also advise learning more about complexity theory.

A good place to start is Melanie Mitchell's book, Complexity: A Guided Tour. goodreads.com/book/show/5597902-co...

Collapse
youpiwaza profile image
max

When I was younger, I tended to avoid complexity, or always tried to go on it with some support (either colleague or internet).

But now with some more experience, I'll always deal it the same way with ~3steps :

  1. Always have a clear vision of what your are doing : always prepare, don't write a single line of code before having complete comments describing what you are doing.
  2. A complex thing is always the sum of multiples simple things. Just cut the big log in small pieces and it will be fine
  3. Refactoring. Again, before coding, try to spot any design pattern that could improve and simplify your algorithm.

I recommand having a look at "refactoring guru", the website with the badger mascot, as it explains a lot of it, with detailed examples both theoric and with code.


Some more advices :

  • If you find yourself in trouble, go try the MVC design pattern, and try to define wich part of your code goes where
  • If you are in trouble with the algorithm, make a flowchart, or several, until all cases are noted. It really helps making patterns pop to the eye
  • Try to regroup stuff by entities. All the client stuff goes in "Client", all the navigation stuff goes in "Navigation", and so on. It can help to create Classes, if you yo the Object way. Also if it's an info, it will be a property (you just store something). If it does something, or transform something, it's a method. As simple as that.
  • Naming is reaaaally important.

Maybe the best advice I can give is that it will never be flawless the first time, and don't try to make 10+ classes for a start.

Most of the time I do a big old "index.php" or "script.js", code on the fly, and when things are finally starting running flawlessly, and your file is 500+ lines : it's a hint that it is time to split your code into multiple folders/files.

Got client stuff ? Create a "Client" classe.

Need to create a new client ? Create "Client->create( )" method

Client needs name and email ? Update your class : name & email properties. "Client->create(name, email)"

And so on.

Once you feel good and confortable about this, to get to the next level go check Unit Testing, and after that TDD > Test Driven Development.

It will help you thinking about your code as input/outputs and stuff, and can really improve code reliability, maintenance, avoid regression, and also make your code really faster.


Sorry for the big block and the approximate english.
Feel free to ask questions if you have some ;)

Have a nice day

Collapse
raphael_jambalos profile image
Raphael Jambalos

I used to think that I can do anything given time. That any complexity can be unravelled if I was just given enough time to sit it out in the corner and think/hack away at the problem. I used to get all excited about the solution and jump at it.

Now, my perspective is more nuanced than that. Some problems maybe beyond reach for my skill level (and experience) no matter how long I hack away at it. Sometimes its as much a "people problem" than a code problem. Overcoming complexity isn't as simple as hacking away at it. It requires us to really think it first and break apart the problem. Consider multiple solutions and what tradeoff it makes against the many facets of the problem.

I can say that I'm no longer as excited in jumping to the solution immediately.

Collapse
philoserf profile image
Mår Ekkertsen • Edited on

I used to be tolerant of complexity. When I was younger, I even thought complexity indicated something was clever. I have since learned how easy it is to create a complex thing and how hard they are for others to learn or to use. I now have come to appreciate simplicity. And, when I can, I create the most straightforward solution first, then add to it, refactoring out complexity as it, inevitably, accumulates.

Collapse
zurcher profile image
zurche

Learning and work experience has helped a lot to cope with complexity in various different ways. I'd say though sometimes It's unavoidable but as a rule of thumb If it can be made simple, then simple it is. My latest recipe is something like:

  1. Put time to do a proper POC ahead of working on the actual thing (which most times turns to be the root of the initial work anyway) Anxiety--
  2. Keep the expectations of stakeholders in line and as updated as possible. Which leads to be able to focus more on the task and having less pressure to meet an unrealistic deadline. Pressure--
  3. Divide the task in as many parts/deliverables as possible. Visibility++

On top of all of this with time I learned that no matter how complex it seems at first It always ends up being doable, managing that initial anxiety is very useful.

Collapse
lexlohr profile image
Alex Lohr

Complexity can always be increased, but reducing it is not always possible.

In most cases, you'll find ways to reduce complexity by understanding the issue to solve and the underlying system (APIs, formats, protocols, encodings) so you can reduce the complexity of the tasks required by the solution.

Collapse
davidmontoyago profile image
David Montoya

I've learned to manage it. I do so by using abstractions and "Bounded Contexts" that closely represent the business domain. If a certain abstraction is too complex to maintain, "grok" or reason about, I "encapsulate it" and defer all its complexity to a consumable contract. This often applies to classes, modules, libraries as well as feature teams! I wish I'd had learned this "domain-focused" approach much earlier in my career. It would have made me more effective at maintaining codebases and designing larger systems.

Collapse
mfurmaniuk profile image
Michael

I have personally become more complex as I age, my code less so.
Turning to have Code as documentation has allowed me to not only simplify it, but make methods and steps easier to understand with good naming.

Collapse
yawaramin profile image
Yawar Amin

I see complexity arise when people try to fit square pegs in round holes, use tools for purposes they were not intended for and for which they are mismatched. I think complexity can be reduced by 'going with the grain' of tools we use rather than against. Have written more thoughts here: dev.to/yawaramin/reducing-system-c...

Collapse
arbaoui_mehdi profile image
Arbaoui Mehdi • Edited on

My background was linear and procedural, which means I used to think of a problem as a set of steps that needed to be executed in order. Through the years, I found out that many approaches are better than a linear one.

In fact, one of the most basic ways to split a problem into smaller ones is called decomposition. If I'm solving a problem and getting stuck on some aspect, I can isolate that part and focus on it first.

With age and experience, I switched from a linear thinker to a systematic thinker, which triggers envisioning projects as a couple of interconnected elements that must be split first and then combined to fit an entire system.

I developed a process where I try to understand the problem first, isolate it as small as I can, think on a piece of paper on how to solve the problem outside the tool, then move into code.

I can summarize the process to:
1️⃣ Define the problem by isolating it as small as possible.
2️⃣ Think on paper of a simple solution (non-coding).
3️⃣ Code the solution.
4️⃣ Test the code.
5️⃣ Get feedback from peers and use it to improve the code.
6️⃣ Repeat steps 3-5 until satisfied with the result.

Collapse
jaakidup profile image
Jaaki • Edited on

I've always strived for simplicity, as it is beautiful to look at and to work with. And it works.

I find that inexperienced developers often overcomplicate simple things. I've made peace with that as everyone needs to learn sometime. It is frustrating though to look at a project, codebase or architecture that is 10x times more bloated and convoluted than it should be.

Collapse
lepinekong profile image
lepinekong • Edited on

Actually it hasn't changed much it just reenforced the theory I had already because of my SystemsThinking background (I've been coached by a close friend of Deming the guy who helped Japan Industry become number I after WWII) youtube.com/watch?v=OqEeIG8aPPk ie Complexity is kind of fractal concept you could unify. In Science it is even quantifiable as degree of freedom which I refer below as "intrinseque complexity".

I've been always attracted to complex Systems originally I almost embrace a career of Astrophysicist but I had to go to Canada too cold for me :) Then I was half professional in Stockmarket (being analyst for pro traders in a big bank) in parallel to Software Enginer - which is kind of amazement because I had created a unique model that is based on a non linear equation which is extremely rare as the huge majority of models are stochastics so I'm one of the rare person who knows some truth about how it really works. And of course also Software which is rather simple compared to the other twos because the intrinseque complexity are augmented by artificial over complications which are partly social organisation, partly technical, partly accidental, partly commercial so it's kind of folkore, people who pretend to be "software architect" for example are almost laughed at compared to architect in traditional sense, Alan Kay himself think the field lacks rigor, but that's I find actually even more attractive as it creates opportunity to improve the field more than in another field. In the future this won't be possible anymore because probably it will be completely industrialised and commoditized by the Cloud Giants.

Collapse
booboboston profile image
Bobo Brussels

When I was brand new to programming I was kind of proud of complex systems in a way that is perturbing in hindsight. I am accepting of complexity, but certainly not proud of it.

Collapse
cerchie profile image
Lucia Cerchie

So... what do you mean by complexity? Dependencies, tactics vs strategy, technical debt all jump to mind.

Collapse
lepinekong profile image
lepinekong • Edited on

In Science as I said there is the concept of degree of freedom. But that is about the object, whereas in Software what is really complex is the process which also involves social organisation like in a big corp which will over-complicate your job rather than facilitate it ;) Defining the right problem is often more complex than finding the solution once you have understood the first.

Collapse
highcenburg profile image
Vicente Reyes

Will never forget this from one of the authors here at dev:

Collapse
mellen profile image
Matt Ellen

It's...

Complicated.

Collapse
mcsee profile image
Maxi Contieri

Complexity is always accidental.
We need to avoid it all the time.

Forget about code complexity and software complexity. they are a myth

Collapse
kspeakman profile image
Kasey Speakman

Complexity is reserved for business logic. Complication is acceptable for technical concerns.

Collapse
pandademic profile image
Pandademic

Now I'm fine with complexity - I try to understand it and try and do complex things,
Earlier I would have freaked out and stayed anything that was the slightest bit complex to me.

Collapse
dwoodwardgb profile image
David Woodward

As long as the unit tests are readable, I give up caring about the code readability

Collapse
goodfellowmunro profile image
John Munro

Code is simple, people are what's complicated.

Get the reason and workflow from the person takes the time and effort. Then the code is simple to implement.