3 ms·

> the industry, in my opinion, does not seem to value craftsmanship in software outside of a few niches That's because craftsmanship in software has massively

> the industry, in my opinion, does not seem to value craftsmanship in software outside of a few niches That's because craftsmanship in software has massively diminishing returns outside of a few niches. Unless you're writing some VERY highly optimized kernel code, some physics logic that makes a simulator run correctly, etc... you're writing code that gets the job done until it's replaced. A login form on a website works, until the business requirements for it change. Is it worth going back and understanding all of the fine details to make sure your changes don't break anything, or should you just rewrite it from scratch in an afternoon? This is how I feel generally about craftsmanship. There are some places where it's warranted for long term stability and incremental improvement. But the power of software lies in it's mutability (else it's better and faster in pure hardware), so the vast majority of software will break due to changing requirements or dependencies, and will be cheaper and less buggy to just replace. There's no point in finely crafting these replacements because eventually they'll suffer the same fate.

nyanpasu64 6y ago
Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up. Assembler code for old 2D game consoles is unclear, partly because it's not structured programming, partly from rushing out the door and/or generational cruft, and partly from talking to awkward hardware interfaces, and partly from optimizing performance. I've seen C code with #ifdefs to pick different code on x86 and RISC CPUs, which might've made sense as an optimization with CPUs and compilers from 15 years ago. Duff's Device is faster on older processors, but sometimes slower on new processors and compilers. From what I've heard, microservices address organizational problems more than technical ones, and dependency injection may be more useful in large enterprise projects (not sure, in my minimal experience it creates complexity). I think that all of performance, clarity, elegance, and replacability (possibly linked to modularity) are values, and software craftsmanship can encompass one or more to varying degrees.
- loup-vaillant 6y ago
  > Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up. Am I misinterpreting your comment, or did you just list 3 distinct items? 1. easily understood and simple code 2. code easily maintained and extended by corporate employees 3. fast code. In my experience, points (1) and (2) are one and the same. No tension at all. Easily understood and simple code is easily maintained and extended, by anyone. When I write code, I never try to cater to some junior idiot. I write for myself, 6 months later. Yet people who see my code often compliment how easy to read, use, and extend it is. Junior and experts alike.
