10 ms·

I used to love these kinds of articles three decades ago. Then you get a programming job with budgets and deadlines and even stupid decisions based on politics

I used to love these kinds of articles three decades ago. Then you get a programming job with budgets and deadlines and even stupid decisions based on politics and you hate all that at first until through experience you realize that even poorly engineered cars can get product from point a to point b and do so all over the world. Free markets eventually only have time for perfect solutions. And a perfect solution according to markets is the solution that does the job for the lowest cost over time. For a website that will support a two week marketing campaign, you don't need anything talked about in this article. In fact the only responsible decision is to ignore this type of approach and just build the damn thing with someone that has a track record. And then throw it out and move on. Based on empirical evidence, there isn't really a problem at all with the way people program. Markets have already mostly figured out the rare cases when such robustness is really needed. And it's rare. The only "right" way to program is to take as many stakeholder requirements into consideration as possible. And those requirements are rarely around program correctness. So this article is good (although I think you're really looking at functional programming by this time in history) but first make sure a top priority is program correctness before getting into the mode suggested by the article. One final stakeholder requirement that's always a priority: you have to be able to find qualified developers, and what developers learn is based on popularity and fashion. It's a real world constraint even if it's distasteful to the idealist and well intentioned types who write these articles.

kbenson 8y ago
> And a perfect solution according to markets is the solution that does the job for the lowest cost over time. Yep. If we actually valued correctness, the market would place some cost on incorrectness. Security is a common example of this. If we wanted, we could punish software developers or publishers for shipping security bugs (for example, making them liable), and then we would see an immediate shift in how software was written. That's not necessarily an endorsement of that position (it lacks enough nuance to even be remotely considered a good idea), it's just a fairly illustrative example.
- blub 8y ago
  The market can't solve solve the quality problem, that's a fantasy. Sw quality is so poor across the board that there is almost no one producing high quality, reliable software. My bloody phone can't properly select text in this box for example. Sw companies have optimised their production for decades to develop software that's just good enough to ensure profit and they've trained customers to expect and accept poor quality. Is anyone surprised when Windows reboots for updates in the middle of an important presentation? No, that's how Windows works. Companies will even reduce quality to improve profits and still get away with it if the customers don't notice, don't understand or are too apathetic to take action. Often there is no action to take that will sufficiently punish the offending company. Security is a great example: it's been bad for so long that core pieces of technology are fundamentally insecure and can't be significantly improved without total rewrites. Punishing developers and companies would result in a collapse of commercial software development, so humanity collectively accepts that software is by nature insecure.
jacquesm 8y ago
And then, five years after you've left the company and some system inevitably collapses with nobody having a clue as to what went wrong you'd finally realize the wisdom of all that. But it's no longer your problem. So, please don't take it personal, but 'the well intentioned types who write these articles' tend to be the people that then get called in to clean up the mess. And then - belatedly - the job gets done properly to keep the company in business, assuming there is still time enough to do so. Just this week I had a nice inside look at the kind of mess gets left behind when the original duct-tape-and-spit guy leaves the company and lets his former co-workers clean up their mess. It isn't pretty, and a chapter 11 isn't an unlikely scenario, so forgive me if I take a harsher than usual look at the attitude that causes this sort of thing. Note that the 'free market' doesn't have a horizon much longer than the next quarterly shareholder report, and that your typical software product lives a multiple of that interval. So software made with short term goals in mind will create long term headaches. Your two week marketing campaign gets a pass. But your decade long backend project does not, nor does your real time medical device controller, ECU, database system or operating system.
- tchaffee 8y ago
  > And then, five years after you've left the company and some system inevitably collapses with nobody having a clue as to what went wrong you'd finally realize the wisdom of all that. But it's no longer your problem. If that were a problem in reality, the markets would be punishing companies where that happens. It's not a real problem that that happens. Management pretends to be upset, but in reality it's not a huge deal. Entropy is normal in apps and everything else. To continue the analogy from my original comment, do companies really go into crisis mode when one of the many cars in their fleet inevitably "collapses"? No. They build or buy a new one and life goes on. > nor does your real time medical device controller, ECU, database system or operating system. Yep. Those are the rare cases I talked about. It's a tiny fraction of total programmers building databases and stuff like that.
  - minor3rd 8y ago
    I agree with you whole-heartedly. My programming career has gone from "I don't know the best way to write something", to "I know the best way to write something and I'll do it this way every time", to "often it doesn't fucking matter, just get it done and move along to the next problem".
