5 ms·

If code doesn’t receive constant love it turns to shit, I would prefer "If bad code doesn't receive constant love it turns to shit" I am aware of thousands of

by edw519 13y ago

If code doesn’t receive constant love it turns to shit, I would prefer "If bad code doesn't receive constant love it turns to shit" I am aware of thousands of examples of heavily used commercial software that hasn't been touched in 5, 10, 15, even 20 years because it just works and always has. Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric changes. But I like OP's quote. I think it should become part of every code reviewer's checklist: Will this turn to shit without constant love? No: Pass. Yes: Then fix it now.

xfax 13y ago
Properly designed and written scalable software can last indefinitely with little or no modification The problem is that what may be "proper" today (thinking, say, 5-10 years out) may fail the test in 10-15 years. One has to design software under some constraints, usually defined by the problem boundary and thus it by definition cannot be infinitely scalable and flexible. Also, the problem is the code ends up being maintained by programmers of varying levels of competency. Even if competency is not a problem, the varying styles inadvertently lead to spaghetti and inconsistent code.
kawera 13y ago
Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric changes. Daniel Bricklin wrote an interesting article[1] related to long lasting software (PDF) [1] http://changethis.com/manifesto/download/6.200YearSoftware http://changethis.com/manifesto/download/6.200YearSoftware
- JulianMorrison 13y ago
  The analogy between bridge building and software is very old and very wrong. Software can indeed be designed like a bridge, proven and then built for one unchanging use case and set in stone. And unless you are writing for NASA, soon enough that code will be junked as an obsolete millstone because use cases change. No engineer could design a bridge that might have to be rebuilt into an aircraft runway, or a 20-floor apartment complex, at a whim.
  - mason55 13y ago
    > The analogy between bridge building and software is very old and very wrong. I disagree. I think that the assumptions and use cases just change much more quickly in software than in the physical world. The covered bridges from 150 years ago were built with the assumption that they'd be used for horses, carts and people. When cars became the primary mode of transportation then those assumptions no longer held. No one would say that the original bridge was poorly built, just that the use case changed. Similarly, software that was built with the assumption that network access is slow has had its typical use case change. Software that was built to keep things on disk because RAM is expensive needed to change. Pretty soon we'll all demand that software assume that disk access is fast again because we'll move to SSDs.
eliben 13y ago
I would argue that bad code is already shit. There's no doubt that good code can be turned to shit too if it's being modified all the time with bug fixes, etc, without paying the required technical debts. Not sure what your example of untouched code represents. The OP says that what makes code turn bad is accumulated local changes and bug fixes without thinking about the big picture. Of course if no one ever touches the code, its quality doesn't change.
acqq 13y ago
It doesn't work that way. The underlying assumptions change. The program can be perfect but still not matching what becomes necessary in a few years. The example they write about is exactly such a kind. Sometime in 2007 it was apparently slow to access files from the distributed storage on Google. Therefore, a Python script was written to fetch these files to some local disks. Python was obviously enough since that process was slow. Then, another program, written in C++ was to deliver the files from the local disks to the clients. The C++ program was then "sub-optimally" maintained, simply because it wasn't on the critical path for the company. There weren't even the good test cases to verify correctness of the changes. Still, until 2013 a lot of assumptions based on which the program was written changed completely: Accessing files from the distributed storage became faster. The typical computer which is to deliver the data seems to have much more free RAM, allowing using RAM for caching purposes instead of the local hard disk. The nature of the load changed so much that accessing the local hard disk became the bottleneck anyway. Which is not so surprising: one disk seek is still around 10 ms, which means as soon as you can't deliver something from RAM you can deliver only up to 100 items from the disk per second, when they are not in the same block of data. Don't tell me you have to write the program for "all possible assumptions." Unless you have unlimited time, you write it to solve the problem under existing assumptions. Once they change, you change the implementation. Moreover, to achieve the changes related to the underlying assumptions, Go wasn't needed in the current example, but it was the most convenient approach for Brad, who is by the way obviously an extraordinary programmer. What I agree with you is that if the program is bad even under the initial assumptions, it's certainly something that should be observed and tracked by the good manager: he must know that he can't rely on such program and that whenever the program gets any heavier load, the problems will happen.
- dman 13y ago
  Not all software operates at scale. The backwards compatibility fostered by posix and wintel has meant many such applications have been silently doing their jobs for many years without (m)any changes.
  - acqq 13y ago
    Yes, when the underlying assumptions don't change and the program is already good it will remain good. The point is that the changes of the underlying assumptions can make even the once perfect program one that's suddenly unusable and it's impossible to cover all future possibilities. Targeting realistically is the only way to make the good program at the start.
