Obviously it has nothing to do with what i personally think, a financial bubble is not about selling tulips selling real estate selling gfx cards or selling a dream, it’s about finance actually not being able to loop it up, that is all it is about.
They can’t make money and wont make money out of it, not now not ever, therefore it’s a financial bubble.
The tech itself is not at fault here, i personally love machine vision (It’s all AI to you nowadays) what’s wrong with this are the valuations, like a sillicon valley 20 year old that wants to IPO with a 10B valuation with 3 people-team all of them co-founders they did exactly that, overpromised and somehow overfunded.
The finance bros couldn’t care less about starting to go all in on yet another bubble for probably political reasons along many others.
And.. here we are.. waiting for it to go out with a bang, or.. a miracle..

for now we just hype up between datacenters to build more steam, coincedentally the same steps that the dot com bubble took before bursting, it was never about the companies back then either although they sure leveraged up in FOMO, bubbles are just.. finance.
How many of them have sound margin to skip it through like Amazon is not yet clear, but only cash cows will survive, that’s the big ones that they already for some years now have started laying off people, because unjustified growth wont going to save them anymore.

Most outages in the global world we live in comes out of years of malpractices eventually to come to fruition as typical bugs, but dealing with technical debt is the most serious issue there is.

Patterns were always around since before Object Oriented programming as an example we can check a few examples given to me by God, Google, and StackOverflow, despite that, our needs evolve, and hence our code has to change too.
The latest craze with Microservices (Serverless, edge or not) gave us some good and some bad examples out of it, on their credit Amazon fixed a few of their mistakes with Amazon Prime Video, startups that claimed to need Microservices wasn’t so lucky and closed shop in tears.

But what is the solution if not to copy the greats? Fear not, for Pelorio Architecture project is here for you.
Technically i’m promoting it because i truly believe there’s no other way to stay sane in todays world if you don’t think things through instead of jumpting to Agile Chaos maneuvers which is what happens if you don’t take Fragile Manifesto seriously enough.

What it really is a Modular monolith Pattern in the making, and maybe along the line also a style guide, for small projects that will potentially be big enough to actually split them into difference services, but until then… until then you keep your hands out of microservices, you vile beast indie hacker with a one man company.

The only way to stay sane, is to stay humble with a monolith, but your code should be modular, for when the need arise for you to grow, then it will also become a technical debt to refactor, so… the only way to cheaply refactor this in the future, is never mess it up in the first place, with pelorio architecture, a modular monolith for the small projects.

When the discussion comes for actually splitting the monolith we should go back to the definition.

What is Microservices?
A microservices architecture is a way to build applications by developing them as a collection of services. This approach allows you to create, deploy, and manage each service and its architecture diagrams independently.

With this definition we understand that independence is the major benefit from using this, also a seperation of concerns should be an obvious benefit aswell, but that’s not a given if you don’t explicitly design it in your code and database aswell.
If you do it will create an expected technical overhead that only grows as long as your microservices grow, for that reason seperation should not be a small task and grow along with your team, for it will be their life-long burden.
I’d expect seperation to be a Technical but also a team building issue, for the needs of the system can be a task for many, 10 senior people can hold a company, but 9 cannot, for that reason splitting Microservices should be carefully considered while the needs and the company grows at the same time or seperately.

Pelorio Architecture is a work in progress, the idea is to keep it as neutral as possible from actual projects, but keep very generic modules that everyone need like Authorization, Logging, Cronjobs, Limiters, Analytics and so on.

The structure is based on the idea that the project is small, but in a few weeks notice, you might be able to split it and get it prepared for a service split, without significant overhead.

Do you have an opinion on this?
Let me know.

Whatever your answer might be, it's wrong.

By thinking in that particular way whichever your choice might be it will be knowingly a flawed choice, you can keep questioning and refactoring and probably avoid the Ouroboros effect in that respect.

By definition, there is no right or wrong choice, and there are literally millions of lines of code out there if not more, that just works, and nobody dares to question them unless they have to, but when the refactoring day comes, then you'll have to choose.

Multivariable Headaches