TeMPOraL 8y ago
I suppose - and this applies generally, not just to programming - people (myself included) don't exactly like market's idea of "perfect". Because free-market perfect isn't just nice-sounding "solution that does the job for the lowest cost over time" - it's the borderline cheapest, ugliest, worst solution that's only barely fit for its purpose, and if it was any worse, it would be unsellable. It's aiming for the absolute lower bound - as any possible way to make it cheaper is taken. The problems with market!perfection are many - mostly resolving around short-term optimization, externalities and lack of alignment between market values and human values. But we have brains that can be used to get better outcome than what the market incentivizes by default.
- kbenson 8y ago
  > The problems with market!perfection are many - mostly resolving around short-term optimization, externalities Almost all bugs, security of otherwise, are just negative externalities. I think the public has been conditioned to accept that software not only comes with bugs, but many of them, and there's nothing that can be done about it. Companies/developers/publishers are not penalized much at all for buggy software, so much so that it's a common business tactic to deliver crappy software that doesn't even accomplish what it states it does, much less bug free and without security problems, with the understanding that it can be fixed up after delivery with little negative consequences.
- perl4ever 8y ago
  I don't think that's correct. You're describing the marginal solution that the market produces, not the average solution. And because demands are always changing, the market never converges on that optimum you are presenting as a bogeyman. It's not realistic any more than all profits being competed away to zero.
  - TeMPOraL 8y ago
    Yes, I've described the solution in the limit, in the same sense a physicist could write: lim t -> ∞ ... A limit doesn't itself happen in real life, but shows you where a system is going. As for a proof that this is happening, there are plenty of examples if you look at the highly competitive spaces and consider goods you usually buy, and how they evolved over past decades. Food and tools are two obvious cases that come to mind.
zzzcpan 8y ago
> but first make sure a top priority is program correctness That's the thing, this doesn't happen in real world and it is questionable if the concept of correctness is useful at all. As it is based on unvalidated and incomplete assumptions about the world, never fully correct themselves. Sort of correctness of incorrectness.
- TooBrokeToBeg 8y ago
  People don't even think consistently, so correctness is an ever-moving target (aka a negotiation).
- perl4ever 8y ago
  Case in point: from reading discussions about the C standard, my impression is that a compliant compiler is "correct" if it reads your program that dereferences a null pointer and blows up the world.
  - TeMPOraL 8y ago
    If a null pointer handler in a nuclear warhead firmware caused immediate detonation, that would certainly be correct according to C standard ;).
- mopierotti 8y ago
  Correctness can just mean "does what it's intended to do". This is fairly unambiguous in cases such as if you intend to implement A* Search. If you hit a NPE and your program explodes, or if you aren't calling your heuristic (central to A*), then you have skimped on correctness. Furthermore, basically any time you hit something like a runtime error you likely did not intend to hit it. Therefore, regardless of problem domain, taking approaches that minimize these types of errors is an uncontroversial way that correctness can be prioritized.
lisper 8y ago
> One final stakeholder requirement that's always a priority: you have to be able to find qualified developers, and what developers learn is based on popularity and fashion. But popularity and fashion are not disembodied forces controlled by the whims of the gods. They are the sum total of decisions made by people. We could make different choices, but the belief that this is futile is a self-fulfilling prophecy.
- tchaffee 8y ago
  How could we make different choices? These choices are rarely made by developers unless it's their own startup. For most IT jobs these kinds of decisions are made by upper management who have to answer to a board of directors, and ultimately to shareholders. No one ever got fired for using Java. (I personally quit C++ and Java many years ago because I thought both were a bit of a mess. Maybe things have improved with Java - I haven't followed it much). Upper IT management can't just say "we're switching to Haskell because fewer bugs". They have to sell the idea to the folks who will pay for those massive changes which include retraining existing employees. And management does take into consideration how big the hiring pool is. That affects costs. A surge in demand for Haskell programmers would of course create a higher cost for hiring and keeping them. So they continue to hire Java programmers and students graduating from uni make sure they know Java. Where is the opportunity for us to make different choices? Should students refuse jobs in Java? Or without picking on a language, jobs at companies that have the highest software quality standards? That's a lot of idealism and responsibility to ask of someone whose is just hoping they can get a foot in the door and start their career. Or is there someone else you have in mind that could be making different choices? It does seem like my own personal choice to give up on Java has had zero effect on its popularity. There is far more at play than the "the belief that this is futile is a self-fulfilling prophecy" although I agree that too is a factor. I do have hope though. One thing I've seen happen is more and more programmers who were introduced to functional programming at uni and who manage to sneak ideas from that in wherever they can. I think we are slowly moving away from the worst parts of the object oriented paradigm and adopting the easier and better parts of functional programming. I'm looking forward to see what we end up with. So far, I think the evolution has headed in the right direction and we are getting better and better at this thing we call coding.
