3 ms·

"maintaining LARGE applications" And that is very poor software engineering. You should be breaking down those large applications into smaller more maintainabl

"maintaining LARGE applications" And that is very poor software engineering. You should be breaking down those large applications into smaller more maintainable micro-services. It's bad really bad. "compile-time support for validating assumptions" Bad software development again. If you are checking assumptions at compile time then you are slowing down your software development iteration loop. It's the 4 hour compile time problem from C++ revisited. "over significant periods of time" Bad, really bad software development again. As business requirements change over the life-time of a software project, you need to retire and replace old code with new code that better meets the changing business needs. Static typing is useful for performance reasons but that doesn't apply in a scripting language. In pretty much every other context it's terrible.

macspoofing 3y ago
I can't tell if this is a troll post or not. >You should be breaking down those large applications into smaller more maintainable micro-services. This take ... I'm not even sure where to start: 1. Everything I said applies equally to microservices as it does to monoliths. 2. You must have never worked with microservices if you think they are a panacea. 3. What is the difference between the same amount of code but split between one monolith versus many microservices? >It's the 4 hour compile time problem from C++ revisited. Do you know what's even more expensive? Tracking down TypeErrors at Runtime. > As business requirements change over the life-time of a software project, you need to retire and replace old code with new code that better meets the changing business needs. Yes .. keep rewriting working code - that's a path to success.
- ReflectedImage 3y ago
  "What is the difference between the same amount of code but split between one monolith versus many microservices" Encapsulation at a larger grain level. "Yes .. keep rewriting working code - that's a path to success." If you had done any courses on software requirements, you wouldn't be saying that. It's the entire premise behind agile software development.
  - macspoofing 3y ago
    > If you had done any courses on software requirements, you wouldn't be saying that. It's the entire premise behind agile software development. Oh really? Twenty years of professional experience say otherwise. I don't remember if that came up in either my graduate or undergraduate classes, but I also remember this post going around: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... - in my experience, this post is as true as it ever way. Sometimes a ground-up rewrite is necessary, but more often than not, you do it at your own peril. >Encapsulation at a larger grain level. Encapsulation has nothing to do with it. The value of compile-time support rises as LOC and complexity goes up - this is irrespective of your development methodology, or the architecture of your stack. >It's the entire premise behind agile software development. No. It's not. Agile does not directly address code maintenance or code quality since Agile is (as Wikipedia puts it) "an iterative development process". You can perfectly follow Agile, and turn out unmaintenable code.

macspoofing 3y ago

I can't tell if this is a troll post or not. >You should be breaking down those large applications into smaller more maintainable micro-services. This take ... I'm not even sure where to start: 1. Everything I said applies equally to microservices as it does to monoliths. 2. You must have never worked with microservices if you think they are a panacea. 3. What is the difference between the same amount of code but split between one monolith versus many microservices? >It's the 4 hour compile time problem from C++ revisited. Do you know what's even more expensive? Tracking down TypeErrors at Runtime. > As business requirements change over the life-time of a software project, you need to retire and replace old code with new code that better meets the changing business needs. Yes .. keep rewriting working code - that's a path to success.

ReflectedImage 3y ago
"What is the difference between the same amount of code but split between one monolith versus many microservices" Encapsulation at a larger grain level. "Yes .. keep rewriting working code - that's a path to success." If you had done any courses on software requirements, you wouldn't be saying that. It's the entire premise behind agile software development.
- macspoofing 3y ago
  > If you had done any courses on software requirements, you wouldn't be saying that. It's the entire premise behind agile software development. Oh really? Twenty years of professional experience say otherwise. I don't remember if that came up in either my graduate or undergraduate classes, but I also remember this post going around: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... - in my experience, this post is as true as it ever way. Sometimes a ground-up rewrite is necessary, but more often than not, you do it at your own peril. >Encapsulation at a larger grain level. Encapsulation has nothing to do with it. The value of compile-time support rises as LOC and complexity goes up - this is irrespective of your development methodology, or the architecture of your stack. >It's the entire premise behind agile software development. No. It's not. Agile does not directly address code maintenance or code quality since Agile is (as Wikipedia puts it) "an iterative development process". You can perfectly follow Agile, and turn out unmaintenable code.