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). + + + +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