1 of 15

Screw perfect

AIM FOR GOOD ENOUGH

A brief story of how to face complexity and not go nuts

by Małgorzata Janeczek

2 of 15

Meet Johnny

DDD

TDD

Clean architecture

Best practices

Scaleability

E2E responsibility

DevOps

DevSecOps

DevSecFinOps

3 of 15

Meet Johnny

4 of 15

Hello, I’m Gosia

Full-Stack .NET / React Developer at Sector Alarm

Co-author of DevOps-journey blog devopsifyme.com

5 of 15

XD

6 of 15

Now going back to our Johhny

What he might’ve forgotten or not know about? 🤷🏼‍♀️

7 of 15

Clean right to left�(Kanban board in action)

Release what you can (if you can).
Released, but doesn’t meet a definition of done? Fix it.
Help out with testing.
Finish what you already started.
Limit your work in progress.

Let’s circle back to Johnny and take his work problems one-by-one. Starting with priorities.

He’s board is full, we should clean this up, surly this will make PO happy at least a little bit.

Our example – missing documentation is required for marking task as done. Maybe you have something too?

Belive me or not, but being a tester is a difficult thing to do. They might be overloaded with work as well. Offer help, that will for sure speed the process up.

This one sounds obvious, but not always is so. In companies it happens, that you might have dependencies between teams, if there is nothing you can do, well life,

but maybe you can jump in to another team’s code and try to resolve the dependency? Look for chances, don’t shut yourself in your own box.

Comfort zone is nice and comfy, but what’s outside for sure will help you grow too (although growth is probably the last thing our poor Johhny is thinking of right now).

Priorities have changed? Happens, move it back to “todo” column and forget about it for time being – those who decide for sure know what they are doing, right?

Your cognitive load is restricted, do not take too much on your shoulders at the same time context switching is expensive. Once you start doing that you’ll never finish anything.

8 of 15

KISS principle

Find the most effective solution
Keep simplicity in mind

Moving on to the codebase

And no, it's not about kissing your bosses ass�Another stating the obvious, made up by the Americans, so it has to work, right?!

The more complexity you add to anything, the more there is later on to maintain.

Look for simpliest solutions

In code it starts from simple things: variable names are understandable, remove comments when not needed, avoid global states, and redundancy.

Or do you really need DDD, all of it? It’s a great approach that helps aligh your codea base with the business, but it’s also known for adding complexity, especially in small microservices, but do you need microservices at your scale? ;)

For DEvOps, maybe a multicloud – 2022 was a year of acceleration of. Multicloud and over 82% of $1 bilion dollar revenue enterprises implemented multicloud (according to Strata). Maybe if you don’t work for this hudge organization you simply don’t need a multi-cloud, maybe you don’t even need cloud at all? Yyy, I said that.

In design it can be anything from avoiding too many fancy-blinking like a christmas tree in NY icons and pop-ups, with too much of these every user will be a Grinch.

I’m sure you get my point, the list can go on and on.

9 of 15

Think big, act small

Keep big picture in mind, create a vision.
Aim for evolution.
Solve problem with baby steps.
Divide task into smaller pieces, WRITE IT DOWN and keep it transparent.

This is my personal deal-breaker

So what can Johhny do if he has a completely new system to design? Should he jump right away into the implementation? Put it in the cloud with top-notch security all that is available and later think of what we actually need?

Miss Rachel “Stop, breath slowly” don’t jump anywhere, Johnny!

If you have a hudge task assigned to you – kepp a big picture always in mind it adds value

but take baby steps to implement it.

Break it down into smaller pieces AND WRITE THEM DOWN, make an actual Todo list!!! Keep it transparent Johnny, your Pos and manager(s) will appreciate that.

// Short story of new services – for construction company (chaotic, all over the place) vs. now at work structurised, calm, less cognitive load, as I don't have a thread going on at all time, focuse at one thing at the time.

Deliver working software often, frequently – Minimal Value product. Do you need the scale right-away?

10 of 15

Just in time (architecture), just enough

One of the Lean Architecture principals
Relates to the “Think big”

I canot not say a few words about architecture, when poor Johnny has entire system to create.

Here we are touching a bit lean principles and the 3 C’s – connection, cohesion and changeability.

Make a decision with just enough knowledge to grasp the essence of the issue. it can be a smarter choice.

Focus on what makes sense at the certain point of time. If this knowledge is not available atm – postponing

Here again, we can mention DDD. We might want to have an EventStorming session to understand a business problem, but we don’t have to implement the entire DDD pattern into your codebase.

Scale is complexity. Do we need it now, or can we start and release something small and working sooner, and then gradually evolve and scale up together with growing needs if there are any?

Be open with your business partners (5 milion users in 5 years example, maybe better start sooner for smaller scale and then adjust)

In a way we are all architects, but on a very different levels ☺

11 of 15

Better is the enemy of good

“It’s not good enough, I can do this better”
Easy to read, understand and maintain by ANYONE
Maybe good is “good enough”?

12 of 15

Now let’s sup it all up

Keep your board nice and clean
Keep it simple stupid
Think big, act small
Just enough
Good is ok
Ask for help

13 of 15

If you are experiencing chronic stress, anxiety or depression symptoms, please contact your doctor

14 of 15

Special contributes for amazing icon creators, since I’m not skilled enough to do them on my own ❤️

https://www.flaticon.com free-icons
Most of the icons I used were created by / are licensed by Freepik, but some special thanks go to: Muhammad_Usman, and Smash icons

15 of 15

Thank you!