raldi 13y ago
Or just deploy the half-assed solution, which will get the job done and allow your limited engineering staff to focus on higher priorities. Then, a decade later, when the company is worth hundreds of billions, you can rewrite it from scratch the proper way. See also: A Tale of Two Bridges http://hintjens.com/blog:16 http://hintjens.com/blog:16
- InclinedPlane 13y ago
  It's a good sentiment, but it doesn't usually work that way. A decade later you find that you don't just have one half-assed solution to rewrite, you have a decade's worth. And because you're spending every second of your working life maintaining that teetering pile of kludges the idea of setting aside enough time to do a proper rewrite is sheer fantasy. Certainly there is a good case to be made for accepting technical debt as a necessity in order to get products into the market and revenue coming out of the market, but on the other hand the typical software development organization tends to be drowning in technical debt. Pay down your technical debt regularly and quickly, not after a decade. For every example of the half-assed temporary solution that made the company money there is a story of development hampered by the burden of maintaining more technical debt than is wise.
  - raldi 13y ago
    > A decade later you find that you don't just have one half-assed solution to rewrite, you have a decade's worth. Whereas if you don't have a good sense of priorities, and you don't get your product out the door, a decade later your company's been dead for nine years.
    - InclinedPlane 13y ago
      Of course, but these are ends on the spectrum, it's important to find the happy medium. One of the biggest downsides of taking on a lot of technical debt is that the cost tends to be indirect and diffuse. And that's the sort of thing that organizations find it easiest to ignore. It's only when the pain becomes acute and obvious that it tends to be addressed, but by then the cost of addressing it is often several orders of magnitude higher than it would have been if it was addressed at a more appropriate time. This can cause a severe stoppage of development velocity and has doomed a sizable number of major projects and products over the years.
JulianMorrison 13y ago
What causes code to turn to shit is taking a well designed, well-factored solution, and hanging a patch off the side to make it do something new, or to fix a use case it wasn't designed to handle. The "constant love" needed is that after a change you must redesign or at least refactor. Preferably every time, or you build up a debt of work.

by edw519 13y ago

xfax 13y ago

Properly designed and written scalable software can last indefinitely with little or no modification The problem is that what may be "proper" today (thinking, say, 5-10 years out) may fail the test in 10-15 years. One has to design software under some constraints, usually defined by the problem boundary and thus it by definition cannot be infinitely scalable and flexible. Also, the problem is the code ends up being maintained by programmers of varying levels of competency. Even if competency is not a problem, the varying styles inadvertently lead to spaghetti and inconsistent code.

kawera 13y ago

Properly designed and written scalable software can last indefinitely with little or no modification, even through geometric changes. Daniel Bricklin wrote an interesting article[1] related to long lasting software (PDF) [1] http://changethis.com/manifesto/download/6.200YearSoftware http://changethis.com/manifesto/download/6.200YearSoftware

JulianMorrison 13y ago
The analogy between bridge building and software is very old and very wrong. Software can indeed be designed like a bridge, proven and then built for one unchanging use case and set in stone. And unless you are writing for NASA, soon enough that code will be junked as an obsolete millstone because use cases change. No engineer could design a bridge that might have to be rebuilt into an aircraft runway, or a 20-floor apartment complex, at a whim.
- mason55 13y ago
  > The analogy between bridge building and software is very old and very wrong. I disagree. I think that the assumptions and use cases just change much more quickly in software than in the physical world. The covered bridges from 150 years ago were built with the assumption that they'd be used for horses, carts and people. When cars became the primary mode of transportation then those assumptions no longer held. No one would say that the original bridge was poorly built, just that the use case changed. Similarly, software that was built with the assumption that network access is slow has had its typical use case change. Software that was built to keep things on disk because RAM is expensive needed to change. Pretty soon we'll all demand that software assume that disk access is fast again because we'll move to SSDs.

eliben 13y ago

