Sprints - The Biggest Mistake Of Software Engineering

Summary

The video script discusses the misconceptions around agile software development, emphasizing that agility is not about speed but about delivering value and adapting to change. It humorously critiques various aspects of agile methodologies like Scrum and Kanban, and introduces the concept of 'Extreme Goorse,' a play on 'Garage', suggesting it as a more realistic approach to software development that values practicality and direct problem-solving over strict adherence to formal processes.

Takeaways

• 🤔 Agile is not about speed but delivering value sooner and being able to adapt to change quickly.
• 🏃‍♂️ The term 'Sprint' in Agile might be misleading as software development is more of a marathon than a sprint.
• 🤯 Burnout in software development is often due to meaningless tasks and a lack of progress, not necessarily the pace of work.
• 👥 Effective teamwork relies on individual accountability and the collective desire for change and improvement.
• 🚫 Agile methodologies like Scrum and Kanban can sometimes lead to misery if not implemented correctly.
• 💡 The idea of 'Extreme Goorse' is introduced as a humorous and exaggerated response to Agile practices.
• 🔥 Extreme Goorse promotes a reactive approach, only addressing issues when they surface.
• 🌐 The manifesto for Extreme Goorse satirizes Agile principles, highlighting the importance of speed and problem-solving over strict adherence to process.
• 🛠️ In Extreme Goorse, there is no refactoring, only rework, and if a problem arises, a quick solution is applied.
• 📋 Comments and documentation are seen as unnecessary in Extreme Goorse, as the code itself is considered the only required documentation.
• 🔒 Security is considered secondary in Extreme Goorse, with trust in luck and a lack of hacker interest as reasons for its lower priority.

Q & A

What is the main misconception about agile software development?

The main misconception is that agile is about being faster. In reality, agile is about delivering value sooner and in a constant manner, with the ability to react and change course earlier.

What does the speaker suggest as an alternative to traditional stand-up meetings?

The speaker suggests using a Slack chat or a team channel where members can quickly communicate any roadblocks or issues they are facing, instead of having a formal meeting.

What does the term 'extreme goorse' refer to in the context of the script?

In the script, 'extreme goorse' is a humorous term used to describe an extreme, chaotic approach to software development, which is not actually a real methodology.

What is the speaker's view on the relationship between agile methodologies and burnout?

The speaker believes that burnout is not caused by moving fast or the expectation of moving fast. Instead, it is more likely due to doing meaningless tasks and feeling like just a cog in a machine.

How does the speaker describe the ideal team dynamic in software development?

The speaker prefers a team dynamic where members set goals together, work independently, and then reconvene to discuss progress, roadblocks, and hold each other accountable.

What does the speaker suggest is the fundamental problem with agile?

The speaker suggests that the fundamental problem with agile is its broad definition, which can lead to misinterpretations and the implementation of rigid structures that may not suit every team or project.

What is the speaker's opinion on the use of 'go horse' as a programming approach?

The speaker humorously acknowledges 'go horse' as a term from the script, but does not endorse it as a real programming approach. The speaker emphasizes the importance of effective communication, accountability, and adaptability over any specific methodology.

How does the speaker feel about the practice of rewriting entire applications?

The speaker is skeptical about the practice of rewriting entire applications, stating that it rarely works and often leads to more problems than it solves.

What advice does the speaker give regarding code quality and comments?

The speaker advises that code quality should not be compromised for speed, and that comments and additional documentation are often unnecessary if the code is clear and well-written.

What is the speaker's stance on the role of testing in software development?

The speaker believes that testing is important and should not be seen as a waste of time. However, they humorously suggest that in the context of 'extreme goorse', if the code compiles, it might be considered enough.

How does the speaker view the concept of refactoring in software development?

The speaker supports refactoring when necessary but humorously notes that in the 'extreme goorse' philosophy, there is no refactoring, only rework if something breaks.

Outlines

00:00

🚀 Misunderstandings about Agile and the Sprint Mindset

