4 ms·

> For any code base that isn't a throwaway like a one-off script or similar, say 10 or 20 years maintenance I think one of our problems is that people have dow

by zmmmmm 9y ago

> For any code base that isn't a throwaway like a one-off script or similar, say 10 or 20 years maintenance I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. It is a natural assumption when you see the deluge of new technologies, hype cycles, etc. It is further reinforced by the fact that people's empirical experience is that a huge amount of their software work is abandoned, rewritten, outdated, obsoleted, etc. I think these views are horribly mistaken, because at a deeper level even if 90% of code gets abandoned, the quality of the 10% that survives is still going to determine your maintenance cost. And half the reason we keep throwing code away is because it was created without consciousness of maintainability - it is so easy to say that the last person's code was garbage, so we are going to rewrite it because that is faster than understanding and then fixing the bugs in what they wrote. I observe this in myself: my favorite language to code in is Groovy - a dynamic, scripting language with all kinds of fancy tricks. But my favorite language to decode is Java. Because it is so simple, boring, there is almost nothing clever it can do. Every type declared, exception thrown, etc. is completely visible in front of me.

jugg1es 9y ago
In my experience with growing companies, even compay-critical code bases get rewritten within 3-4 years to account for flexibility that the previous strongly-typed system just can't handle. A well designed system uses strong types for the "knowns" but allows changes via dynamic types for the "unknowns". Those are the systems that last.
deepGem 9y ago
And half the reason we keep throwing code away is because it was created without consciousness of maintainability. Well, this has nothing to do with static vs dynamic typing. You can write unmaintainable code in static languages very easily. In startups, developers often overlook maintainability, I completely agree but that's because everyone knows that the code you are writing today might not be needed 2 years down the line, you are mostly iterating to find PMF.
- danmaz74 9y ago
  It's also caused by the fact that nowadays a lot (most?) of the code that gets written is for the web or mobile, where technology changes incredibly fast.
