!rant, probably, even though kind of yes, but not overt

i just realized something: software doesn't take lot of effort and time to change because it would be difficult to make a change.

it takes lot of effort and time to change because making the change is easy, but inspecting and debugging what other things the change affects takes most of the time and effort.

it would be nice if project managers were able to wrap their head around this.

tl;dr i can make the change right now in 5 minutes, but it's going to take me an hour to check if me changing that didn't break something else.

"i can make the change right now in 5 minutes, but it's going to take me an hour to check if me changing that didn't break something else."

which is a sign of non-ideal architecture, yes. but when's the last time you encountered ideal architecture?

@Midnight-shcode Yeah, Ideally well written tests are supposed to prevent this. So if you change something they should ring bells if something is broken or has changed.

But truth be told, with every change in software, bugs that no one though of, and that no tests cover are just going to pile up until someone finds it, either a tester or an actual user... You can save some of it with good architecture but often we get changes that were simply not expected at design time so no matter how good your arch was, it's not gonna hold for long if change requests keep coming in. At least that's my experience

There is no such thing as an ideal architecture that would allow for any change to be easy. Things are not only defined by what they comprise, but as well by what they don't.

If you were to make an all-emcompassing architecture, that would be a huge shit pile of over-engineered YAGNI.

"Project Manager" - there's your problem right there. Anyone who thinks software is a series of "projects" to be completed and walked away from as opposed to being a "product" that has to be maintained and supported doesn't understand enough about software to be guiding its creation.

I mean, the thing you're looking for to fix that problem is called abstraction...

Code shouldn't depend on the detail of how something is implemented unless it's in the same class/whatever the paradigm equivalent of class is...

I think part of what I hate about Web dev is when you see mocks and assertions that some underlying library function was called so many times. That's defining implementation, and we've already got something to do that. It's called code. Tests should look at state, not implementation.

@Hazarth
"You can save some of it with good architecture but often we get changes that were simply not expected at design time so no matter how good your arch was, it's not gonna hold for long if change requests keep coming in. At least that's my experience"

same here, it's about half of the reason why the code i wrote for the current project is as shit as it is.

the other half is it being php.

the third half is me possibly never should have becoming a programmer.

(i *think* i got my fractions right)

@yowhatthefuck
i usually prefer rewriting old code - just nuking it and writing it again and better.

isn't too conducive to actually finishing stuff, though.