westoncb 8y ago
I've been thinking on similar lines for a while. It seems like the number one thing it comes down to is that more deep thought is required for a number of these 'obviously better' techniques (I think they generally come down to being more declarative than imperative, saying how the results should look instead of describing how to get them). So lots of people are inclined to say things like, "then don't be lazy, do the work and think deeply"—but for one thing, 'deep thought' should be considered as a conserved resource and you have to choose what to spend it on (it's not automatically better to always spend it); and for another, I think the actual depth required for perhaps the majority of real-life problem domains is impractical, or perhaps sometimes the domain is even fundamentally not amenable to an elegant mathematical solution. So you have to contort the 'better' language to do inelegant things it's not really suited for anyway. I think the constraints on the 'triples_from' structure from the article is a bit misleading and makes a good example of what I'm talking about. It looks super simple, but if you note how this constraint across tf.item as tp all tp.item.source = tf.cursor_index end is actually working, it's not so much that the language gives a particularly elegant/powerful means of specifying these constraints as it is that 'triples_from' was structured in such a way that it would be easy to specify the constraint. My feeling is that trying to do this for real-life things would rarely ever be so neat. If the domain you're modeling has mathematical elegance to begin with—absolutely, do the deep thought and uncover the invariants. But if it doesn't, then you'd be 'programming wrong' by trying to use such techniques. The alternative I've been thinking about is just developing far more powerful/pervasive visualization tools so that you can write relatively mindless imperative code and just see where things are going wrong more easily. (consider the author's example of multiple data structures which must be kept in sync, but it's hard to tell when they get out of sync). Not trying to self-promote too much but you can follow my profile to the project if you're curious.
- riffraff 8y ago
  Regarding the constraints, the article also makes a very important point: it's not all or nothing, you can have _some_ invariants and pre/post conditions easily. I.e. size of arrays or "nonblankness" of strings, or balanced invoices. The simple fact of thinking about the constraints, will help design code.
resource0x 8y ago
I agree with your analysis, but please notice that this new trend has completely redefined the idea of programming job, to the extent that, had I known about it in advance (say, 30 years ago), I wouldn't have chosen this profession in the first place. So the honest advice to "well intentioned types" (as you put it) is to switch to something else, otherwise you will feel miserable for the rest of your life. (I just bring your post to logical conclusion, which I happen to agree with entirely)
- tchaffee 8y ago
  It makes me a little sad to read this because I don't think there are zero opportunities for jobs where quality is the absolute priority. People write code for medical devices for example. In which case you have a legal obligation and an ethical obligation to write the highest quality code possible. I wasn't making the case that we should always abandon quality. Just that we understand its relative importance to other business requirements. That we don't build a $2,000 lock for a $10,000 safe to protect $1. I'd like to think the majority of code I write is high quality. I am proud of most of the code I write. And I spend a lot of time helping junior devs refactor their code to be more robust, deal with edge cases, and be more maintainable, etc. I've also been in the industry for a few decades now, and I'm more excited than ever about the opportunities for quality. The code we were writing in COBOL back in the day is nowhere near the level of quality of code that can be written today. Hell, we weren't even measuring bugs and quality back then. I encourage you to have a look around for opportunities where your employer's values and goals are better matched to your own values and goals. If you are super interested in software correctness, you shouldn't be building throw-away websites for short-lived marketing campaigns. But that doesn't mean those jobs aren't important too. Just that you shouldn't be the one doing them.
blub 8y ago
The world needs idealists and well intentioned types like these, because the improvements in software quality won't come from the burnt out, disillusioned, just ship it already types like you. What software wisdom would you share with us instead? That projects have deadlines and budgets? That the perfect solution does the job at the lowest cost over time? That the right way to program is to take the customer's requirements into consideration?! Honestly it looks like you gave up a long time ago and you're just trying to convince the rest of us that mediocrity is the way to go. No thanks. And it's not like Meyer is advocating for some hardcore formal verification... he's merely pointing out that design by contract can improve software quality. The same DbC which has first class support and could be implemented in many languages. Even the C++ boost library recently added support for DbC; it's kind of ugly and probably bloats the object files, but it's there.
- pdimitar 8y ago
  > Honestly it looks like you gave up a long time ago and you're just trying to convince the rest of us that mediocrity is the way to go. No thanks. That's exactly how I summarized most of his comments yet he still claims it's not true. I don't know, I am interested if he will reply to some of my comments so we can better judge what he actually had in mind. Him claiming that everybody misunderstood him is not a helpful discussion starter. :)
