Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "antipattern"
how often does it happen that you have to prevent terrible architectural decisions from being made, because people who are in charge but obviously have no clue, make really weird suggestions and are really confident that this is a good idea?
PM: so please analyze functionalities X with dev Y, since module Y that dev Y develops shall provide these functionalities.
me: as i said yesterday, module Y will use my module X and shouldn't care about how this is going to be implemented.
PM: yeah, but module Y shall be able to... (lists some functionalities)
me: yes, that's what i'm currently working on in module X. my current state of the API can be used in a way that... (lists different low level functions and how a combination of them can be used to provide these functionalities)
PM: okay, hmm... i just realize that module Y will actually be a user of module X...
i always thought that was crystal clear?? 🤦♀️11
Today was a bad dev day working on a shitty React project. Not that React in itself is bad, but it can be hell to work with when the code is a big pile a crap full of anti pattern code. I spent the day refactoring to try to fix a bug, but to no avail. It would take days if not weeks to put some order in this mess and to prevent such bugs.6
i had an epiphany today, in a discussion with the software architect of our new project.
i'm having the epic job to design & implement a prototype for a C++ library in a new software project and collected some inspiration in our "old" software, where i'm maintaining the module that fulfills the same functionality (i thought). i've been maintaining this module for around a year now. i analyzed the different features and stuff to consider and created a partial model of the new library.
when i showed it to the architect today, he was like "oh my god, no no no, you don't need all this functionality, this shall not be part of the new library!"
this was the moment when i realized how deeply fucked up the code base of the old module is.
imagine it like this:
you want to automate the process of making yourself a good ol' cup of coffee.
the reasonable thing would be to have
- a smart water boiler where you set parameters water temperature and amount of water to be fetched from the water supply
- a smart coffee bean grinder where you can set type of beans, amount of beans and grinding fineness
- a component where water and ground coffee are joined to brew the coffee, where parameters like duration, pressure etc. are set
- a milk tank where amount of milk, desired temperature and duration / speed of foaming can be set
- a sugar dispenser where amount of applied sugar can be set
- optionally, additional modules with spices, syrup, ice cubes, whatever for your very personal coffee experience
on requesting a coffee, you would then configure and orchestrate all components to your wishes to make you a fine cup of coffee. you can also add routines like "makeCappucchino()", "makeEspresso()", or whatever.
our software is not like this.
it is like this:
- a smart water boiler consisting of submodules that know how to cook water for e.g. "cappucchino with sugar" or for "espresso without sugar, but with milk and ice cubes"
- 5 smart bean grinders that know how to grind beans for e.g. cappucchino, espresso, latte macchiato and for 73ml of water preheated to 82°C
- a very smart sugar dispenser that knows how to add sugar to 95, 98 and 100°C coffee and to coffee made of BOTH coffee arabica AND coffee robusta beans.
etc. etc., i think you're getting the gist.
when i realized this, it was like, right in front of my eyes, this terrible pattern emerged like a foul, corrupted caleidoscope of chaos, through the whole code base of this module.
i've already known how rotten from the core this code base is, but today i've actually identified a really bad pattern that i hadn't realized before. the whole architecture is so bloated that it is hard to have an overview of the whole thing. and it would require a LOT of refactoring to repair this pattern.
but i guess it would also be infinitely satisfying because i could probably reduce the code base for 30% or something...
but unfortunately, this is never going to happen, because screw refactoring.
it's a great feeling to start this new library from scratch, tho...6