The paragraph discusses common misconceptions about agile software development, emphasizing that agility is not about speed but about delivering value quickly and consistently. It critiques the use of the term 'Sprint,' suggesting it implies a focus on speed rather than communication and problem-solving. The speaker proposes a more effective approach would be to address issues directly and promptly, rather than in lengthy meetings, highlighting the importance of team communication and adaptability over rigid processes.

05:02

😓 The Realities of Burnout in Software Development

This section delves into the issue of burnout in the software development industry, challenging the notion that fast-paced agile practices are the primary cause. Instead, it argues that meaningless tasks and a lack of genuine progress contribute more significantly to burnout. The speaker suggests that the repetitive nature of certain development tasks, coupled with a lack of accountability and engagement, can lead to dissatisfaction and attrition. The paragraph also touches on the limitations of methodologies like Scrum and Kanban, and the speaker's preference for a more flexible and goal-oriented approach.

10:03

💡 Agile Manifesto and the Extreme Goorse

The speaker humorously introduces the concept of 'Extreme Goorse,' a play on the Agile Manifesto, which is described as a Brazilian interpretation of agile methodology. The paragraph satirizes various aspects of software development, such as the focus on speed over quality and the reactive nature of problem-solving. It also pokes fun at the idea of constantly rewriting code and the lack of respect for standards, suggesting that in the pursuit of speed, developers may sacrifice important principles of good coding practice.

15:04

🛠️ The Challenges of Team Building and Project Management

This paragraph addresses the practical challenges of team building and project management in software development. The speaker argues against the idea that teams cannot be changed or replaced once established, suggesting that a competitive wage can attract skilled developers. The paragraph also emphasizes the importance of delivering software consistently and the unrealistic expectations set by new frameworks that focus on speed rather than sustainable development practices. The speaker advocates for a more measured approach to development, one that values long-term success over quick wins.

20:04

🎯 Extreme Goorse Axioms and their Implications

The paragraph presents a series of 'axioms' for Extreme Goorse, a tongue-in-cheek set of principles that satirize extreme approaches to software development. These axioms suggest that Extreme Goorse is faster than other methodologies, creates more problems than it solves, and is completely reactive. The speaker humorously explores the idea of committing code without regard for quality or standards, and the notion that deadlines are flexible in the face of client demands. The paragraph also touches on the concept of self-sufficiency in Extreme Goorse and the dismissal of traditional project management roles.

25:04

🔄 The Downfall of Legacy Code and the Goorse Approach

The speaker reflects on the challenges of dealing with legacy code and the Goorse approach to software development. The paragraph humorously suggests that refactoring is unnecessary and that code duplication is preferred over abstractions and code reviews. The speaker also discusses the importance of embracing the chaos of a project and the potential pitfalls of trying to impose order on a Goorse-driven project. The paragraph concludes with a nod to the idea that success and failure are subjective, and learning from a project's challenges is a form of success in itself.

Keywords

💡Agile

Agile is a software development methodology that emphasizes flexibility, customer collaboration, and rapid and adaptive responses to change. In the video, the speaker discusses misconceptions about agile, clarifying that it's not about speed but about delivering value sooner and being able to adapt to changes quickly. The term is used to critique the extreme interpretation of agile practices, such as constant sprints and stand-up meetings, which the speaker feels may not always be effective.

💡Sprint

A Sprint in the context of agile development is a time-boxed period during which a specific goal is to be achieved. The speaker in the video questions the term 'Sprint' as it might imply a focus on speed, which contradicts the true essence of agile. The speaker suggests that software development is more of a marathon than a sprint, highlighting the need for long-term, sustainable effort rather than a quick burst of activity.

💡Burnout

Burnout refers to a state of chronic physical and emotional exhaustion, often accompanied by feelings of cynicism and detachment. In the video, the speaker discusses how the pressures and expectations in software development can lead to burnout among developers. The speaker argues that doing meaningless tasks and feeling like a cog in a machine can contribute to burnout, rather than the pace of work itself.

💡Extreme Goorse

Extreme Goorse is a humorous and satirical term used in the video to describe an exaggerated approach to software development, which prioritizes speed and getting things done over best practices, quality, and collaboration. The speaker uses this term to critique certain aspects of agile and scrum methodologies, suggesting that in their extreme forms, they can lead to chaotic and unsustainable work environments.

