4 ms·

I disagree. There's a realm of fields to which software engineering applies. There's fields where correctness, elegance and formal methods definitely matter; th

by crdb 11y ago

I disagree. There's a realm of fields to which software engineering applies. There's fields where correctness, elegance and formal methods definitely matter; those involve complex products like airplanes (RIP, A400 victims...) or nuclear plant control systems. Or academia, which cannot progress with imprecise thinking. You can't run Facebook's operations the way you'd run a bakery's website's. But then there are heaps more fields where correctness absolutely does not matter, where a shiny cover over an awful spaghetti ball is enough, where you can lose half the client's data and say "sorry, crash" and he'll just nod and shrug, and where this is a lot cheaper and faster than hiring a professional and doing things properly, where the determinant of success is not the engineer, but the management team, their connections, and the sheer amounts of money that investors are willing to pump into the company to win the market (money they will mostly give only to the first competent person that pitches them the idea, giving the pretty-"MVP"-in-a-week team the edge over the formals). It's a trade-off between time and cost to market, and product quality; it won't change until the second way beats the first on the first two dimensions as well as the last.

romaniv 11y ago
The problem is that software usually moves from the first realm to the second realm over time.
- AnimalMuppet 11y ago
  True. Very true. But if you don't let it start in the first realm, then most of the time, there's nothing created, so there's nothing to move to the second realm.
- crdb 11y ago
  Yes, but when this happens, the company can usually afford to hire thousands of engineers and brute force the issue, or the product is unpopular and in the process of disappearing. Exceptions (like Whatsapp) are legendary for the concentration of wealth in the hands of a few engineers that follows success.
AnimalMuppet 11y ago
And what's ironic is that EWD's preferred approach actually increases the cost of (at least the first version of) many pieces of software. And his article was "Why Software Is So Expensive". I mean, his approach would have prevented Microsoft from ever existing. Or Linux. Or Apple. Which means we never would have had the PC revolution. We would just have a software industry that produced software right, and code that didn't crash, but we'd have maybe 1/100th of the software industry that we have. We'd miss 99% of what computers have brought us. I'm not willing to make that trade-off to get software that never breaks, even though I hate it when software breaks.
- crdb 11y ago
  I'm not sure one could describe Microsoft as "fast and dirty". Gates' BASIC interpreter is a famous example of technical ability...
  - AnimalMuppet 11y ago
    But Dijkstra would oppose Gates' BASIC interpreter, because it wasn't built using Dijkstra's approach of mathematical reasoning, and therefore couldn't be trustworthy.
- vezzy-fnord 11y ago
  I mean, his approach would have prevented Microsoft from ever existing. Or Linux. Or Apple. Which means we never would have had the PC revolution. In an alternate continuity where Dijkstra's methods prevailed, other companies and products would have arisen instead, or perhaps the same but under different circumstances. There is no reason to believe the PC revolution would have never occurred, as that was largely a result of commodity hardware (where QC is much more stringent than in software). The software would have been written anyway, but it might have been less bad. We'd miss 99% of what computers have brought us. Strictly speaking, no. The quantity of software might have been less, but the quality and thus the actual features would have been either the same in aggregate, or, as intended, far more progressive and in line with the academic state of the art.
  - 11y ago