- tchaffee 8y ago
  > burnt out, disillusioned, just ship it already types like you I love programming. And I've been at it for three decades. Zero burn out. I don't believe in just ship it, and I take a lot of pride in my work. And yes, part of that pride comes from having a better understanding of customer requirements than someone idealistically insisting we cannot ship working software because the aesthetics of the code aren't pleasing enough yet. That's why I get paid a lot more than idealistic junior devs. Whose idealism I do appreciate, and who I enjoy mentoring. Most of that mentoring being around how to improve the quality of their code... I never said to ignore quality. Does it sound like I'm saying the world doesn't need idealists when I said this in my original comment? "So this article is good (although I think you're really looking at functional programming by this time in history) but first make sure a top priority is program correctness before getting into the mode suggested by the article" Maybe it's your own cynicism that gave you such an ungenerous interpretation of what I thought would be helpful advice to other devs. Whatever it is, that's on you, not me.
carapace 8y ago
> Based on empirical evidence, there isn't really a problem at all with the way people program. I disagree strongly. I would say that software development is a tire fire. Every day there are reports of bugs in software causing all kinds of real-world problems. These days software bugs can kill people[1]. And there are only going to be more CPUs and more software and more bugs going forward. > Markets have already mostly figured out the rare cases when such robustness is really needed. I don't see how this is a supportable statement in a world that includes the "Toyota Unintended Acceleration" bug? (Among so many many others.) When you say, "a perfect solution according to markets is the solution that does the job for the lowest cost over time" aren't you effectively saying we should only expect software to be as good as has to be to protect the liability of some corporation? Not to take a cheap shot, but uh, I think the families of the people who died in the car accidents-- excuse me, collisions ("'Accident' implies there was no one at fault.") --might have a different attitude to software correctness? In any event, your entire argument is predicated on the idea that correct software is expensive. But this is only true because we, as an industry, have not made effective use of the the available tools to write correct software! It's not expensive to write correct code. It doesn't take longer either. We just don't do it. Dr. Margaret Hamilton figured out how to write bug-free software as a side effect of her work on the Apollo 11 program years ago and nobody noticed.[2] (She's the person who coined the term "Software Engineer" BTW.) Byte-for-byte, flawless code is no more expensive than buggy code. And maintenance costs are near zero, so it's actually cheaper. You just have to use the right method (which has existed for about 30~40 years, nearly totally ignored.) Please PLEASE don't make excuses. We've can get this right, even if "the market" doesn't notice or care. To reuse my lumberjack metaphor from my other comment: Chainsaws exist. They are safer and faster than axes. There is in fact no way that cutting down trees with an ax is objectively better than cutting down trees with a chainsaw. You are maintaining that, since trees are felled well enough with axes today, there's no sense in investing in chainsaws and chainsaw training, not now, nor ever in the future. You're saying that "the market" only really needs wood cut by axes and doesn't value wood cut by chainsaws because all the furniture made with it is good enough, and we should just live with splinters and chairs that break and drafty houses, etc... Frankly, it's kind of a lame argument to find on a pro-tech forum. Fancy sophisticated technology is awesome, unless it threatens to obsolesce your favorite ax, eh? > you have to be able to find qualified developers, and what developers learn is based on popularity and fashion. This is the source of the problem: we're not "engineers", we're not even car mechanics! We're barely above the level of kids building go-carts in their backyards out of junkyard parts. We should be ashamed of our fashion-driven-ness. The amazing thing is that we got the business people to go along with this![3] Maybe someone should just start offering chainsaw-cut wood at cheaper prices than the hand-hewn crap and see if "the market" likes that noise? (In case I'm being too arch, that's exactly what I'm about right now. I'm so freaking passionate about this.) "Program correctness" shouldn't have to be "top priority" because it should be the default. You should get it "for free" along with the software for the same price because it costs nothing extra. [1] For example: "A Case Study of Toyota Unintended Acceleration and Software Safety" Prof. Phil Koopman. September 18, 2014. Carnegie Mellon University https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... [2] Nearly nobody noticed. I know it sounds crazy but it's true: There's a simple, easy method to develop bug-free software. James Martin wrote it up in a book "System design from provably correct constructs: the beginnings of true software engineering." in 1985. That's probably the best source if anyone wants to read up on it. [3] A programmer in language or framework A who cannot or will not learn language or framework B is not a good programmer. (I don't mean putting "Won't do PHP" on your resume, I mean that you can't or won't learn it in the first place.) Q: "What if we can't find Python devs? There are so many Java devs. We should use Java." A: "Why would you hire a Java guy who can't do Python? Even to do Java?" I've had that conversation a bunch of times.

kbenson 8y ago

> And a perfect solution according to markets is the solution that does the job for the lowest cost over time. Yep. If we actually valued correctness, the market would place some cost on incorrectness. Security is a common example of this. If we wanted, we could punish software developers or publishers for shipping security bugs (for example, making them liable), and then we would see an immediate shift in how software was written. That's not necessarily an endorsement of that position (it lacks enough nuance to even be remotely considered a good idea), it's just a fairly illustrative example.

blub 8y ago
The market can't solve solve the quality problem, that's a fantasy. Sw quality is so poor across the board that there is almost no one producing high quality, reliable software. My bloody phone can't properly select text in this box for example. Sw companies have optimised their production for decades to develop software that's just good enough to ensure profit and they've trained customers to expect and accept poor quality. Is anyone surprised when Windows reboots for updates in the middle of an important presentation? No, that's how Windows works. Companies will even reduce quality to improve profits and still get away with it if the customers don't notice, don't understand or are too apathetic to take action. Often there is no action to take that will sufficiently punish the offending company. Security is a great example: it's been bad for so long that core pieces of technology are fundamentally insecure and can't be significantly improved without total rewrites. Punishing developers and companies would result in a collapse of commercial software development, so humanity collectively accepts that software is by nature insecure.

jacquesm 8y ago

And then, five years after you've left the company and some system inevitably collapses with nobody having a clue as to what went wrong you'd finally realize the wisdom of all that. But it's no longer your problem. So, please don't take it personal, but 'the well intentioned types who write these articles' tend to be the people that then get called in to clean up the mess. And then - belatedly - the job gets done properly to keep the company in business, assuming there is still time enough to do so. Just this week I had a nice inside look at the kind of mess gets left behind when the original duct-tape-and-spit guy leaves the company and lets his former co-workers clean up their mess. It isn't pretty, and a chapter 11 isn't an unlikely scenario, so forgive me if I take a harsher than usual look at the attitude that causes this sort of thing. Note that the 'free market' doesn't have a horizon much longer than the next quarterly shareholder report, and that your typical software product lives a multiple of that interval. So software made with short term goals in mind will create long term headaches. Your two week marketing campaign gets a pass. But your decade long backend project does not, nor does your real time medical device controller, ECU, database system or operating system.

tchaffee 8y ago
> And then, five years after you've left the company and some system inevitably collapses with nobody having a clue as to what went wrong you'd finally realize the wisdom of all that. But it's no longer your problem. If that were a problem in reality, the markets would be punishing companies where that happens. It's not a real problem that that happens. Management pretends to be upset, but in reality it's not a huge deal. Entropy is normal in apps and everything else. To continue the analogy from my original comment, do companies really go into crisis mode when one of the many cars in their fleet inevitably "collapses"? No. They build or buy a new one and life goes on. > nor does your real time medical device controller, ECU, database system or operating system. Yep. Those are the rare cases I talked about. It's a tiny fraction of total programmers building databases and stuff like that.
- minor3rd 8y ago
  I agree with you whole-heartedly. My programming career has gone from "I don't know the best way to write something", to "I know the best way to write something and I'll do it this way every time", to "often it doesn't fucking matter, just get it done and move along to the next problem".

TeMPOraL 8y ago

I suppose - and this applies generally, not just to programming - people (myself included) don't exactly like market's idea of "perfect". Because free-market perfect isn't just nice-sounding "solution that does the job for the lowest cost over time" - it's the borderline cheapest, ugliest, worst solution that's only barely fit for its purpose, and if it was any worse, it would be unsellable. It's aiming for the absolute lower bound - as any possible way to make it cheaper is taken. The problems with market!perfection are many - mostly resolving around short-term optimization, externalities and lack of alignment between market values and human values. But we have brains that can be used to get better outcome than what the market incentivizes by default.

kbenson 8y ago
> The problems with market!perfection are many - mostly resolving around short-term optimization, externalities Almost all bugs, security of otherwise, are just negative externalities. I think the public has been conditioned to accept that software not only comes with bugs, but many of them, and there's nothing that can be done about it. Companies/developers/publishers are not penalized much at all for buggy software, so much so that it's a common business tactic to deliver crappy software that doesn't even accomplish what it states it does, much less bug free and without security problems, with the understanding that it can be fixed up after delivery with little negative consequences.
perl4ever 8y ago
I don't think that's correct. You're describing the marginal solution that the market produces, not the average solution. And because demands are always changing, the market never converges on that optimum you are presenting as a bogeyman. It's not realistic any more than all profits being competed away to zero.
- TeMPOraL 8y ago
  Yes, I've described the solution in the limit, in the same sense a physicist could write: lim t -> ∞ ... A limit doesn't itself happen in real life, but shows you where a system is going. As for a proof that this is happening, there are plenty of examples if you look at the highly competitive spaces and consider goods you usually buy, and how they evolved over past decades. Food and tools are two obvious cases that come to mind.

zzzcpan 8y ago

> but first make sure a top priority is program correctness That's the thing, this doesn't happen in real world and it is questionable if the concept of correctness is useful at all. As it is based on unvalidated and incomplete assumptions about the world, never fully correct themselves. Sort of correctness of incorrectness.

TooBrokeToBeg 8y ago
People don't even think consistently, so correctness is an ever-moving target (aka a negotiation).
perl4ever 8y ago
Case in point: from reading discussions about the C standard, my impression is that a compliant compiler is "correct" if it reads your program that dereferences a null pointer and blows up the world.
- TeMPOraL 8y ago
  If a null pointer handler in a nuclear warhead firmware caused immediate detonation, that would certainly be correct according to C standard ;).
mopierotti 8y ago
Correctness can just mean "does what it's intended to do". This is fairly unambiguous in cases such as if you intend to implement A* Search. If you hit a NPE and your program explodes, or if you aren't calling your heuristic (central to A*), then you have skimped on correctness. Furthermore, basically any time you hit something like a runtime error you likely did not intend to hit it. Therefore, regardless of problem domain, taking approaches that minimize these types of errors is an uncontroversial way that correctness can be prioritized.

lisper 8y ago

> One final stakeholder requirement that's always a priority: you have to be able to find qualified developers, and what developers learn is based on popularity and fashion. But popularity and fashion are not disembodied forces controlled by the whims of the gods. They are the sum total of decisions made by people. We could make different choices, but the belief that this is futile is a self-fulfilling prophecy.

tchaffee 8y ago
How could we make different choices? These choices are rarely made by developers unless it's their own startup. For most IT jobs these kinds of decisions are made by upper management who have to answer to a board of directors, and ultimately to shareholders. No one ever got fired for using Java. (I personally quit C++ and Java many years ago because I thought both were a bit of a mess. Maybe things have improved with Java - I haven't followed it much). Upper IT management can't just say "we're switching to Haskell because fewer bugs". They have to sell the idea to the folks who will pay for those massive changes which include retraining existing employees. And management does take into consideration how big the hiring pool is. That affects costs. A surge in demand for Haskell programmers would of course create a higher cost for hiring and keeping them. So they continue to hire Java programmers and students graduating from uni make sure they know Java. Where is the opportunity for us to make different choices? Should students refuse jobs in Java? Or without picking on a language, jobs at companies that have the highest software quality standards? That's a lot of idealism and responsibility to ask of someone whose is just hoping they can get a foot in the door and start their career. Or is there someone else you have in mind that could be making different choices? It does seem like my own personal choice to give up on Java has had zero effect on its popularity. There is far more at play than the "the belief that this is futile is a self-fulfilling prophecy" although I agree that too is a factor. I do have hope though. One thing I've seen happen is more and more programmers who were introduced to functional programming at uni and who manage to sneak ideas from that in wherever they can. I think we are slowly moving away from the worst parts of the object oriented paradigm and adopting the easier and better parts of functional programming. I'm looking forward to see what we end up with. So far, I think the evolution has headed in the right direction and we are getting better and better at this thing we call coding.

