How do you deal with, avoid, or accept complexity — differently than you might have earlier in your career?
For further actions, you may consider blocking this person and/or reporting abuse
How do you deal with, avoid, or accept complexity — differently than you might have earlier in your career?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (31)
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.
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.
So... what do you mean by complexity? Dependencies, tactics vs strategy, technical debt all jump to mind.
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.
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
and thus the problem as a wholeis easier to grasp.
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.
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?"
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.
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.
I rarely write in Python, but I follow Python zen:
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🤦♀️
Thanks for sharing. 👍🏻
And this one got me thinking hard. 🤔
“ Complex is better than complicated.”
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.
This metaphore is insanely accurate.
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...