mercer 11y ago
The fact that software engineering applies to so many fields is exactly the reason why I often find it problematic when it's treated as 'one thing' in a discussion. While the process of writing software looks deceptively uniform (files with code), the purpose of said software can be anything in reality (and it can even be used to create an entire virtual representation of (a) reality). Perhaps 'software' is too broad a concept to discuss without qualifiers? It's a bit like lumping together essayists, lawyers, analysts, journalists, poets, novelists, philosophers, etc. under the label 'writers', and then try to have a meaningful discussion about hiring practices, writing standards and writing tools. This doesn't really make, as the requirements of a junior reporter are quite different from those of a junior lawyer. The fact that they both write words on paper doesn't change that. I suppose they could discuss the quality of different pens. Our equivalent to that might be code editors...
tikhonj 11y ago
It's really not clear that the spaghetti code approach is better time-wise over anything but the immediate short term. In my experience, any advantages fall away once you get out of hackathon territory—a matter of weeks, not months. At a point, even if absolute correctness is not important, you just spend so much less time debugging your old code and it takes so much less effort to add new features (ie less need to rewrite or extend old code to support the new) that you end up producing more overall. The problem is that these improvements are non-local. Yes, over a month, you might get more done per day if you slow down and write less hacky code—but it won't help you get your thing out today. In the short term, it feels like you're always more productive being hacky because, day to day, you get specific things done faster… but, over the long term (or even the medium term!), you're actually less productive. The human mind is not great at accounting for time and effort. This is exacerbated significantly by tight deadlines and constant pressure. And the sort of companies that have those problems also tend to overwork their engineers, which has exactly the same sort of non-local consequences. (If you work 80 hours this week, you will get more done than you would have. And the same is true next week, and the week after—but your base productivity is falling so, after a few months, you will be less productive in absolute terms!¹) These local improvements are very tempting—and sometimes they're actually justified! There are definitely scripts and programs that only matter in the immediate short term, and you shouldn't worry about making them elegant. But people apply this far to widely. If your program will matter in the medium term—if you're going to be iterating on it over multiple weeks—it's probably worth maintaining a bit of discipline throughout and writing more elegant, maintainable and readable code. ¹ I remember seeing a pretty compelling study about how long work weeks affect absolute productivity, but I can't find it at the moment.
- crdb 11y ago
  Oh, I agree with you entirely. Let me reword/summarize my comment: there's r-strategists and K-strategists. It's usually better in most relationships to be with K-strategists. Where I disagree with Djisktra is in the idea of a world without r-strategists; not because it's not desirable, but because it's highly unlikely.
  - sanderjd 11y ago
markbnj 11y ago
Hmm, I'm not sure we disagree. I think you're looking at a larger picture. I think the scope of most software was somewhat narrower at the time these opinions were formed, and I believe in his mind Dijkstra was thinking about the structure of individual programs more so than the architecture of systems or technology based business. This strikes a chord with me because I was thinking just other day about the fast vs. good trade-off, and I have come to the conclusion that "fast" doesn't mean poor quality. It means, or should mean, that you build fewer pieces, attempt fewer features, but the individual components that you do build are still well structured, well-designed, well-implemented, and don't close off avenues of evolution as the business scales. In other words, for me he is saying that code must always be written well, as simply and as elegantly as possible. You still retain the freedom to choose how much to write.

by crdb 11y ago

romaniv 11y ago

The problem is that software usually moves from the first realm to the second realm over time.

AnimalMuppet 11y ago
True. Very true. But if you don't let it start in the first realm, then most of the time, there's nothing created, so there's nothing to move to the second realm.
crdb 11y ago
Yes, but when this happens, the company can usually afford to hire thousands of engineers and brute force the issue, or the product is unpopular and in the process of disappearing. Exceptions (like Whatsapp) are legendary for the concentration of wealth in the hands of a few engineers that follows success.

AnimalMuppet 11y ago

And what's ironic is that EWD's preferred approach actually increases the cost of (at least the first version of) many pieces of software. And his article was "Why Software Is So Expensive". I mean, his approach would have prevented Microsoft from ever existing. Or Linux. Or Apple. Which means we never would have had the PC revolution. We would just have a software industry that produced software right, and code that didn't crash, but we'd have maybe 1/100th of the software industry that we have. We'd miss 99% of what computers have brought us. I'm not willing to make that trade-off to get software that never breaks, even though I hate it when software breaks.

crdb 11y ago
I'm not sure one could describe Microsoft as "fast and dirty". Gates' BASIC interpreter is a famous example of technical ability...
- AnimalMuppet 11y ago
  But Dijkstra would oppose Gates' BASIC interpreter, because it wasn't built using Dijkstra's approach of mathematical reasoning, and therefore couldn't be trustworthy.