I would argue that bad code is already shit. There's no doubt that good code can be turned to shit too if it's being modified all the time with bug fixes, etc, without paying the required technical debts. Not sure what your example of untouched code represents. The OP says that what makes code turn bad is accumulated local changes and bug fixes without thinking about the big picture. Of course if no one ever touches the code, its quality doesn't change.

acqq 13y ago

It doesn't work that way. The underlying assumptions change. The program can be perfect but still not matching what becomes necessary in a few years. The example they write about is exactly such a kind. Sometime in 2007 it was apparently slow to access files from the distributed storage on Google. Therefore, a Python script was written to fetch these files to some local disks. Python was obviously enough since that process was slow. Then, another program, written in C++ was to deliver the files from the local disks to the clients. The C++ program was then "sub-optimally" maintained, simply because it wasn't on the critical path for the company. There weren't even the good test cases to verify correctness of the changes. Still, until 2013 a lot of assumptions based on which the program was written changed completely: Accessing files from the distributed storage became faster. The typical computer which is to deliver the data seems to have much more free RAM, allowing using RAM for caching purposes instead of the local hard disk. The nature of the load changed so much that accessing the local hard disk became the bottleneck anyway. Which is not so surprising: one disk seek is still around 10 ms, which means as soon as you can't deliver something from RAM you can deliver only up to 100 items from the disk per second, when they are not in the same block of data. Don't tell me you have to write the program for "all possible assumptions." Unless you have unlimited time, you write it to solve the problem under existing assumptions. Once they change, you change the implementation. Moreover, to achieve the changes related to the underlying assumptions, Go wasn't needed in the current example, but it was the most convenient approach for Brad, who is by the way obviously an extraordinary programmer. What I agree with you is that if the program is bad even under the initial assumptions, it's certainly something that should be observed and tracked by the good manager: he must know that he can't rely on such program and that whenever the program gets any heavier load, the problems will happen.

dman 13y ago
Not all software operates at scale. The backwards compatibility fostered by posix and wintel has meant many such applications have been silently doing their jobs for many years without (m)any changes.
- acqq 13y ago
  Yes, when the underlying assumptions don't change and the program is already good it will remain good. The point is that the changes of the underlying assumptions can make even the once perfect program one that's suddenly unusable and it's impossible to cover all future possibilities. Targeting realistically is the only way to make the good program at the start.

raldi 13y ago

Or just deploy the half-assed solution, which will get the job done and allow your limited engineering staff to focus on higher priorities. Then, a decade later, when the company is worth hundreds of billions, you can rewrite it from scratch the proper way. See also: A Tale of Two Bridges http://hintjens.com/blog:16 http://hintjens.com/blog:16

InclinedPlane 13y ago
It's a good sentiment, but it doesn't usually work that way. A decade later you find that you don't just have one half-assed solution to rewrite, you have a decade's worth. And because you're spending every second of your working life maintaining that teetering pile of kludges the idea of setting aside enough time to do a proper rewrite is sheer fantasy. Certainly there is a good case to be made for accepting technical debt as a necessity in order to get products into the market and revenue coming out of the market, but on the other hand the typical software development organization tends to be drowning in technical debt. Pay down your technical debt regularly and quickly, not after a decade. For every example of the half-assed temporary solution that made the company money there is a story of development hampered by the burden of maintaining more technical debt than is wise.
- raldi 13y ago
  > A decade later you find that you don't just have one half-assed solution to rewrite, you have a decade's worth. Whereas if you don't have a good sense of priorities, and you don't get your product out the door, a decade later your company's been dead for nine years.
  - InclinedPlane 13y ago
    Of course, but these are ends on the spectrum, it's important to find the happy medium. One of the biggest downsides of taking on a lot of technical debt is that the cost tends to be indirect and diffuse. And that's the sort of thing that organizations find it easiest to ignore. It's only when the pain becomes acute and obvious that it tends to be addressed, but by then the cost of addressing it is often several orders of magnitude higher than it would have been if it was addressed at a more appropriate time. This can cause a severe stoppage of development velocity and has doomed a sizable number of major projects and products over the years.

JulianMorrison 13y ago

What causes code to turn to shit is taking a well designed, well-factored solution, and hanging a patch off the side to make it do something new, or to fix a use case it wasn't designed to handle. The "constant love" needed is that after a change you must redesign or at least refactor. Preferably every time, or you build up a debt of work.