I Do Waterfall When Nobody Is Looking
As a developer, I have never done Agile. I am stuck at Waterfall, despite Waterfall being already dead and gone when I started my career.
My modus operandi is close to Waterfall.
I have always liked to think in terms of systems, so that’s what I do. I alternate top-down and bottom-up thought processes, I get lost in details but am always reminded things should ultimately work harmoniously as a whole. I do a lot of top-down despite it being demonised by agile mindset.
I think about abstractions. That does not mean I implement them on the get-go, but I organise my code to make them implementable as the need arises.
I like them because humans need to simplify mess by grouping things as they see patterns arising and I have come to the conclusion I am a human despite some well-founded suspicion of it not being the case.
I create APIs that make sense and glue together different fragments of my software. Even if I did not want to, I would have to because the same people who like Agile now inexplicably like microservices.
Agile is for me, a developer, just a convoluted way to interface with employees who are focused on product. My approach to Agile is analogous to my approach to role-play.
The reason why product can see the progress of my development is not because the chunks are ready when I am supposed to demo them, they just look ready.
Sometimes they wonder why it takes so long to build an admin interface page. It’s because that page makes use of several input components that I am abstracting in a framework, probably implements filters which have to be dependent from the router, has to give meaningful feedback after validation and when the data is not available and so forth.
Just delivering that single page means having a lot of the architecture figured out.
However, I still am a developer, and as such I have learnt to get around this limitation and “deliver” chunks on time. How?
Behind the curtain, I have been merging 5 different branches where my coworkers’ and my work is inevitably spread out, committed a couple of hot fixes and most likely hard-coded a couple of constants because by the way, the environment is not ready yet.
The product you see is probably running on a development server that’s watching all changes to files to reload on time, lol.
Doing so is quite draining.
Agile is just a matter of communication for me.
It will never be intertwined with my natural development workflow and at this point, I know it’s not because I am doing something wrong but because of fundamental misconceptions.
There are probably some teams that actually do Agile.
Real agile development must smell a lot like spaghetti code.
That’s why lots of companies that proud themselves of being agile nowadays are hiring overpaid self-proclaimed software-architects.
There are no developers vs. software architects. There are those developers you decided to dehumanise and those who are cocky enough to look at you straight in the eyes and proclaim your product will not break in their hands.
If you want to see it from a more positive perspective, architecture is every programmer’s job.
As you can see, widely and wildly adopted agile methodologies spawn extremely odd misconceptions about my profession and correlate with the general unhappiness in the field, by being extremely biased towards product employees.
I believe it is not by chance that the worst developers I know decided to turn to product as they hit their 30s (no offense, some of you are still lovely and emotionally intelligent people ❤). Joking; also good developers decided to do so because the situation is just unsustainable.
There is stagnation in my field and I truly believe it’s time we start thinking of what can be done to improve this whole situation, possibly from scratch.