vezzy-fnord 11y ago
I mean, his approach would have prevented Microsoft from ever existing. Or Linux. Or Apple. Which means we never would have had the PC revolution. In an alternate continuity where Dijkstra's methods prevailed, other companies and products would have arisen instead, or perhaps the same but under different circumstances. There is no reason to believe the PC revolution would have never occurred, as that was largely a result of commodity hardware (where QC is much more stringent than in software). The software would have been written anyway, but it might have been less bad. We'd miss 99% of what computers have brought us. Strictly speaking, no. The quantity of software might have been less, but the quality and thus the actual features would have been either the same in aggregate, or, as intended, far more progressive and in line with the academic state of the art.
- 11y ago

mercer 11y ago

The fact that software engineering applies to so many fields is exactly the reason why I often find it problematic when it's treated as 'one thing' in a discussion. While the process of writing software looks deceptively uniform (files with code), the purpose of said software can be anything in reality (and it can even be used to create an entire virtual representation of (a) reality). Perhaps 'software' is too broad a concept to discuss without qualifiers? It's a bit like lumping together essayists, lawyers, analysts, journalists, poets, novelists, philosophers, etc. under the label 'writers', and then try to have a meaningful discussion about hiring practices, writing standards and writing tools. This doesn't really make, as the requirements of a junior reporter are quite different from those of a junior lawyer. The fact that they both write words on paper doesn't change that. I suppose they could discuss the quality of different pens. Our equivalent to that might be code editors...

tikhonj 11y ago

It's really not clear that the spaghetti code approach is better time-wise over anything but the immediate short term. In my experience, any advantages fall away once you get out of hackathon territory—a matter of weeks, not months. At a point, even if absolute correctness is not important, you just spend so much less time debugging your old code and it takes so much less effort to add new features (ie less need to rewrite or extend old code to support the new) that you end up producing more overall. The problem is that these improvements are non-local. Yes, over a month, you might get more done per day if you slow down and write less hacky code—but it won't help you get your thing out today. In the short term, it feels like you're always more productive being hacky because, day to day, you get specific things done faster… but, over the long term (or even the medium term!), you're actually less productive. The human mind is not great at accounting for time and effort. This is exacerbated significantly by tight deadlines and constant pressure. And the sort of companies that have those problems also tend to overwork their engineers, which has exactly the same sort of non-local consequences. (If you work 80 hours this week, you will get more done than you would have. And the same is true next week, and the week after—but your base productivity is falling so, after a few months, you will be less productive in absolute terms!¹) These local improvements are very tempting—and sometimes they're actually justified! There are definitely scripts and programs that only matter in the immediate short term, and you shouldn't worry about making them elegant. But people apply this far to widely. If your program will matter in the medium term—if you're going to be iterating on it over multiple weeks—it's probably worth maintaining a bit of discipline throughout and writing more elegant, maintainable and readable code. ¹ I remember seeing a pretty compelling study about how long work weeks affect absolute productivity, but I can't find it at the moment.

crdb 11y ago
Oh, I agree with you entirely. Let me reword/summarize my comment: there's r-strategists and K-strategists. It's usually better in most relationships to be with K-strategists. Where I disagree with Djisktra is in the idea of a world without r-strategists; not because it's not desirable, but because it's highly unlikely.
- sanderjd 11y ago

markbnj 11y ago

Hmm, I'm not sure we disagree. I think you're looking at a larger picture. I think the scope of most software was somewhat narrower at the time these opinions were formed, and I believe in his mind Dijkstra was thinking about the structure of individual programs more so than the architecture of systems or technology based business. This strikes a chord with me because I was thinking just other day about the fast vs. good trade-off, and I have come to the conclusion that "fast" doesn't mean poor quality. It means, or should mean, that you build fewer pieces, attempt fewer features, but the individual components that you do build are still well structured, well-designed, well-implemented, and don't close off avenues of evolution as the business scales. In other words, for me he is saying that code must always be written well, as simply and as elegantly as possible. You still retain the freedom to choose how much to write.