Why AGILE development sucks.
For example, if I was given a ticket for a requirement, where I say y = x + 2.
Then the code I write:
```
int func(int x)
{
return x + 2;
}
```
Now I'm given a new requirement, where it's supposed to double the input, and chain that up with the original function.
```
int func2(int x)
{
return 2 * func(x);
}
```
Now I'm given a third requirement, which is to substract 4 from the input, and it's supposed to chain up to func2.
```
int func3(int x)
{
return func2(x) - 4;
}
```
Now I'm given a fourth requirement, which is to substract 2x of the input from the chained function.
```
int func4(int x)
{
return func3(x) - (2 * x);
}
```
If I put all the code together, and run it:
```
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int func(int x)
{
return x + 2;
}
int func2(int x)
{
return 2 * func(x);
}
int func3(int x)
{
return func2(x) - 4;
}
int func4(int x)
{
return func3(x) - (2 * x);
}
int main()
{
int i;
for (i = 0; i < 256; i++) {
printf("%d\n", func4(i));
}
}
```
I will get all zeroes.
If I simply refactored the code, I would get:
```
int refactored(int x)
{
return 0;
}
```
This is why AGILE development sucks, and never gives the simplest possible code to do a particular task, unless you refactor it constantly.
Because you will always get "new" requirements, and some of them are conflicting with each other, or cancel each other out, and if you don't refactor to remove these conflicting requirements, they linger in code as bloat.
Strictly speaking, waterfall designers "know" what they want and would've gone straight towards "refactored(int x)", if they have enough insight (and deep knowledge of the task). This is why they still can't be beaten, when it comes to designing good software or hardware.
AGILE development is for babies who don't know what they're doing, and they're guessing every step of the way.
