From b91ff99b4282d77d67231685173c7cfa98dfa4a3 Mon Sep 17 00:00:00 2001
From: Julio Biason <j.biason@engys.com>
Date: Fri, 30 Jun 2023 16:54:44 -0300
Subject: [PATCH] Working on an holistic view of development methodologies

---
 ...rywhere-at-once-in-software-development.md | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 content/thoughts/everything-everywhere-at-once-in-software-development.md

diff --git a/content/thoughts/everything-everywhere-at-once-in-software-development.md b/content/thoughts/everything-everywhere-at-once-in-software-development.md
new file mode 100644
index 0000000..a5651b4
--- /dev/null
+++ b/content/thoughts/everything-everywhere-at-once-in-software-development.md
@@ -0,0 +1,77 @@
++++
+title = "Everything Everywhere At Once In Software Development"
+date = 2023-06-30
+draft = true
+
+[taxonomies]
+tags = ["software development"]
++++
+
+A lot of stuff we learn (and some things we don't learn, specially at Uni) is
+told in a vaccuum, in which only it exists. But there is a lot of things that
+are connected (or, at least, they should).
+
+<!-- more -->
+
+Let's start with...
+
+## TDD
+
+Test-Driven Development, or just TDD for short, is the idea of building the
+tests before you build the code. Sure, that means the test fails, then you add
+the code, and the test finally passes. This flow is described as
+"red-refactor-green" in the TDD lingo.
+
+But what you need to test? Well, if you follow the language used in TDD, you
+write the test **and then** refactor. This means you need to find out what the
+code needs to do, write a test that replicates the behavior you want and then
+write the code.
+
+{% note() %}
+**The internet hates me**: One general description of TDD you may find in the
+internet is that you should write a test for every function/class in your
+project. I've told those that you shouldn't make it an one-to-one when writing
+tests like this, and I've been laughed at for that.
+
+Just a warning that you may find other explanations for what TDD is and it
+won't say exactly like that.
+{% end %}
+
+But where those behaviors come from? That's when we have to talk about...
+
+## Agile
+
+Agile is a set of project management methodologies in which you start with
+small pieces, deliver them, and then gather more information. This process
+assures that you're moving in the right way, letting the ideas settle instead
+of having just concepts and hoping they are right the project reaches its end
+and it is delivered.
+
+{% note() %}
+**The internet hates me**: If you look for agile on the internet, you may find
+a series of posts saying that "agile sucks" or something like that. So far, all
+the things I've read seem to follow the agile book line-by-line instead of
+understanding *why* things are that way.
+
+Also, the behavior descriptions can come from other project management
+methologies, like Cascade, in which you have the whole project specified and
+described way before any piece of code is written -- which have its own issues.
+{% end %}
+
+Besides gathering information at each step, there is a discussion about the
+"Definition Of Done", on when a feature is complted: Is it when the developer
+finishes writing the code? Is it when the testers say it is ok? Or is it when
+the client says it fits their needs, 'cause the issue could be the information
+gathering way before it reached the developer?
+
+The point of "was it right before reaching the developer" have a definition
+that is mostly forgotten: It should pass the "Definition Of Ready", which, as
+with Definition of Done, tries to describe when something is good to be
+developed, like "Do we have the proper definition?", "Does it have an example
+of what is the expected behavior?", "Do we have the error
+conditions/constrains?" and so on.
+
+If a task passes the "Definition of Ready", then the developer have the
+expected behavior from the system, which brings us back to...
+
+## TDD