It comes down to 10 or 20 variables in total that you'll need to base your decision on. In the end, you will always be confident about your choice, and you'll make it look impressive, like a PowerPoint magician who no longer uses PowerPoint. (And if you still do, I apologize for your life choices.)

Taking those 20 variables in mind for one reason or another, we could safely start from a fact given to me by experience that you might not have all the necessary ones available, or your data quality (as the data people say today) is less than desirable, hence the usual iterations of feedback for that exact reason.
(not like it will solve it in the end, but it might)

Pennies on the dollar

So your budget is decent, you go directly for microservices and ofc you go serverless, you do go full cutting edge, a variable that your CFO will approve because if anything there might be a KPI about that one too, not part of your data, but his data that you might or might not have an idea about, you can also indeed verify that any other choice would use a bigger budget than the one you do use now because let's be honest, AWS is awesome and Google Cloud too, I like the Microsoft people too, they made Typescript.
So on paper, everything works, and a job well done, one small thing about it, there is another variable about scalability that you or someone else overlooked and because of macroeconomics that unfortunately you know nothing about, it became the next Metaverse project, because why on earth should an engineer know about low FED rates?

And as it seems, they don't.
Nevertheless, we have some new realities to deal with now, so what is the budget right now to fix this?
Not enough, and they will now require cost cuts that seem to be borderline paranoia, complete chaos and other Greek words that summarize your new reality, so now you'll try to go as open source as possible because it rocks, and it's free, and you don't have to reinvent the wheel on every corner or buy the wheel for $9.99 per hour, the problem right now is that because of some core decisions that you either chose or just followed the trend of the times refactoring will never be simple again, you've become a cog of the Ouroboros Architecture, maybe that will cause you to drop some features to cut server costs as Twitter did, maybe you'll have to drop the cloud on every level like ahrefs, at the end you will cut the costs while maintaining some form of the previous system and services to some degree.
The best thing would be to increase spending, exactly because you have to cut costs on the server level, but good luck convincing anyone after the previous decisions taken by you or someone else.

« Alors, c'est la guerre »

So what now?
What do you do after the Ouroboros is in full swing and it goes faster than the rpm in your hard drive?
Fast migration of the core product to the most inexpensive solution available, code freeze the rest, you're at war now.