westoncb 8y ago

I've been thinking on similar lines for a while. It seems like the number one thing it comes down to is that more deep thought is required for a number of these 'obviously better' techniques (I think they generally come down to being more declarative than imperative, saying how the results should look instead of describing how to get them). So lots of people are inclined to say things like, "then don't be lazy, do the work and think deeply"—but for one thing, 'deep thought' should be considered as a conserved resource and you have to choose what to spend it on (it's not automatically better to always spend it); and for another, I think the actual depth required for perhaps the majority of real-life problem domains is impractical, or perhaps sometimes the domain is even fundamentally not amenable to an elegant mathematical solution. So you have to contort the 'better' language to do inelegant things it's not really suited for anyway. I think the constraints on the 'triples_from' structure from the article is a bit misleading and makes a good example of what I'm talking about. It looks super simple, but if you note how this constraint across tf.item as tp all tp.item.source = tf.cursor_index end is actually working, it's not so much that the language gives a particularly elegant/powerful means of specifying these constraints as it is that 'triples_from' was structured in such a way that it would be easy to specify the constraint. My feeling is that trying to do this for real-life things would rarely ever be so neat. If the domain you're modeling has mathematical elegance to begin with—absolutely, do the deep thought and uncover the invariants. But if it doesn't, then you'd be 'programming wrong' by trying to use such techniques. The alternative I've been thinking about is just developing far more powerful/pervasive visualization tools so that you can write relatively mindless imperative code and just see where things are going wrong more easily. (consider the author's example of multiple data structures which must be kept in sync, but it's hard to tell when they get out of sync). Not trying to self-promote too much but you can follow my profile to the project if you're curious.