💡Stand-up Meetings

Stand-up Meetings are short, daily team gatherings where each member reports on what they did the previous day, what they plan to do today, and any impediments they are facing. In the video, the speaker questions the effectiveness of these meetings, suggesting that they can sometimes be a waste of time and that more direct and informal communication methods might be more efficient.

💡Kanban

Kanban is a visual project management method that involves using a board divided into columns to represent different stages of a process. In the video, the speaker mentions Kanban as one of the agile methodologies that can be perceived as miserable due to its focus on continuous workflow and the pressure to keep the process moving, which may not suit every individual or team dynamic.

💡Refactoring

Refactoring is the process of restructuring existing computer code without changing its external behavior. Its purpose is to improve the nonfunctional attributes of the software, making it easier to comprehend, reducing its complexity, and increasing its maintainability. In the video, the speaker humorously suggests that there is no need for refactoring in extreme goorse, as the focus is on quick solutions and moving forward, rather than improving the existing codebase.

💡Legacy Code

Legacy Code refers to older code that continues to be used and maintained, often without extensive documentation or following modern coding practices. In the video, the speaker mentions legacy code in the context of not questioning or changing working code, highlighting a common challenge in software development where existing, potentially poorly written code, is maintained instead of being refactored or replaced.

💡Code Duplication

Code Duplication is the practice of having identical or very similar pieces of code in multiple places in a codebase. While it can sometimes provide short-term efficiency gains, it is generally discouraged because it can lead to maintenance difficulties and increased risk of bugs. In the video, the speaker sarcastically endorses code duplication as a feature of extreme goorse, emphasizing the focus on quick solutions over long-term code health.

💡Documentation

Documentation in software development refers to the written descriptions and instructions that accompany a program or system to explain how it works and how to use it. The speaker in the video argues that in the context of extreme goorse, code itself should serve as the primary documentation, with comments and additional documentation being unnecessary. This perspective reflects a controversial stance on the importance of clear and comprehensive documentation for long-term maintainability and understanding of the codebase.

💡Security

In the context of software development, Security refers to the measures taken to protect a system from potential threats and vulnerabilities. The speaker humorously downplays the importance of robust security in extreme goorse, suggesting that reliance on luck and a lack of interest from hackers are sufficient. This satirical comment highlights the reality that in some fast-paced development environments, security can be overlooked, which can lead to significant risks.

Highlights

Agile is not about being faster but delivering value sooner and in a constant manner.

The fairest definition of agile is to pretend that you're the king of England, valuing ceremony and tradition over progress.

Instead of daily stand-ups, a Slack chat could be more efficient for quick communication.

Agile is a reaction to developers not knowing how to communicate with each other effectively.

Sprints are just a time box for a certain amount of work to be done, not a measure of speed.

Software development is more like a marathon than a sprint, with repetitive efforts over time.

Burnout in the profession often results from meaningless tasks and a lack of progress.

The problem with agile is not the speed but the expectation of moving fast, leading to burnout.

Extreme goorse methodology is a humorous and exaggerated take on agile practices.

Extreme goorse suggests that errors only exist when they surface, implying a reactive approach.

In extreme goorse, there is no deadline, and the focus is on getting things done regardless of time constraints.

Extreme goorse does not respect standards, advocating for writing code however it solves the problem.

Extreme goorse is self-sufficient and does not require management or project owners.

The more extreme goorse is practiced, the more problems will be solved using it, leading to a chaotic system.

When using extreme goorse, if the system is abandoned for a trending methodology, the project may collapse.

In extreme goorse, the code is the only documentation needed, and additional comments are unnecessary.

Security is considered a secondary detail in extreme goorse, with a reliance on luck and lack of hacker interest.

Transcripts

all right anyway Sprints the biggest

mistake of software engineering I

actually already agree with this take do

we even need to read the

article do we even need to I mean the

man is scare quoting it just to remind

you that you don't actually run you use

words that sound like exercise but we

all know you haven't left the chair in a

long time damn I know harsh yes reality

real sprinting towards failure okay

let's talk a little bit about being

