4 ms·
These principles are the first thing thrown out the window for new apps. I've been developing for around 15 years and I've noticed the excitement of new devs on
by redact207 7y ago
These principles are the first thing thrown out the window for new apps. I've been developing for around 15 years and I've noticed the excitement of new devs on new projects who'll rush out and just throw something together quickly to solve the immediate problem. I've done this a lot too.
This gets you a long way very quickly, which is proof that none of these principles really matter. Development continues along this path at a cracking pace for 6 months until complexity spikes and your productivity is at a crossroads. Do you take a step back, refactor, restructure so the code can be built on with any degree of velocity?
Hell no! Everyone's expecting the same output as when you started, so now you have to start copy/pasting everywhere trying to keep up, but your bug tickets have started ticking in so you have to address those. But you don't have tests, so now each bug fix raises two more bug tickets. Uh oh.
Better get more devs. Now you have people who don't understand the system making changes. There's no real structure so they just squeeze code in where they can, but progress is slow because it takes them five times the amount of time to reason about what the system does and bugs are still going out. Must be bad developers. Better hire a QA team to stop all that.
QA is reporting defects with each release candidate, and puts it back in the dev queue. After a year each feature is taking months to go out. The business just wants some simple changes, why is that so hard?
Enter the hotshot dev. They whip up a quick MVP with the latest language/framework plus it's serverless! No SOLID principles but that doesn't matter because the latest technology will fix everything. Better fire the old team and start fresh.
- alexvaut 7y agoAgreed 100%, I worked with legacy code at different stages: 1 to 2 years: very little of structure but still velocity matters a lot, complexity is not very high; 2 to 5 years: first customers. copy/paste designs and complexity arise; 5 to 10 years: I observed 2 different trends, software where refactoring happened, product is still not in a very good shape but it is still ok and the others, the garbage product with millions of lines: global variables, If/then/else copy/paste design, doesn't scale, broken everytime for no obvious reasons. It's going to take years to stabilise without too much churn. So everytime I'm working on a project, I pledge managers, devs to allocate time to refactor and follow those patterns, implement unit tests etc... everytime at whatever stage, after sometime the team realizes the benefit. So yes, without a doubt, good design patterns are keys to make our dev lifes as easy as possible. And the SOLID ones are definitely my favourites.
- p0nce 7y agoThanks for saying this, it's especially strange to see so much people disparage SOLID as if they have outgrown the concept because it was invented some years ago.
- Traubenfuchs 7y agoYou have missed an important step: Once the productivity goes down because complexity spikes, the original developers flee the company, if their cv allows them. They are then replaced by new hires that got fed lies at their job interviews. The managers had to lie to get new developers for their shitty codebase. That's where development time and costs double while quality is bottom of the barrel.
- p0nce 7y agoSurely we can do without the SOLID principles this time, right? right?