riffraff 8y ago
Regarding the constraints, the article also makes a very important point: it's not all or nothing, you can have _some_ invariants and pre/post conditions easily. I.e. size of arrays or "nonblankness" of strings, or balanced invoices. The simple fact of thinking about the constraints, will help design code.

resource0x 8y ago

I agree with your analysis, but please notice that this new trend has completely redefined the idea of programming job, to the extent that, had I known about it in advance (say, 30 years ago), I wouldn't have chosen this profession in the first place. So the honest advice to "well intentioned types" (as you put it) is to switch to something else, otherwise you will feel miserable for the rest of your life. (I just bring your post to logical conclusion, which I happen to agree with entirely)

tchaffee 8y ago
It makes me a little sad to read this because I don't think there are zero opportunities for jobs where quality is the absolute priority. People write code for medical devices for example. In which case you have a legal obligation and an ethical obligation to write the highest quality code possible. I wasn't making the case that we should always abandon quality. Just that we understand its relative importance to other business requirements. That we don't build a $2,000 lock for a $10,000 safe to protect $1. I'd like to think the majority of code I write is high quality. I am proud of most of the code I write. And I spend a lot of time helping junior devs refactor their code to be more robust, deal with edge cases, and be more maintainable, etc. I've also been in the industry for a few decades now, and I'm more excited than ever about the opportunities for quality. The code we were writing in COBOL back in the day is nowhere near the level of quality of code that can be written today. Hell, we weren't even measuring bugs and quality back then. I encourage you to have a look around for opportunities where your employer's values and goals are better matched to your own values and goals. If you are super interested in software correctness, you shouldn't be building throw-away websites for short-lived marketing campaigns. But that doesn't mean those jobs aren't important too. Just that you shouldn't be the one doing them.