agile yeah that's a that's a word you

don't describe with Arch users and the

Brazilian definition of the current

state of agile generated extreme goorse

methodology extreme goorse what the hell

is okay I don't know what the extreme

goorse is now you got me uh

misconceptions the first thing is to get

the common misconceptions out of the way

agile is going fast by now we should we

all should know that agile is not about

being faster it's about delivering value

sooner and in a constant Manner and

being able to react and change course

earlier I wouldn't necessarily say

that's what agile's about I I'd say the

fairest definition of agile is to

pretend that you're the king of England

and you love ceremony and that tradition

trumps progress I thought that was the

proper d definition yeah right like we

all like to get dressed up in our robes

we all want to have that nice hour and a

half long ceremony for me to do the

thing that I was already doing but to

say I'm going to do the thing again and

then I would love to have like a quick

15minute

check-in to tell you that I'm doing the

thing that I'm doing like who like like

real talk like like instead of like

imagine you had a roadblock you could

wait till the next day and talk about it

and stand up or you could just find the

person that you're roadblocked and go

and talk to them like why do you need to

tell everybody about your roadblock why

not have like a little like like why not

have a team slack chat where you're just

like yo dog I got blocked by this and

then instead of wasting everybody's time

to be in a meeting someone an hour later

could be like yeah hey guess what I've

seen this before you know how I I can

help you with this you know how crazy

that would be to uh completely destroy

standups and just have a slack chat

every now and then hey I'm just saying

I'm not a big fan of multi thousand

15minute meetings you know that's my

ideal that's everybody's ideal because

it's better it just simply is better

okay we can even have a stupid Channel

called I got [ __ ] Dash your team name

and then you put your problem in there

and then everybody knows that that that

channel is really important to listen to

okay I'm just saying I just spilled

coffee on myself we need to stand up I

got to tell everybody about this oh [ __ ]

I you know what I need to take I I need

I need a moment here okay I'm going to

talk about this for at least 15 minutes

in stand up that I spilled coffee on

myself today skill issue I'm dying of

skill issues I'm literally dying in

skill issues right now I pissed

myself oh my God bro oh hell no man what

the [ __ ] man get your ass on Sprint is

doing all in the time slot okay so

you're saying agile is not about being

fast but it also means having Sprints

questionable so you exist in society too

it might have been an unfortunate term

used by developers of scrum but it

certainly doesn't help with all the

agile as being fast people like to think

Sprints however are just a time box for

certain amount of work to be done you

know the more I think about agile is

agile just really a reaction to the fact

that developers don't know how to talk

to each other and we didn't have a good

chat app to avoid talking to people when

created you know like slack really

wasn't there you know I was I was using

Skype or some some nonsense I was

literally using Skype at one of my jobs

as a form of communication like we were

practically on we're practically on AOL

Instant Messenger sending each other

messages yeah aim just shooting a little

bit of aim at each other oh yeah hey hey

everybody Boomer yeah boom

the problem Executives push for agile

and scrum because they think uh about

being fast Sprints the biggest problem

is that making software is not a Sprint

it's a marathon yes well it's actually

you do 400s over and over and over again

until you die or create a marathon

that's actually what software is is it's

just individual individually the worst

race you've ever done the 400 or you

could say the 800 I think we could go

back and forth on the worst possible

foot RAC is either the four or the 800

and you do that that over and over again

until one of you die or you make a

product unless you're not human you know

that you cannot Sprint a marathon it's

really bad uh hell most people can't

even Sprint a short race and I'm also

talking about software what the hell are

we talking about the people resolve

burnout plain and simple the profession

loses a lot of good people because of

burnout not to be confused with burn

down charts also from scrum but somehow

that doesn't generate any confusion for

people the same people expecting more

and more from developers so burnouts

burnouts very interesting I don't think

that moving fast is the problem or the

expectation of moving fast is the

problem for Burnout I I just don't think

that that's what causes burnout I don't

think burndown charts are what causes

burnout I don't think any of those

things are I think doing meaningless

things is much easier to cause burnout

right like if you feel like you're just

like just such a cog and you're just so