MaxBarraclough 6y ago
> Unless you're writing some VERY highly optimized kernel code linguae used the word craftsmanship, which covers more than just performance. Correctness is another obvious aspect. (We still write production code that is vulnerable to buffer-overflows, for instance.) Standards-compliance is another. Wikipedia has a list that applies here. [0] This is analogous to other engineering disciplines. There's no market for supersonic civilian aircraft, but there are plenty of challenges besides speed to keep aeronautical engineers busy. Even if you're developing 'just another website', poor craftsmanship might result in downtime and loss of customer data. It might also result in longer onboarding times for new developers. The list goes on. [0] https://en.wikipedia.org/wiki/List_of_system_quality_attributes https://en.wikipedia.org/wiki/List_of_system_quality_attribu...
hnedeotes 6y ago
I personally don't agree. Even with something like a login form. If you keep on improving it with what you learn whenever you need to re-implement it or extend its requirements you end up with at least a re-usable "architecture", and most of the times you probably end up with big chunks of code that you can use, either the JS part, or html, or back-end logic. You now have a nice show/hide password field, your html is semantic, issues that were on the first quick and dirty were ironed out a bit with every iteration. > But the power of software lies in it's mutability (else it's better and faster in pure hardware) This doesn't seem at all right? The power of software lies in it doing what it's supposed to do, not introducing problems that might be costly or annoy users to the point they don't use it anymore or something better comes along and not doing what you don't expect it to do. And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it? I also think that if you can rewrite it in one afternoon, perhaps it's ok, but I doubt the things where some semblance of quality and effort matter is when whatever is the software isn't rewritable in an afternoon. > so the vast majority of software will break due to changing requirements or dependencies This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles.
- craftinator 6y ago
  > And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it? You do realize that "mutability" means "ability to be changed", correct? It's value comes from being able to be rewritten piecemeal, as opposed to hardware where you'd have to design a new PCB, manufacture it, then snail-mail it to all the places it should be, then install it. >> so the vast majority of software will break due to changing requirements or dependencies > This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles. What you said literally had nothing to do with that except you quoted from my comment.

nyanpasu64 6y ago

Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up. Assembler code for old 2D game consoles is unclear, partly because it's not structured programming, partly from rushing out the door and/or generational cruft, and partly from talking to awkward hardware interfaces, and partly from optimizing performance. I've seen C code with #ifdefs to pick different code on x86 and RISC CPUs, which might've made sense as an optimization with CPUs and compilers from 15 years ago. Duff's Device is faster on older processors, but sometimes slower on new processors and compilers. From what I've heard, microservices address organizational problems more than technical ones, and dependency injection may be more useful in large enterprise projects (not sure, in my minimal experience it creates complexity). I think that all of performance, clarity, elegance, and replacability (possibly linked to modularity) are values, and software craftsmanship can encompass one or more to varying degrees.

loup-vaillant 6y ago
> Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up. Am I misinterpreting your comment, or did you just list 3 distinct items? 1. easily understood and simple code 2. code easily maintained and extended by corporate employees 3. fast code. In my experience, points (1) and (2) are one and the same. No tension at all. Easily understood and simple code is easily maintained and extended, by anyone. When I write code, I never try to cater to some junior idiot. I write for myself, 6 months later. Yet people who see my code often compliment how easy to read, use, and extend it is. Junior and experts alike.

MaxBarraclough 6y ago

> Unless you're writing some VERY highly optimized kernel code linguae used the word craftsmanship, which covers more than just performance. Correctness is another obvious aspect. (We still write production code that is vulnerable to buffer-overflows, for instance.) Standards-compliance is another. Wikipedia has a list that applies here. [0] This is analogous to other engineering disciplines. There's no market for supersonic civilian aircraft, but there are plenty of challenges besides speed to keep aeronautical engineers busy. Even if you're developing 'just another website', poor craftsmanship might result in downtime and loss of customer data. It might also result in longer onboarding times for new developers. The list goes on. [0] https://en.wikipedia.org/wiki/List_of_system_quality_attributes https://en.wikipedia.org/wiki/List_of_system_quality_attribu...

hnedeotes 6y ago

I personally don't agree. Even with something like a login form. If you keep on improving it with what you learn whenever you need to re-implement it or extend its requirements you end up with at least a re-usable "architecture", and most of the times you probably end up with big chunks of code that you can use, either the JS part, or html, or back-end logic. You now have a nice show/hide password field, your html is semantic, issues that were on the first quick and dirty were ironed out a bit with every iteration. > But the power of software lies in it's mutability (else it's better and faster in pure hardware) This doesn't seem at all right? The power of software lies in it doing what it's supposed to do, not introducing problems that might be costly or annoy users to the point they don't use it anymore or something better comes along and not doing what you don't expect it to do. And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it? I also think that if you can rewrite it in one afternoon, perhaps it's ok, but I doubt the things where some semblance of quality and effort matter is when whatever is the software isn't rewritable in an afternoon. > so the vast majority of software will break due to changing requirements or dependencies This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles.

craftinator 6y ago
> And at the same time you're saying its value comes from mutability but then saying that it's better to rewrite it? You do realize that "mutability" means "ability to be changed", correct? It's value comes from being able to be rewritten piecemeal, as opposed to hardware where you'd have to design a new PCB, manufacture it, then snail-mail it to all the places it should be, then install it. >> so the vast majority of software will break due to changing requirements or dependencies > This also depends. Exhaustive testing for the sake of testing is not good, but a good test suite that exerts the overall functionality of your software is almost always good and allows for much faster iteration down the line and pays itself in a short amount of time or iteration cycles. What you said literally had nothing to do with that except you quoted from my comment.