blub 8y ago

The world needs idealists and well intentioned types like these, because the improvements in software quality won't come from the burnt out, disillusioned, just ship it already types like you. What software wisdom would you share with us instead? That projects have deadlines and budgets? That the perfect solution does the job at the lowest cost over time? That the right way to program is to take the customer's requirements into consideration?! Honestly it looks like you gave up a long time ago and you're just trying to convince the rest of us that mediocrity is the way to go. No thanks. And it's not like Meyer is advocating for some hardcore formal verification... he's merely pointing out that design by contract can improve software quality. The same DbC which has first class support and could be implemented in many languages. Even the C++ boost library recently added support for DbC; it's kind of ugly and probably bloats the object files, but it's there.

pdimitar 8y ago
> Honestly it looks like you gave up a long time ago and you're just trying to convince the rest of us that mediocrity is the way to go. No thanks. That's exactly how I summarized most of his comments yet he still claims it's not true. I don't know, I am interested if he will reply to some of my comments so we can better judge what he actually had in mind. Him claiming that everybody misunderstood him is not a helpful discussion starter. :)
tchaffee 8y ago
> burnt out, disillusioned, just ship it already types like you I love programming. And I've been at it for three decades. Zero burn out. I don't believe in just ship it, and I take a lot of pride in my work. And yes, part of that pride comes from having a better understanding of customer requirements than someone idealistically insisting we cannot ship working software because the aesthetics of the code aren't pleasing enough yet. That's why I get paid a lot more than idealistic junior devs. Whose idealism I do appreciate, and who I enjoy mentoring. Most of that mentoring being around how to improve the quality of their code... I never said to ignore quality. Does it sound like I'm saying the world doesn't need idealists when I said this in my original comment? "So this article is good (although I think you're really looking at functional programming by this time in history) but first make sure a top priority is program correctness before getting into the mode suggested by the article" Maybe it's your own cynicism that gave you such an ungenerous interpretation of what I thought would be helpful advice to other devs. Whatever it is, that's on you, not me.