cogged out and that everything you do is

just such a process and every last

little point in your next three four

five 6 weeks are all individually mapped

out for you never to have any questions

and then you're going to have to go and

wake up every day and tell everybody

what you're doing every single day in

some stupid meeting where some guy's

going to tell you all about his dog for

the 17th time about how cute boots is

well boots is just so cute you should

see boots this morning boots is so it's

just like you do that over and over and

over again and man that's not that much

fun like there's probably different

archetypes of

burnout I just don't think moving fast

is the problem right like if you got up

and your environment is changing all the

time and you're constantly never making

progress and it's an ever like it's

literally like playing wow and just

trying to level by killing uh pigs like

that uh that starc that Starcraft [ __ ]

it that South Park episode yeah you get

burnt out pretty pretty much because

it's not fun let's not blame agel for

burn I'm not going to blame agel for

Burnout I don't think that that's the

fundamental problem like I don't think

those things make burnout worse like I

don't think agile itself leads to or

doesn't lead to burnout let's blame

agile for everything yeah I mean I I

mean understandably agile agile is like

that kid that always tells too much and

you just want to punch him that's real I

understand that the problem I have with

just like whenever someone says like

agile is actually great or agile can be

you know like you're talking about scrum

not agile the problem is is that scrum

is an implementation of agile in some

sense it's the attempt to codify what

agile is into a thing into a set of

things people can do and that becomes

increasingly more and more difficult

kbon is another one of these but kbon

can feel equally as like Miserable as

scrum is right it can be equally

miserable because kbon in some sense I

find kbon almost worse because it's just

like you're literally so

replaceable that you're just a cog that

takes off the top of the list like

that's your value is that you are just

like how do we effectively Drive

software engineering into what llms

should do right it's just like we're

going to break down the task as as small

as possible and you're going to just

shove through these things on just like

a fire hose right kbon is NeverEnding

torture absolutely and so it's just like

my I mean my personal favorite way to

develop things is that you get together

with the people you're you're trying to

develop with set a set of like goals and

then you come back a week later and you

talk about how are your like progress

towards the goals going in any roadblock

or anything you have in the way you

reach out to the team members

individually you don't you don't do any

sort of planning you don't do anything

of course that's agile agile that's the

problem with agile agile has such a

broad definition it's only part of agile

it's one definition which is a team

should set forward its own thing right

that's it just set a goal as a team we

set one goal one thing we want to make

we want to improve the reliability of

service X go and make it happen

team right fail fast it's it's but it's

not a Sprint like there's no there's I

don't think check-ins or I don't think

like tasks and extreme breakdowns work

right if everybody's held accountable

for what they do and every last person

wants to see change and works hard you

don't need need all these rules right

and when people aren't doing it you're

protective of the team and you talk to

them you address issues and eventually

you have to let them go like it's that

simple I'm going to Agile these nuts

across your face right such hard well

you have to you have to create the team

you have to create the team you want

right anyone that thinks you can't

create the team then that's a that's a

problem this assumes Yes again you are

the reason why teams have to be held

accountable

right you have to find people like

yourself that hold people accountable

and that's that like if you're if you're

trying to do it in some top down way

you're going to just land and scrum in

Daily meetings and every this that and

the other because now management has to

come in and they're the ones that have

to go through and do all this stuff and

then it's just awful like I don't want

that do you want that I don't want that

but I love my scrub mommy well we all

love our scrum Mommy okay okay but only

one team gets a scrub mommy and that

ain't me okay uh first off I don't

believe that I I I don't believe this at

all right here uh I cannot create my

team and 30 million is on the line and

contracts with deadlines are in effect

if we fire people I have no one to

replace them

BS if you literally paid people a good

wage a competitive wage whatever that

competitive is for your area slightly

better 5% better 10% better whatever it

is you will literally have a load of

developers knocking on your door right

now saying pay pay me pay me pay me I'll

do the work I'll do the work good and

you you can just handpick right now

great

talent okay there are people desperate

for jobs right now this I this idea that

somehow like I mean I understand like

tribal knowledge is really important and

you can't just get rid of an entire team

and then come back and create a new one