- zmmmmm 9y ago
  It's not totally divorced from the static vs dynamic argument. One of the main arguments people deploy for dynamic typing is that most type declarations are boilerplate and take time to code but don't add any value. But the reality is that they do add value because they enhance the readability and maintainability of the code (and this is one reason I'm not even a great fan of type inference in many situations). So it comes back to the value of maintainability vs getting your first iteration of the code to work.
falsedan 9y ago
> people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible Well, most code is written by relatively-inexperience developers, who have not had to retire a system or support a legacy one, and don't know what should be sought out & what should be avoided when designing a system. Thus, they make decisions with limited information to solve the problem at hand, and only later find out the implications of those decisions when someone wants to (say) deploy it as a dockerized service on k8s. It's one thing to read The Mythical Man Month, and another to write a replacement system that stops providing business value after 30 months and needs to be rewritten to support the current needs. > it is so easy to say that the last person's code was garbage, so we are going to rewrite it because that is faster than understanding and then fixing the bugs in what they wrote There's no black and white answer here: sometimes the code is so convoluted (or in the wrong language) that it has to be rewritten; sometimes the design of the system strongly resists changes in behaviour & so much of it needs to be made more flexible that an incremental improvement would cost about the same as a full rewrite.
arthur_pryor 9y ago
> I observe this in myself: my favorite language to code in is Groovy - a dynamic, scripting language with all kinds of fancy tricks. But my favorite language to decode is Java. Because it is so simple, boring, there is almost nothing clever it can do. Every type declared, exception thrown, etc. is completely visible in front of me. one of my favorite things about groovy is that it's easy to start strongly typing things as your code shapes up, because it allows for totally dynamic types, but it also allows for strong static typing. haven't really had the chance to use groovy since 2012, though.
- vorg 9y ago
  Static typing was grafted onto Apache Groovy in 2012, but no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy. Groovy's still great for scripting on the JVM though, for stuff like those 10-liner build scripts for Gradle, glue code, and mock testing. Just don't use Groovy for building systems -- use a language based on static typing from the ground up, like Java, Scala, or Kotlin.
  - zmmmmm 9y ago
    > Static typing ... no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy You keep saying this repeatedly but it just isn't true: https://github.com/grails/grails-core/blob/master/grails-core/src/main/groovy/org/grails/core/MetaGrailsDomainClassProperty.groovy https://github.com/grails/grails-core/blob/master/grails-cor... https://github.com/groovy/groovy-core/blob/master/src/main/groovy/util/FileTreeBuilder.groovy https://github.com/groovy/groovy-core/blob/master/src/main/g...
    - vorg 9y ago
      Both your examples use very simple logic. The Apache Groovy codebase example is of some peripheral functionality, i.e. a builder. All the methods in your Grails codebase example are, at most, 1 line long. I can't be bothered re-investigating what proportion of the core Groovy codebase really uses static compilation -- it certainly wasn't much only 2 years ago. As for Grails, virtually no-one has upgraded from v.2 to Grails 3 since it was released 2.5 yrs ago, or started many new projects with it.
jamaicahest 9y ago
>I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. I think younger devs think this. Once you get a decade or more experience, you grow wiser and realise that code never dies, and especially the code you wish would die is particularly tenacious. And this is pure speculation, but I would wager that the number of lines of legacy code that is kept alive with maintenance is much greater than the number of lines of code that gets abandoned/rewritten/obsoleted.

by zmmmmm 9y ago

jugg1es 9y ago

In my experience with growing companies, even compay-critical code bases get rewritten within 3-4 years to account for flexibility that the previous strongly-typed system just can't handle. A well designed system uses strong types for the "knowns" but allows changes via dynamic types for the "unknowns". Those are the systems that last.

deepGem 9y ago

And half the reason we keep throwing code away is because it was created without consciousness of maintainability. Well, this has nothing to do with static vs dynamic typing. You can write unmaintainable code in static languages very easily. In startups, developers often overlook maintainability, I completely agree but that's because everyone knows that the code you are writing today might not be needed 2 years down the line, you are mostly iterating to find PMF.

danmaz74 9y ago
It's also caused by the fact that nowadays a lot (most?) of the code that gets written is for the web or mobile, where technology changes incredibly fast.
zmmmmm 9y ago
It's not totally divorced from the static vs dynamic argument. One of the main arguments people deploy for dynamic typing is that most type declarations are boilerplate and take time to code but don't add any value. But the reality is that they do add value because they enhance the readability and maintainability of the code (and this is one reason I'm not even a great fan of type inference in many situations). So it comes back to the value of maintainability vs getting your first iteration of the code to work.

falsedan 9y ago

> people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible Well, most code is written by relatively-inexperience developers, who have not had to retire a system or support a legacy one, and don't know what should be sought out & what should be avoided when designing a system. Thus, they make decisions with limited information to solve the problem at hand, and only later find out the implications of those decisions when someone wants to (say) deploy it as a dockerized service on k8s. It's one thing to read The Mythical Man Month, and another to write a replacement system that stops providing business value after 30 months and needs to be rewritten to support the current needs. > it is so easy to say that the last person's code was garbage, so we are going to rewrite it because that is faster than understanding and then fixing the bugs in what they wrote There's no black and white answer here: sometimes the code is so convoluted (or in the wrong language) that it has to be rewritten; sometimes the design of the system strongly resists changes in behaviour & so much of it needs to be made more flexible that an incremental improvement would cost about the same as a full rewrite.

arthur_pryor 9y ago

> I observe this in myself: my favorite language to code in is Groovy - a dynamic, scripting language with all kinds of fancy tricks. But my favorite language to decode is Java. Because it is so simple, boring, there is almost nothing clever it can do. Every type declared, exception thrown, etc. is completely visible in front of me. one of my favorite things about groovy is that it's easy to start strongly typing things as your code shapes up, because it allows for totally dynamic types, but it also allows for strong static typing. haven't really had the chance to use groovy since 2012, though.

vorg 9y ago
Static typing was grafted onto Apache Groovy in 2012, but no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy. Groovy's still great for scripting on the JVM though, for stuff like those 10-liner build scripts for Gradle, glue code, and mock testing. Just don't use Groovy for building systems -- use a language based on static typing from the ground up, like Java, Scala, or Kotlin.
- zmmmmm 9y ago
  > Static typing ... no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy You keep saying this repeatedly but it just isn't true: https://github.com/grails/grails-core/blob/master/grails-core/src/main/groovy/org/grails/core/MetaGrailsDomainClassProperty.groovy https://github.com/grails/grails-core/blob/master/grails-cor... https://github.com/groovy/groovy-core/blob/master/src/main/groovy/util/FileTreeBuilder.groovy https://github.com/groovy/groovy-core/blob/master/src/main/g...
  - vorg 9y ago
    Both your examples use very simple logic. The Apache Groovy codebase example is of some peripheral functionality, i.e. a builder. All the methods in your Grails codebase example are, at most, 1 line long. I can't be bothered re-investigating what proportion of the core Groovy codebase really uses static compilation -- it certainly wasn't much only 2 years ago. As for Grails, virtually no-one has upgraded from v.2 to Grails 3 since it was released 2.5 yrs ago, or started many new projects with it.

jamaicahest 9y ago

>I think one of our problems is that people have downgraded the importance of this. Much code nowadays (rightly or wrongly) is considered "disposable" - people think that the likelihood of any given piece of code they are writing as surviving more than a few years is negligible. I think younger devs think this. Once you get a decade or more experience, you grow wiser and realise that code never dies, and especially the code you wish would die is particularly tenacious. And this is pure speculation, but I would wager that the number of lines of legacy code that is kept alive with maintenance is much greater than the number of lines of code that gets abandoned/rewritten/obsoleted.