carapace 8y ago

> Based on empirical evidence, there isn't really a problem at all with the way people program. I disagree strongly. I would say that software development is a tire fire. Every day there are reports of bugs in software causing all kinds of real-world problems. These days software bugs can kill people[1]. And there are only going to be more CPUs and more software and more bugs going forward. > Markets have already mostly figured out the rare cases when such robustness is really needed. I don't see how this is a supportable statement in a world that includes the "Toyota Unintended Acceleration" bug? (Among so many many others.) When you say, "a perfect solution according to markets is the solution that does the job for the lowest cost over time" aren't you effectively saying we should only expect software to be as good as has to be to protect the liability of some corporation? Not to take a cheap shot, but uh, I think the families of the people who died in the car accidents-- excuse me, collisions ("'Accident' implies there was no one at fault.") --might have a different attitude to software correctness? In any event, your entire argument is predicated on the idea that correct software is expensive. But this is only true because we, as an industry, have not made effective use of the the available tools to write correct software! It's not expensive to write correct code. It doesn't take longer either. We just don't do it. Dr. Margaret Hamilton figured out how to write bug-free software as a side effect of her work on the Apollo 11 program years ago and nobody noticed.[2] (She's the person who coined the term "Software Engineer" BTW.) Byte-for-byte, flawless code is no more expensive than buggy code. And maintenance costs are near zero, so it's actually cheaper. You just have to use the right method (which has existed for about 30~40 years, nearly totally ignored.) Please PLEASE don't make excuses. We've can get this right, even if "the market" doesn't notice or care. To reuse my lumberjack metaphor from my other comment: Chainsaws exist. They are safer and faster than axes. There is in fact no way that cutting down trees with an ax is objectively better than cutting down trees with a chainsaw. You are maintaining that, since trees are felled well enough with axes today, there's no sense in investing in chainsaws and chainsaw training, not now, nor ever in the future. You're saying that "the market" only really needs wood cut by axes and doesn't value wood cut by chainsaws because all the furniture made with it is good enough, and we should just live with splinters and chairs that break and drafty houses, etc... Frankly, it's kind of a lame argument to find on a pro-tech forum. Fancy sophisticated technology is awesome, unless it threatens to obsolesce your favorite ax, eh? > you have to be able to find qualified developers, and what developers learn is based on popularity and fashion. This is the source of the problem: we're not "engineers", we're not even car mechanics! We're barely above the level of kids building go-carts in their backyards out of junkyard parts. We should be ashamed of our fashion-driven-ness. The amazing thing is that we got the business people to go along with this![3] Maybe someone should just start offering chainsaw-cut wood at cheaper prices than the hand-hewn crap and see if "the market" likes that noise? (In case I'm being too arch, that's exactly what I'm about right now. I'm so freaking passionate about this.) "Program correctness" shouldn't have to be "top priority" because it should be the default. You should get it "for free" along with the software for the same price because it costs nothing extra. [1] For example: "A Case Study of Toyota Unintended Acceleration and Software Safety" Prof. Phil Koopman. September 18, 2014. Carnegie Mellon University https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... [2] Nearly nobody noticed. I know it sounds crazy but it's true: There's a simple, easy method to develop bug-free software. James Martin wrote it up in a book "System design from provably correct constructs: the beginnings of true software engineering." in 1985. That's probably the best source if anyone wants to read up on it. [3] A programmer in language or framework A who cannot or will not learn language or framework B is not a good programmer. (I don't mean putting "Won't do PHP" on your resume, I mean that you can't or won't learn it in the first place.) Q: "What if we can't find Python devs? There are so many Java devs. We should use Java." A: "Why would you hire a Java guy who can't do Python? Even to do Java?" I've had that conversation a bunch of times.