right like that's not it's not that easy

right people are really really really

really wanting to work there's plenty

like that is not right that is not

like a thing okay all right anyways uh

develop deliver deliver software not

fast but with consistency the first

thing people see in new Frameworks is

how fast they can make a to-do app yes I

hate to-do apps I hate to-do apps but

that's not the reality for most of us go

horsing quick and dirty to make a big

bowl of Muddy pasta is okay for an MVP

side project and a throwaway project I

still don't know what go horsing is is

this like a is this a Brazilian term

that's being like transliterated

across languages is there like is am I

missing something uh but most of the

time you'll be working for months on end

on something what matters making one

thing fast than slowing down on each new

feature until you jump

ship this yeah

this this is actually pretty funny is

that you slow the the the inevitable

slowdown or decide to rewrite the whole

thing dude holy cow oh so this must be

okay so this is I see Axiom 8 Axiom 10

this is funny cuz right when I said jump

ship my next thought was or you just try

to burn the ship and get a new one and

then here you go rewrite the whole thing

I might okay maybe extreme goorse is a

I'm a fan of extreme goorse like is this

is this HDMX mentioned is this what's

happening right now okay as I was

writing this post it came to my

attention that extreme goorse is

commonly known only by Brazilian deaths

yes I literally I first off Brazil

mentioned can we get a Brazil mention

can we just get I just just just so you

know Brazil was just mentioned okay and

I I don't think people are are are

experiencing how amazing that is

processess right Brazil mentioned this

is fantastic horsing the man's horsing

around but not enough around the world

this was made by who knows when by who

knows who it's a little outdated in the

writing I'll refactor as needed but you

will see it's Timeless C axium 14 uh and

re and relevant to what I was saying

disclaimer this is basically not a to-do

list it's a funny it's let's see it's

funny as a meme but as I like to say if

all you do are things from memes then

your life is a joke it's real take you

know those people that always are like

ironic on the internet and they're and

they're and they're

continuously just like saying [ __ ]

that's like really on the edge like real

Edge Lords and they're just constantly

being like dude it's just a joke bro but

they only operate in that mode you know

what I mean and you're just like are you

sure you're living ironically or are you

just like is that just you

it's this this is who you

are uh there were some translations out

there but I translated them here by

timeing uh let's see by trying to update

things and make it more easy uh make it

more sense today enjoy but don't follow

it little note people usually uh just

read x g Extreme goorse as goorse all

right the goorse manifesto by the way I

typically don't like to read manifestos

um just the idea the whatever reason the

word manifesto gives me the heebie

jeebies okay I don't I don't I don't

like it but we're going to do it anyways

here we go if you had to think it's not

extreme

goorse in extreme goorse you don't think

you do the first thing that comes to

mind there's no second option the only

option is the fastest

one there's this weird part of me that

likes and hates this all at the same

time I feel I feel like a mixed drink

right now you know what I mean I can't

tell which part of me loves this and

which part of me hates this

you know what I mean and the hard part

is is that I'm thinking about something

and it just told me not to think let Tim

Cook

already okay so so extreme goorse can

also be replaced with GSD that's the

American way to say it which is get [ __ ]

done um yeah for the most part I

actually genuinely agree with this

whenever I'm prototyping or kind of

specking out something or just trying to

investigate how something works like

this is what I do I don't even try to

make it pretty at all I I'm building it

just to get [ __ ] done come up with some

ideas and then maybe make something that

makes sense later on uh there are three

ways of solving a problem the right the

wrong and the extreme goorse which is

like the wrong one but

faster I'm not sure if these are great

axioms extreme goorse is faster than any

other methodology of software

development you know okay okay the more

extreme goorse you do the more you'll

need to do it for each problem solved

using extreme goorse about seven more

will be created but all of them will be

solved using uh extreme goorse extreme

goorse tends to Infinity I'm glad we got

like the limit definition of Extreme

goorse as time goes as time goes to zero

is infinity react mentioned is that what

is that what we're seeing zoo zoo

mentioned extreme goorse is completely

reactive erors only exist when they

surface so that's kind of a funny phrase

they're using there erors only exist