Contrary to what many believe, even if you'd like to cut cloud costs to zero or your features, that might not be possible right away because the development costs are also significant in contrast to the commonality that Software is cheap.
(no it's not some people are just easy with words)
Therefore a realistic timeline has to be implemented in a starting analysis for the migration without the need to overpromise or prove anything to anyone, strict deadlines after all are an enemy of the total budget, and you'd better not do any revisions on it.
Also, the running system has to have a smooth transition because that's the core product of the company, which makes it quite important for everyone around you.

The real world kicks in.

Inflation will keep hitting cloud services like everything else and that is already happening, they were never cheap contrary to what many believed back in the day because some marketing or sales department convinced them that this was the case, hence the Ouroboros effect, the Cloud Decoupling will be the main thing to brag about in vision terms sooner rather than later, unless you do have the budget to take on market share while you do that too, in that case.. you're a rocket.
There is not a single crisis that remains a crisis for everyone, many lose but some will benefit, that's always the case, and it's not different this time.

We need a hero.

Sometimes the UX designers will not save that situation, sometimes they have to work with the engineering team on deeper more technical issues that maybe they've resolved during their experience in some other company and all you have to do is seek advice about it, sometimes you'll have to apply some solution in a custom manner and at some rare cases you'll have to build something from the ground up.

It is easy to implement, but is it better?

It is as common as the Sun that rises from the East and sets in the West that the web is full of odd functionality that in practical terms seems outdated but they do indeed work fine, on a technical level 10 dropdowns are simpler than a search implementation of multiple services that return multiple sets of data or files or both, one would say that it is a very common occurrence for a user to see multiple pages of data entry functions instead of a well-balanced search or a form wizard that can group a chaotic situation decently.

Adderall or a better design?

With a simple search for our average user we can identify that the average focus span is around 8 seconds, SEO research showed us that in the first 4 seconds, users have already formed an opinion of our website and even on that scale the first second is a crucial part, considering that with age and time (in a date format measuring with average attention span) that passes average attention span gets worse, therefore we have an ongoing epic battle with time/latency itself, and not many can claim different considering that we're already at the age of Instagram stories and TikTok timelines, I guess that it gets worse because of our everyday habits with social media.

A glass half full.

The glass is indeed half full rather than half empty despite all the challenges, there is a list of things we can do and although the analysis of such a list can go from shapes to colours to features that are tight with cloud products and more a synopsis of the situation could be phrased in a sentence...

«You DONT have to do that extra Click.»

Measuring in clicks can be quite effective because our refined architecture can teach us that if it's easier on a technical deadline-pressured implementation way that doesn't mean it's always the better solution, not when you deal with non-professional customers on the public web that is, the main difference between a professional vs a non-professional/everyday customer is that the first category is obliged to go through on whatever interface your sick horror story of a mind implemented,

For a Bonus Story: Click the interface image

the other guy is a king, and you're going to lose your head in less than 4 seconds.
The only way to save your head is to make him buy your product as fast as possible and then provide utility services on it through other means, people say that the longer a customer stays on a website is a good indicator of the website, that's not a lie but it won't apply for all situations like e-commerce websites, social media wants the user to stay hooked while anything that is not free has a big risk for the client to get confused and bail without an actual sale, that's why the save for later button got implemented and it's a great feature that aims to handle that exact confusion.

Is that confusion serviceable by that feature alone?
I think that it is to a certain extent, but it would be even better if we could avoid that confusion in the first place instead of handling it, by measuring with clicks you can get the customer as fast as possible to the end of the road, and that's good for everyone, I do believe that extra promotion of products belongs to the marketing department and the ad campaigns, not inside of your UX space, if you abuse your UX you're risking confusion and considering the average focus span out there it's bad news for people that want to play games.

Measure with clicks today, and then tell me, do you have to do that extra Click?

Let me know in the comments!

Thanks for Reading.

• Contact me on Twitter

• Contact me on the Web

It is all those things around it that make the idea of daily CI/CD difficult.

Splitting effectively is a bigger task than we give credit for, and it's not always done by very senior people, sometimes not engineers at all, and that's bad if you want to accurately estimate the odds.

What are the odds?

• Real-world variables (Personal / family issues / Health issues or stress-related, those are as common as it gets, therefore it goes #1)

• Department latency (Assume you need a minor thing from another department but you're not the centre of their universe, bizarre I know, but just stay with me until the end of this)

• Technical issues (It can happen and it can waste maybe even a full day, that's the basis on which ALOT of tech like Docker & other online IDE platforms with readymade environment variables are based)

• Vague product scopes / Logical fallacies (Self-explanatory while also the base of the real agile process and why we use it in most but not in all cases)

• Operational Corporate Red Tape (The devil himself, it should be #1 but it hides in the shadows, maybe disguised as Scrum/SaFe/Kanban or your idea of mixing kanban with scrum.)

• Introduction latency (It starts from a new tool to languages to new people in a team, everything new will need an adjustment/integration period, your manager doesn't think so, and that's why it might cost the team down the line.)

• Unknown factors (It would be proper to add 5% of your time just in case, or your 8-hour workweek won't stay 8 hours for long)

I'm certain that many people claim to know how to conduct their business effectively but those odds above are no small thing, accidents, by definition miss intent, for when they happen they're not intentional by the one that is taking part or have complete ownership of the accidents, think of it like when your phone falls and breaks down and you have all those information in it, there is not a single chance that you expected for it to happen, and yet it was out of your power, and it happened, that's how most estimations work when you are unaware of multiple odds, that's why experience matters a lot, the definition of APM (Actions per minute) is essentially the same thing, the second time you take the test your results will be elevated by more than 35% in comparison to the first time because now you'd be more experienced on the process, Software estimation is also like that.

What APM lacks is the human factor of trying to play nice and overpromise, for that reason be a pessimist and humble yourself when it comes to your skills, let alone the team skills that you know nothing about or even worse, you think that you know.

So how do you calculate the A.F.S.T, some of the techniques are mentioned in my previous article about Chaos Estimation but the truth is, whatever works for you is good for the world, as long as it works, calculating those odds though is the thing that will make everything glue together, no matter of what your model looks like or how complicated your new project might be.

Thanks for Reading.

• Contact me on Twitter: twitter.com/ChasanisNickos

1. 💡 Know your people.

Know their schedule, their strengths and weaknesses, what excites them and what brings them down, let them give you the feedback on anything that goes 10-15 days ahead of schedule.

You dont have to have a Dream Team, but you'll have to manage what you have properly If anything you estimate the outcome from people not the software itself, because the Software will not write itself (not at this time anyway) so knowing your variables will make a chaotic situation somewhat better.

They say that the enemy of Good is Perfect, well... yes but actually no, bad decisions will lead to technical debt, unless you're looking to escape to a different Company/Country/Universe before the deadline hits, you'll have to imagine what your decisions will lead to.

To be clear, there is no silver bullet, whatever works is good enough, but some things work better than others, i would start by not trying to be good, be realistic, dont try to play nice, i think that's the 101 on estimates, it is what it is, you always do your best but it's not a contest that you have to win.

You'll have to be ready to cut corners but that's not what the initial plan is in estimates, it is what happens in some cases, so if someone want to mess with your estimates get ready to pain him with the realities of what he'll have to lose (Utility from server or UI/UX features on an initial demo, all should be accounted)

2.✨ The three point estimation.

Take what is required as a feature, let's assume that it is pretty straightforward, there are no third party dependencies in terms of management to implement it, there is nothing special about it, it's all up to you (that's a pretty good scenario for most cases) You'll have to apply the days of development to the estimate in the coming form.

• Development time: 3 days = 33.3%

• Documentation: 3 days = 33.3%

• Testing: 3 days = 33.3%

Result = 9 days therefore 99.9%

In this technique you'll probably say that for a straightforward feature 9 days are probably too much, you could easily make it in 6 right?

All the projects that never made it to deadlines are thinking the same thing.

If we assume that your data aint so straightforward as you progress in development, and you get updates (usually bad ones) you'll have to start cutting corners, ultimately estimates are deal making, if you start with a bad deal you'll end up with a bad deal for everybody, but if you do it right, then you can cut corners between documentation and testing without sacrificing actual utility from what is required, so... being nice is a bad deal for estimation dealing, it will bite you back, and your client.

3. 📐 Average Development pace within a scrum team

Let me tell you one thing about Scrum teams, they are often misused, and i'll let it at that.

People ignore the people factor mentioned in the start of the article, they'll give unrealistic estimations that god knows what the algorithm was behind the final date and play with numbers while rating feature complexity that is more like a guessing game (Spoiler Alert: it doesn't end well.)

They will introduce more people in a team after 2 months and they'll also expect them to adapt in miliseconds because it's the most probable outcome.

Many things can go wrong, but what can we do about it?

Calculate the average development feature pace and give it a 5 for complexity, do it with all the developers, dont expect it to be 100% accurate because people have strengths and weaknesses therefore it might not illustrate their best self, but that's exactly the point, in a way you want them to fail for your estimations to succeed.

You need to have a clue of your team's pace even if the accuracy is limited, what you think it is your actual team's pace will be even less accurate, i would say it is definitely irrelevant and will lead to trouble.

While having a glimpse of what a 5 is in terms of complexity, you'll probably have to readjust it every now and then because you guessed it, the people factor, you're dealing with people, act like it and they'll thank you for it.

I'd like to thank the Estimation Police of Luxembourg for this technique.

**Well i dont agree with this Opinion section: **

At this point some will disagree with this, they are the same ones that believe that you can define a clear scope and ignore the people factor because Marketing said so, (At the expense of mental health and worklife balance maybe) they might even see unicorns and fairies in the woods, that wont help their deadlines, being realistic will.

Thanks for Reading.

• Contact me on Twitter: ** https://twitter.com/ChasanisNickos