3 ms·

> Yet, in practice, the cost of maintenance often dwarfs the cost of initial development. However, funding the development is sometimes harder than funding the

> Yet, in practice, the cost of maintenance often dwarfs the cost of initial development. However, funding the development is sometimes harder than funding the maintenance: You need the system to operate in the first place in order to get the benefits/money/revenue/etc. Once the system is in place and brings benefits, it is easier to fund further investment on the system, be it maintenance, extension,etc.

KillSticky 9y ago
The initial development of a chunk of code is not the same as the initial development of a shippable product. Code maintenance starts the moment you need to go back and add anything nontrivial to the existing code. And you will have to go back and change your code many times while using your initial funding. So the product funding argument, while true, does not apply here. Try reading your own code written two weeks ago. How about a month ago? Three month ago? Let's say your code is making some calls and gets back an object. Can you list all the important methods on that object from the top of your head? With a statically typed language IDE can always do that for you. If your team member added some more methods, they will be listed too. No need to waste time reading the function source to figure out the return type, and then waste more reading the class's source.
- flavio81 9y ago
  > Try reading your own code written two weeks ago. How about a month ago? Three month ago? In fact i did. Code of 8 months ago (december 2017). Easy to read, because i used named parameters extensively and added comments at every function Signature. Language Python (dynamic). Don't assume that all programmers can't understand their past code. All my peers (we have over 12 years doing this professionally) would do the same. It is part of our job to read code written even years before by us. You never know when a past customer (internal or external) will call you to want an enhancement or upgrade. > With a statically typed language IDE can always do that for you. So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. (Servers almost never have any kind of IDE or even fancy text editor installed). > And you will have to go back and change your code many times while using your initial funding. I am speaking about production software for using within an enterprise context. You have a defined budget and you need to ship a working product. For us , "maintenance" phase starts after the product has gone live in production. For us, if we deploy a working product, it is easy to get additional funding for maintenance and improvement. If we don't, we don't get subsequent funding for anything. Business will value more a slightly buggy program that is ready in 3 months than a perfect program that only is deployed after 8.
  - KillSticky 9y ago
    > So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. This is not a sound argument to advocate dynamic languages. There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns.
    - flavio81 9y ago
      Your argument was that some IDE features are really really needed. > There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns. You are doing a strawman fallacy. I never ever spoke about having or not having code reviews, and separate testing and staging environments. All of these are also necessary, and what in the world does this has to do with static typing? Testing and staging environments are required and doable using any programming language.
- Scarbutt 9y ago
  Let's say your code is making some calls and gets back an object. Can you list all the important methods on that object from the top of your head? With a statically typed language IDE can always do that for you That's really an issue with class-based programming, where you have lots of ad-hoc methods, you have identified one of the complexity it brings. You need the bloaty IDE to make that problem bearable to code in, because as you said, who is going to remember all that crap?, but it doesn't make the problem/complexity of the system go away.

KillSticky 9y ago

The initial development of a chunk of code is not the same as the initial development of a shippable product. Code maintenance starts the moment you need to go back and add anything nontrivial to the existing code. And you will have to go back and change your code many times while using your initial funding. So the product funding argument, while true, does not apply here. Try reading your own code written two weeks ago. How about a month ago? Three month ago? Let's say your code is making some calls and gets back an object. Can you list all the important methods on that object from the top of your head? With a statically typed language IDE can always do that for you. If your team member added some more methods, they will be listed too. No need to waste time reading the function source to figure out the return type, and then waste more reading the class's source.

flavio81 9y ago
> Try reading your own code written two weeks ago. How about a month ago? Three month ago? In fact i did. Code of 8 months ago (december 2017). Easy to read, because i used named parameters extensively and added comments at every function Signature. Language Python (dynamic). Don't assume that all programmers can't understand their past code. All my peers (we have over 12 years doing this professionally) would do the same. It is part of our job to read code written even years before by us. You never know when a past customer (internal or external) will call you to want an enhancement or upgrade. > With a statically typed language IDE can always do that for you. So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. (Servers almost never have any kind of IDE or even fancy text editor installed). > And you will have to go back and change your code many times while using your initial funding. I am speaking about production software for using within an enterprise context. You have a defined budget and you need to ship a working product. For us , "maintenance" phase starts after the product has gone live in production. For us, if we deploy a working product, it is easy to get additional funding for maintenance and improvement. If we don't, we don't get subsequent funding for anything. Business will value more a slightly buggy program that is ready in 3 months than a perfect program that only is deployed after 8.
- KillSticky 9y ago
  > So? Not everybody needs to use a crutch to walk. How about having to patch a live code on a running server using only a plain text editor? This is not fiction, this is real. This is not a sound argument to advocate dynamic languages. There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns.
  - flavio81 9y ago
    Your argument was that some IDE features are really really needed. > There are good reasons industry best practices include things like code reviews, testing, and staging environments. But I suppose, if you are going to ignore all of these, then the lack of type safety is the least of your concerns. You are doing a strawman fallacy. I never ever spoke about having or not having code reviews, and separate testing and staging environments. All of these are also necessary, and what in the world does this has to do with static typing? Testing and staging environments are required and doable using any programming language.
Scarbutt 9y ago
Let's say your code is making some calls and gets back an object. Can you list all the important methods on that object from the top of your head? With a statically typed language IDE can always do that for you That's really an issue with class-based programming, where you have lots of ad-hoc methods, you have identified one of the complexity it brings. You need the bloaty IDE to make that problem bearable to code in, because as you said, who is going to remember all that crap?, but it doesn't make the problem/complexity of the system go away.