when they

surface which by all definition is the

only ways in which errors become

known which you can be

proactive by trying to look at the

surface so is it reactive or proactive

extreme goorse accepts everything solved

the problem compiled commit that's it

always commit before updating if [ __ ]

happens your part will always be correct

and your colleagues can go [ __ ]

themselves I think I'm a huge fan of I

think I'm a huge fan of goor right now

extreme goorse goorse I think I I'm I'm

in on this one I'm in on this one

Extreme goorse has no deadline the

deadlines set by your client are more

are mere details you always uh be able

to implement everything in the given

time even if it involves accessing the

database with Shady

script I mean I I've worked that job

I've been at this job I know this job I

feel this

job be prepared to jump ship when it

starts to sink or blame someone or

something else for those who use extreme

go horse one day the ship will sink uh

the more time passes the more the system

becomes a monster the day the house

Falls it's better to have your LinkedIn

updated or have something to blame be

authentic extreme goorse does not

respect standards if you write code

however you want let's see write code

however you want if it solves the

problem commit and that's it isn't that

pretty much I mean I mean that's

actually just modern-day coding this is

this is actually just like this is

actually just like this is just coding

right I I hate to break this to you but

this is how everybody writes code when

somebody tells you something is cleaner

it's not cleaner it's because they like

it

differently okay some people like their

cucumbers pickled like that's just a

fact of life 10 there is no refactoring

only rework if [ __ ] happens redo a quick

extreme goorse that solves the problem

the day the rework involves rewriting

the entire application jump ship uh and

the boat will sink it will sink it

actually will sink I have rarely seen a

rewrite work and when a rewrite happens

I've just never I've never seen good

things about rewrites extreme goorse is

completely uh anarchic uh the figure of

a project manager is completely

disposable there is no owner everyone

does what they want when problems and

requirements arise you know this isn't

far from bad advice because I mean I

understand like this whole list is like

supposed to be bad advice but there's

accidentally good advices in here in the

sense that everyone should try to solve

a problem or everyone should try to like

do what they think is best when problems

or requirements arise rather than having

formal meetings about everything like

I'm actually on that team that there is

something like sometimes these bad

advices are actually accidentally okay

always delude yourself with Promises of

improvement I mean I agree with that

okay I agree I agree I mean I I I agree

tweet material putting to do in the code

as a promise of improvement helps the

extreme goorse developer not feel

remorse or guilt for the [ __ ] for the

[ __ ] they made of course refactoring

will never be done C M 10 uh extreme

goorse is absolute it does not cling to

relative things time and cost are

absolute quality is totally relative I

actually this is accidentally true I

know this is supposed to be a meme but

this is accidentally

true uh never think about quality only

let's see only about the shortest time

uh the solution can be implemented in

fact don't think just do it that's Axiom

one you should have cited Axiom one okay

if we were proper here you would have

known that that that that that if you

had to think it's not extreme goorse you

would have known that but you clearly

didn't you forgot clearly whoever wrote

it was not thinking uh extreme goorse is

timeless scrum extreme programming all

of this is just a fat extreme goor does

not cling to fads of the moment that's

for the weak Extreme goorse has been and

it will always be used by those who

disregard

quality extreme cor is not a workaround

oh let's see on Extreme goorse is not

always workaround oriented programming

many workaround oriented programming uh

requires a high level of thinking but

Extreme goorse does not see axm one

thank you translator node in the

original it uses garia oriented

programming since I understand some

people will know what garia is it's more

encompassing term than just hack or

workaround is garia something like

circumference is that like fairish it

means ass doesn't it garia is like

Brazilian

macgyverism appreciate that anyways uh

don't try to swim against the tide if

your colleagues use extreme goor for

programming and you are the stickler who

likes to do things properly forget it

for each design pattern you use

correctly your colleagues will generate

10 times more rotten code using extreme

goorse extreme goor is not dangerous

until a little order arises the axium is

very complex but it assumes the projects

using extreme goorse is in the midst of

chaos don't try to add order to extreme

goorse uh it's useless and you can waste

precious time this will make the project

sink even faster don't try to manage

extreme goorse it is self-sufficient

just like the chaos you know there's

actually an accidental piece of wisdom

in this one as well which is like if you

came into a project it had one month to

ship and it's just absolute

craziness like do you think you can

just say well this is crazy we better

rewrite this right sometimes you do just

have to embrace the chaos sometimes

you're like this C this is crazy I'm

going to make a script that does like a

full integration test on this and I'm

going to hope everything goes great you

know like you just sometimes Thanos

mentioned sometimes you just got to go

for it you know what I

mean just give the gasoline for the fire

you called exactly chaos CL Charlie yeah

exactly let's see uh goorse is your ally

but it is vengeful as long as you want

goorse will always be on your side be

careful don't abandon it if you start a

system using goorse and abandon it using

trending methodology you're [ __ ]

goorse does not allow for refactoring

C10 and your new full of Frills will

collapse and at that time only goorse

can save you if it's not working don't

or if it's working don't touch it never

changed let alone question working code

I mean this is every piece of Legacy

code that has ever existed that's a

waste of time especially since

refactoring doesn't exist C10 time is is

the gear that moves goorse and quality

is a negligible detail testing is for

the week if you put your hands on goorse

system you better know what you're doing

if you know what you're doing why test

testing is a waste of time if code

compiles that's enough get used to the

feeling of eminent failure failure and

success always go hand inand and in

goorse it's no different people often

think the chances of a project failing

using goorse are always greater than it

being successful but success and failure

are a matter of perspective did the

project go down the drain but you learn

something then it's a success for you

the always positive Bob ra style I love

it uh the problem is yours only when

your name is in the G blame never put

your hand on a file whose author is not

you if a team member dies or is sick for

a long time the boat will sink in this

case use Axiom a oh my goodness more is

more with goor you thrive on code

duplication code quality doesn't matter

and there's no time for abstractions

code code reviews or refactoring time is

essential so copy and paste

quickly again there's so much accidental

almost wisdom in here almost it's like

so close isn't it funny that what is

actually a good idea can be masqueraded

as such a bad idea isn't it funny how

that works like that you could like

that's it's actually one of the dangers

it's I think it's one of the reasons why

really bad ideas tend to crop up in

software is that I can make such a straw

man such as this and sell it as a reason

why you should abstract everything and

it's like I've just created this bogey

man that's like impossibly

scary this is why we should do something

else and then the next thing you know is

you find yourself just with Builder

factories coming out the ass it's

crazy right uh not accidental we now we

we know it's the right way it's uh like

it's grug programming not Grog Grog is

something different anyways the code is

the documentation I actually do agree a

lot with this General approach uh in

goorse the code is the only

documentation needed comments and

additional documentation are just a

waste of time if someone can't figure

out how the code Works they shouldn't be

working on it cm20 um again this is so

close to being true I actually really

dislike 99% of code comments one of my

favorite code comments was a code

comment at the top of the file and just

said hey I had to make a lot of

shortcuts in this file I want you to

know that beforehand that these two

tickets and jro were the reason why I

did what I did I'm not happy about it

but I did it and I am happy about it the

bug was fixed this code is [ __ ] sorry

not

sorry that was at Netflix it was

fantastic one of my favorite developers

I've ever worked with put that code

comment at the top it was amazing it was

perfect it was exactly correct the code

was

[ __ ] I couldn't be upset because I saw

why it was and I just kind of agreed I

was like yeah you know you're right

you're right you're right the code is

horse crap the go the code is goorse but

I'm not sure if you could give any you I

don't I don't know if you could do any

better in goorse a security is a

secondary detail it's a waste of time to

implement robust security C5 and S trust

in luck the lack of interest from

hackers C

ax8 it's pretty good this is pretty

good uh you know it's weird

because I can't tell what part of this

was satire and what part of

this wasn't satire you know what I mean

like I can't tell I honestly can't tell

cuz like this right here feels like it's

meant to be true right that agile is not

about moving fast it's about delivering

value sooner and in a constant Manner

and being able to react to change uh and

change course earlier like that feels

like you're you're trying to give a

legit definition of

agile and then just tosses

in in goorse you don't

think