47 ms·

Programmers who want to change how we code before catastrophe strikes

• DrScump 9y ago
  “Software engineers don’t understand the problem they’re trying to solve, and don’t care to.” In environments where management judges by (and is judged by) other metrics, this result is inevitable.
  • user68858788 9y ago
    This is the environment of large software companies.
  • jasonmaydie 9y ago
    it's like blaming the assembly line worker for a badly designed car. Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.
    • TeMPOraL 9y ago
      Also, a software engineer, being a technical person, can probably understand the problem quite well - but that doesn't help when the management doesn't care about solving the problem, but about sorta-solving it in order to maximize profits.
    • Jtsummers 9y ago
      The analogy would be more appropriate if you said programmer and not software engineer. Anyone calling themselves a software engineer should be providing input into the design of the thing they're producing. Their role is very explicitly managing requirements and codifying them in, well, code. Either directly doing the programming or managing those who do.
      • vorotato 9y ago
        Except software engineers are often placed in subordinate roles because "WE WANT ONLY THE BEST". If you aren't given the authority to change the design, caring about it is an unnecessary source of anxiety and stress.
        • busterarm 9y ago
          Many times, I feel this. Really though, caring about what the problem is and trying to solve it means: 1) you work slower, 2) you ask a lot of questions, 3) you push back on things. Basically you're spending more mental effort trying to encapsulate what the problem is than the stakeholder. Those things will often make people either hate you or think you're bad at your job.
        • arvinsim 9y ago
          I agree with this. Imagine studying about web design, accessibility and usability for many years. You feel that you have something to contribute to the design of any app. Then the higher ups just hands you a spec and assigns you to a task to fix this bug/implement this feature without your input. That's pretty damn demoralizing. It will just push you towards caring more about streamlining your own workflow to rather than care about the actual usability of the app. Maybe that's the reason why there is so much interest in the in what workflow to use, what IDE/text editor to use, which languages to program in, etc.
      • Epenthesis 9y ago
        Are there companies that actually distinguish between these roles? For all the ones I've ever worked at, "software engineer" and "programmer" are synonyms. (I'm aware that there's been some effort to extend the legal significance of the word "engineer" to the software industry, but I'm curious if that difference is actually in practice anywhere today)
        • Clubber 9y ago
          I dunno, it's just a title game. I would guess it's because programmers in the 90s simultaneously had massive hubris and insecurity issues and wanted to be just as respected in the community as actual engineers, but who knows. Engineer invokes a sense of design, but so does programmer. When I started, there was no job where you just coded straight pseudocode specs. Business described the problem the way business does, and you had to convert that into a computer solution. Within that solution, different developers would own various parts of it. I would say the entire process of having coders who design systems and coders that just write code is inherently broken. Businesses want to think of development as prod-ops, but it's more like book publishing. I'm of the mind that if a coder who designs a system in enough detail to write pseudocode, he should just write the application. The better approach is have an architect/lead model subsystems and a general skeleton of the application, then have different teams implement the subsystems. Clearly defined interfaces on all inter-subsystem communications.
    • jakelarkin 9y ago
      Was thinking about this the other day: in big companies SWE individual contributors are the new line workers. Large enterprise ends up trying to manage them with business metrics goals without much visibility into the process issues that hamper overall quality or the production efficiency. Has anybody thought to apply the Toyota Production System in Engineering management? https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System
      • emodendroket 9y ago
        Yes, a whole lot of people have thought of that.
      • zdw 9y ago
        DevOps takes this as a primary input.
  • wpietri 9y ago
    More specifically, I think those engineers are trained not to care. The have tried caring, experienced unpleasantness from their "superiors", and learned to stop. But this is reversible. I've done coaching in large-company environments and it's not at all hard to wake developers up, to get them to care again. The hard part is changing the environment so that caring is rewarded, not punished.
  • humanrebar 9y ago
    > Software engineers don’t understand the problem they’re trying to solve, and don’t care to. I think this is unfair. Engineers usually have great (at least qualitative though often quantitative) insight into potential, cost, and complexity. The problem tends to be in getting that feedback back into "the room where it happens", the place where budgets are set, approvals are given, disputes are resolved, and performance is evaluated. In that room, there is usually a heavier presence by people who understand organizations, political concerns, messaging, and revenues. So when the cost and risk experts (the devs) are not in the room, of course we end up with overly complex, poorly understood products that chug along for a while and then become so massive that either: a. the project collapses under its own weight b. the project creates its own "gravitational pull" and starts pulling in resources to support itself; sometimes this is locked-in customers who cannot migrate away, sometimes this is locked-in enterprises who can't imagine how (and sometimes why) to kill it off
    • DrScump 9y ago
      In some cases, however, ignorance on the part of the engineers (especially those with any say in the architecture of the application) of the users' needs can seriously damage the user experience for the life of the design. I face numerous examples in the sports-ticketing world all the time. For example, if you are going to a football game, what is the most important consideration to a fan? I say the most common priorities are: 1) nearness to midfield ("What yardline are my seats nearest?") 2) sun exposure ("Will I be baking in the sun all day? Do I need sunscreen? Will I be looking into the sun when trying to watch play on the field for a portion of the game?") 3) home vs. visitor side 4) elevation ("Am I low enough to see the players? Am I high enough to not be obscured by bench and media personnel?") If you're designing the site/app and you've never been to a (an American) football game, you won't know these criteria are important.
      • humanrebar 9y ago
        Sure. I was just saying the cluelessness goes the other way, too, so putting it on devs is at least one sided. Maybe a product genius can come up with better ways to sell shady stadium seats. But the technical contributors would be able to tell you that the shade-o-matic feature is layers of bad hacks that cost the company $X million a year in dev costs and astronomical security and maintenance risk since it is still running (partly) on old hand-configured Windows XP boxes using a hand-rolled UDP server library backed by an Access database. And that's for a key differentiator for the company. Profit and success doesn't happen until both sides of the story are accounted for.
• tmnvix 9y ago
  > "Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself." This is an insightful description of the biggest mental challenge I face when programming.
  • nomel 9y ago
    My personal method is, every line of code that I write, I write for someone else. If it's internal, it's always for another developer (who may not exist) and, for the upper layers, a user (of the function/API/library) that may peek behind the scenes trying to debug some problem. If it's anything facing the "user", it's entirely written for that user, and I know they're not very good at reading or writing software. Thinking about the developer helps prevent me from being lost in complexity, abstraction, or the general specific of the problem. Thinking of the user keeps the game in sight. In all cases, I've had very "clever" solutions that are fun and challenging, that I completely scrap for something the other developer, and myself, can understand in 3 months.
    • gregmac 9y ago
      > for another developer (who may not exist) You, 6 months from now (or whenever you stop touching this code base), are effectively "another developer". New developers don't seem to really grasp this until the first time they have to maintain their own old code. I don't think it really hits home until the first time you experience: "What is this? Who wrote this garbage??" runs git blame "..oh, crap."
      • milkytron 9y ago
        This is why I usually throw in comments with myself as the recipient for understanding where complexity exists. I've heard people debate over whether comments should be in well written code, including some that argued comments should never be used at all. Party A: Code should be easily understandable so that comments aren't necessary. Party B: Comments should exist where complexity exists to save a developer's time when determining what is and is not important to them. Sometimes though, you just can't avoid it. The few times I had to write PERL are prime examples.
• carlmr 9y ago
  I agree with the premise, but I'm unsatisfied with the solutions offered. I've worked on both C code and model based designs in Simulink and other more purpose built tools for safety critical embedded systems. First off I can't agree with the notion that programmers don't care about the system. They do. A lot. Especially the good ones. You can't do any meaningful work without caring about the system you're working on. But like in any profession you have some useless people. Second on MBD. In my opinion it leads to much more complex code, especially because the people writing the code aren't coders anymore. Or they don't see themselves as such. You say the people crafting the requirements are now speaking the same language as the coders? I say we've siloed people working on requirements from the actual coders now, which leads to exactly the coders having no clue about the requirements, and the requirements engineers having no clue what their model based changes do to the software. MBD is the worst reason I've seen for spaghetti code making it mainstream. MBD promotes spaghetti simply because it's so much easier to tack on more and more complexity without a serious understanding of what it does to code. Another thing is that I find MBD often harder to read than code. I can't really point to hard evidence, but I have a good analogy here in terms of UX. If code is like Google, MBD is like Bing's 2D tiling. It's much easier for a human to parse a list of statements, than statements that are all over the place. I think if we did meaningful research here, we'd get the same result for MBD vs code. We still shouldn't give up to look for better ways to code, but I think the better ways are easier to use programming languages that preserve the general purposeness of programming, better interactive environments (like F# interactive, Python REPL, etc.) and helpful syntax highlighting and better code annotation systems. Maybe live rendering of markdown and explanatory pictures in the IDE would be a helpful first step.
  • saimiam 9y ago
    What is your approach to delivering a programmatic solution to a given problem? Without knowing that, I can't quite tell if you understood the article at all.
  • humanrebar 9y ago
    > Another thing is that I find MBD often harder to read than code. I can't really point to hard evidence, but I have a good analogy here in terms of UX. It is harder to read. Both for humans and for programs. In code, if you see a mysterious call to "flushData", there are standard ways in each language to discover exactly where the definition of that logic is. In contrast, what is the standard way to discover what a circle means? A dotted arrow? OK. Maybe your IDE has a right-click "go to shape definition" option. But that's not a language feature. That's a tool feature. So you don't really have a language spec. You have a tool spec. So the problem is that the language is hard to read because it's not a concrete language. It's a nebulous implementation detail of a tool.
• combatentropy 9y ago
  If TLA+ really does let you prove your program is bugless, then maybe it is something to look into for cars, airplanes, medicine, etc. For the rest of us, who still wrestle with complexity but probably would't accidentally kill someone, here are some simpler aids: 1. Don't put a computer there. My microwave doesn't need to be digital. It needs two dials, time and power. My mother's washing machine can be controlled by smartphone. How useful is that, since you can't load it by phone? Computerized light switches are another example of something that sounds nifty, but the complexity outweighs the benefit by a thousand to one. Plus, you need the exercise. Get up and just hit the light switch. I question whether a car needs any computer at all, especially if the car is electric, ironically. My ignorance will allow that maybe a computer can mix air and gas better than a purely mechanical fuel-injection system. But since an electric motor is simpler, this advantage disappears. Don't get me wrong. I like computers. But I think computation should be gathered instead of spread all over the place. I like my smartphone and my laptop (pure computers). And I would prefer a car from the 1960s (pure mechanics). I don't like the hybrids --- today's complicated, hackable, beeping nannymobiles. 2. Give more time for refactoring. It's an embarrassingly unflashy point, but I think refactoring is important. Don't rush software out. Let programmers refine it. Maybe even force them to, beyond their natural tendencies, like the schoolteacher telling a pupil to revise once again. It is unflashy, but it makes a big difference. I've revised programs down to a tenth their size (no, not by using one-letter variables and that sort of thing, but by finding more efficient ideas), made them run a hundred times faster on the same hardware, all while adding features and improving safety. (See the advice about "going deep" instead of "high" or "wide" by Hacker News member bane: https://news.ycombinator.com/item?id=8902739 https://news.ycombinator.com/item?id=8902739) 3. Data-driven programming. I'll just quote some really smart people: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. --- Fred Brooks, The Mythical Man-Month "If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." --- Rob Pike (https://www.lysator.liu.se/c/pikestyle.html https://www.lysator.liu.se/c/pikestyle.html) "I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." --- Linus Torvalds (https://lwn.net/Articles/193245/ https://lwn.net/Articles/193245/) "Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic. . . . "Data is more tractable than program logic. It follows that where you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data. --- Eric Raymond, The Art of Unix Programming (http://www.faqs.org/docs/artu/ch01s06.html#id2878263 http://www.faqs.org/docs/artu/ch01s06.html#id2878263). See also ch. 9 (http://www.faqs.org/docs/artu/generationchapter.html http://www.faqs.org/docs/artu/generationchapter.html)
• bsaul 9y ago
  Great article, but it leaves me with one question : what's the difference between good code generating systems (the ones mentionned, that you'd use to build critical system), and the horrors that we saw back in the time with wysiwig HTML editors such as dreamweaver ( to the point where nobody today would dare to write an html website with something other than a text editor) ? The second problem seems a lot easier to me, and yet it is where wysiwyg failed spectacularly.
  • shalabhc 9y ago
    > good code generating systems To discuss a different perspective - why have text as an intermediate representation at all? To elaborate - if you look at something like Smalltalk, you modify the 'running program' directly.
    • hwayne 9y ago
      LabVIEW is the future
      • tytytytytytytyt 9y ago
        Any decade now...
  • Animats 9y ago
    What went wrong with Visual Basic? (HTML/CSS/Javascript was botched so badly that Dreamweaver-type editors no longer work. This is embarrassing.)
    • david927 9y ago
      What went wrong with Visual Basic? The language was simple enough for beginners but not sophisticated enough to scale for large projects. All too often you would have a project that started in VB as a proof of concept which then extended to become the actual system, and then as that system grew it started to collapse under its own weight. The conversion to the CLR fixed a lot of that, but now it isn't really for beginners anymore. HTML/CSS/Javascript was botched so badly That combination is atrocious out-of-the-box. There was no "botching" it, but rather (again) scaling to larger problems showed that the foundation was always made of sand.
• hwayne 9y ago
  > He began collaborating with Gerard Berry, a computer scientist at INRIA, the French computing-research center, on a tool called Esterel INRIA is also maintains Coq, TLAPS, and much of TLA+. INRIA is a scary scary place.
  • simlevesque 9y ago
    > INRIA is a scary scary place. Why ?
    • schoen 9y ago
      I assume scary as in "scar(il)y smart", in the sense that it's (almost) disturbing to see their sophistication and competence.
      • simlevesque 9y ago
        Thank you.
• brfox 9y ago
  The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.
  • mannykannot 9y ago
    The effects of a change may be immediate, but not necessarily immediately obvious. Subtle bugs are a problem in any programmable system.
    • rodw 9y ago
      Yes, and there are plenty of examples of spreadsheet-bugs having significant real-world impact. E.g., 1. https://www.bloomberg.com/news/articles/2013-04-18/faq-reinhart-rogoff-and-the-excel-error-that-changed-history https://www.bloomberg.com/news/articles/2013-04-18/faq-reinh... 2. https://www.cio.com/article/2438188/enterprise-software/eight-of-the-worst-spreadsheet-blunders.html https://www.cio.com/article/2438188/enterprise-software/eigh...
  • recursive 9y ago
    And yet its results aren't any more reliable. They seem less so to me. https://www.bloomberg.com/news/articles/2013-04-18/faq-reinhart-rogoff-and-the-excel-error-that-changed-history https://www.bloomberg.com/news/articles/2013-04-18/faq-reinh...
  • nitwit005 9y ago
    My uncle worked at a very large corporation that couldn't update to a later version of Excel because they relied on some spreadsheet to do their taxes, and some minor difference between versions broke the spreadsheet. No one could reverse engineer what the spreadsheet did. With a complex enough sheet, every cell becomes a separate function with no documentation. That's unfortunately a pattern you see with these efforts to make things simpler and more visual. They're great tools, until it gets too complicated, and then you find you'd be better off just writing code.
    • 9y ago
• chroem- 9y ago
  The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when in reality other engineering disciplines deal with unexpected failure modes all the time. The only difference is that these other engineers are motivated to be significantly more thorough about their jobs.
  • always_good 9y ago
    >The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Well, it's a whole ecosystem problem. Most of the places I've worked, security was just supposed to be something you learned and credentialized on your own, and no time or resources were deliberately allocated to it. In fact, you're likely seen as an underperformer if you slow down to get things right or to refactor bad code. And when software does break, `git blame` tends to accuse the developer that was in the worst position to fix a ship that had begun sinking long ago. I'm not sure how engineer culpability works in other fields, but surely it's always coincided by bad process and management at which point the whole company is responsible.
    • throwaway020217 9y ago
      In professional engineering the accountability comes with a stamp, and a professional ethics requirement to report up the chain if a critical problem has been found that could impact public safety. This includes whistleblowing if management ignores the problem. There are clear guidelines as to what types of products and services require a p.eng.'s stamp. There are also many professional engineers out there who's stamp has never touched ink. For example, the engineers drafting and churning out spreadsheets in the engineering sweatshops aren't accountable for the safety of the product, you'll have one or more engineers providing their stamp for that group's work. If we were to implement a similar model on software development, most developers would not have personal liability for work they do e.g. for a company or open source project. What is needed is better classification of software products/activities that require a software engineer's stamp[1], and a corresponding professional association. So no, developers should not be accountable. However, certain safety-critical products - where safety can be defined in various ways expanding the current relatively small set of NASA, aviation and health-care software - need engineers overseeing design, development, and QC to be accountable. And yes, this means that the self-taught developer, no matter how talented, will not be able to release certain types of software without some sort of oversight. [1]As a side-note - not everyone can call themselves an 'engineer' in other fields without the proper credentials and professional membership. I see developers calling themselves software engineers all the time though they don't have the chops. This would, of course, need to change. Updated to change asterisk to brackets
• walshemj 9y ago
  The example however (911 outage) is a poor one a traditional telco could not make that mistake with POTS they talk in major failures (ie losing a switch) as a once in a generation or two.
  • Animats 9y ago
    In the history of the Bell System, no electromechanical exchange was ever totally down for more than half an hour for any reason other than an natural disaster.
    • Periodic 9y ago
      The reason cited seems much more a case of moving call-management into a high-level software system that didn't have the same sort of rigor that telecom systems traditionally have. Maybe it did and someone missed this? It's hard to know. In short it feels a lot more like a management failure than a failure of software.
      • walshemj 9y ago
        Probably a lowest cost bidder and not helped by the US devolved government if this had happened in say the UK the papers would have a field day and the government would force the telcos to fix it stat!
    • Animats 9y ago
      Someday I should write up how that was done in modern terminology. You can read the "Number 5 Crossbar" documents, but the terminology is archaic.[1] Crossbar offices consisted of a dumb switching fabric and lots of microservices. The switching fabric did the actual connecting, but it was told what to connect by other hardware. Each microservice was implemented on special-purpose hardware, and there were always at least two units of each type. Any unit of a type could do the job, and units of a type were used in rotation. Microservice units included "originating registers", which parsed dial digits, "markers", which took parsed dial digits and routed calls through the switch fabric, "senders", which transmitted dial digits to other exchanges for inter-exchange calls, "incoming registers", which received dial digits from other exchanges, and "translators", which looked up routing info from read-only memory devices. There were also trouble recorders, billing recorders, trouble alarms, and other auxiliary services. Every service unit had a hardware time limit. If a unit took longer than the allowed worst case time, the unit got a hard reset, and a trouble event was logged. This prevented system hangs. Failures of part of the switching fabric could only take down a few lines. Failures of one microservice unit of a group just slowed the system down. Retry policy was "try one microservice unit, if it fails, try a second one, then give up and log an error". If a retry with a different unit didn't work, further retries were unlikely to help. All microservice units were stateless. At the end of each transaction, they went back to their ground state. So they couldn't get into a bad state. All state was in the switching fabric. All microservice units were replaceable and hot-pluggable, so maintenance didn't require downtime. This architecture was very robust in practice. It's worth knowing about today. [1] http://etler.com/docs/Crossbar/ http://etler.com/docs/Crossbar/
• p0nce 9y ago
  This gives an idea for an interesting tax. Every (money-making) codebase should cost money commensurate to the number of LOC.
  • insertnickname 9y ago
    It'll just encourage companies to rewrite all their software as one line of Perl.
    • hwayne 9y ago
      My J skills will finally be worth something!
      • eggy 9y ago
        No kidding! I love J, and I find it very easy to troubleshoot, since it is all within a few lines or a page. Forth is like that too.
    • worldsayshi 9y ago
      Perhaps it should be taxed by number of conditional branches then?
    • FLUX-YOU 9y ago
      Nah, we'll just have a transpiler and PerlPack™ and PPM
• narvind 9y ago
  Great article! My $0.04: 1. Programmers often see a small part of the jigsaw puzzle they are assembling. Most spaghetti code is the result of too many cooks over time. 2. The architects should ensure that testers know and care more about the problem than the programmers who are coding the solution 3. There is a clear need for improving the stone age tools programmers use 4. There is a need to create simulated environments for all kinds of software so they can be battle tested
• vtange 9y ago
  So we need to write more code to make fancy Photoshop-like editors for the average-Joe programmer who can't see the big picture? That just adds more to the code issue - even Photoshop has bugs you know. The fact that "Few programmers write even a rough sketch of what their programs will do before they start coding" is a soft-skills/experience issue that isn't specific to software. I too can use Photoshop to draw logos, maps, and diagrams, but I'm pretty sure someone out there who uses Photoshop professionally knows a lot more tricks within Photoshop and sees the bigger picture of what they want to create before starting. I generally free-hand my drawings, as opposed to the structured outlining most professional artists do.
  • haskellandchill 9y ago
    No, we need to use logic and set theory and provide tools for visualizing the implications of our rules and checking correctness of desired properties. There's a strong history and lots of good people working on these things but it's tough to get our message out to working programmers. This article helps but based on the comments we've got a lot of perception work to do :)
    • Bartweiss 9y ago
      There are definitely people making a real effort here, and I appreciate you. But I can't shake the feeling that the reason your task is so hard is that everyone before you has been selling snake oil. "Visual programming", "human-readable software languages" and so on are all just ways of saying "crippled tools". It's not an accident that the examples in the article were WYSIWYG editors, Photoshop, Squarespace, and Mario. All of those things flatten neatly into two dimensions, and their terminal form is visual. The visualized code is the product. Meanwhile similar initiatives for software in general are almost always nonsense. There was a pretty compelling TED talk* about visual tools for cybersecurity, shared by lots of people I know. Only one problem: none of the fancy tools showcased work, or will work. They're operating backwards from a known answer. Like most programming tools, they collapse right where they're needed most, stopping at the same edge cases that cause these problems. More broadly, it seems like the existing tools for known-safe software run exactly the opposite direction from Bret Victor's vision. Correctness proofs, exhaustive test suites, reversible debuggers, and so on are far from non-code, but they're what we use where reliability matters most. I can appreciate that "code everything like the space shuttle" is hopeless, and I would love to see breakthroughs on easier correctness checking. But right now, it does feel like an attempt to push tools that won't work when they're needed. *TEDx, but selected by TED for special featuring: https://www.ted.com/talks/chris_domas_the_1s_and_0s_behind_cyber_warfare https://www.ted.com/talks/chris_domas_the_1s_and_0s_behind_c...
• kmicklas 9y ago
  Disappointing to see such a long article and no mention of type theory, or any other work from the "correct by construction" school of formal methods. It's all normie model checking, TLA+ etc.
  • AnimalMuppet 9y ago
    Type theory is much less than "correct by construction" formal methods. Type theory is great at preventing a whole class of bugs (an operation on a value for which that operation doesn't make sense). But it's inadequate for the larger problem, of whether the operation is the correct one. Formal methods can ensure that the code matches a formally written spec, for all the aspects of the code that are covered by the formal method. Note well: That's not all aspects of the code. And you have the little problem of (correctly) creating the formal spec. This move the problem up a layer, but the problem doesn't go away. Even given a formal spec, though, it's my impression that formal methods are s l o w. Does anyone have data on this?
    • catnaroek 9y ago
      > And you have the little problem of (correctly) creating the formal spec. How on Earth did we end up putting people who can't write down precisely what they want in charge of programming machines that do exactly what you tell them to?
      • perl4ever 9y ago
        I was just told today that gathering requirements is not my job, it's the PM's. But they are swamped in administrative minutiae, and all too often the only person who knows how something worked has quit anyway. So in sum "no spec, no spec, you're the spec!"
    • kmicklas 9y ago
      > But it's inadequate for the larger problem, of whether the operation is the correct one. Huh? Types (of the sufficiently advanced kind) are one way of specifying behavior in the same sense as TLA+ and other models. The difference is that type theory provides a coherent story for how to form entire systems like this in a composable manner. Traditional modeling/spec languages, not so much.
• skywhopper 9y ago
  This article is silly in a lot of ways. The real problem of software engineering is not "how do you prove this code follows algorithm X exactly?" It's "how do you know what algorithm X needs to be in sufficient detail to implement it?" It's "when you realize you were wrong about algorithm X, how do you change your existing, working code to implement the new algorithm X-prime, without interruption?" It's "what do we do when we realize algorithm X-prime was completely the wrong thing, and now we need to transition to algorithm Y, and also fix all the data that algorithm X-prime messed up?" No matter what awesome tool you come up with to translate requirements into CPU bytecode, you still have to translate human requirements into that requirements language, whether that language is assembly, C, Java, Rust, Haskell, or TLA+. When you have the money and time and patience to fully examine the problem space and work out exactly what the requirements are, that's great. In the far more common scenario, you have impatient investors, or you're inventing something entirely new, or your software will deal with the real world which is not as predictable as an imaginary algorithm. Government regulations, flaky hardware, network latency, human error, financial limits, competition, malicious actors, gamma rays, other people's software, power outages, terrorists, dependencies, operating system upgrades, corrupt data, hurricanes, all are conspiring against your software. Can you plan for all of that?
  • haskellandchill 9y ago
    It's not a one size fits all thing. The majority of startups won't need these methods, think software for examples in the article: control systems, critical infrastructure, etc. It's fine to have different approaches for different classes of software. Raising awareness of these tools is critical because most software engineers haven't put much thought into them.
  • brians 9y ago
    The article's not silly. Leveson and Hamilton's works cover that explicitly. Start with Engineering a Safer World's Intent Specifications, move on to Safeware, and look at the attention that goes into writing the right TLA+ specs. Lists like "Government regulations, flaky hardware…" look a lot like the upper levels of the hierarchical control systems contemplated there. It didn't make it into a pop science piece, but it's absolutely core to the work at issue. You can get a copy of the book at http://sunnyday.mit.edu/safer-world/index.html http://sunnyday.mit.edu/safer-world/index.html .
• dsfyu404ed 9y ago
  I work in security. People not giving enough shits about the "situation in the field" with respect to how their code will be used, how long it will need to be used and what will need to be done to keep it functional over that time is job security for me. Some points the author makes I agree with, others I don't. Nothing will change until incentives change.
• tasuki 9y ago
  I'm surprised understanding the domain hasn't been mentioned. Whether I am developing for someone else or for myself, it turns out misunderstanding/misrepresenting the domain is the most common source of trouble. If your understanding of the domain isn't thorough, is TLA+ going to be much help?
  • ScottBurson 9y ago
    > If your understanding of the domain isn't thorough, is TLA+ going to be much help? I suspect it could, actually, because it lets you formalize and work with the implications of the understanding you do have without getting bogged down in the details of actual coding. Seems like this could give you the opportunity to debug your mental model much earlier in the process. (I confess I haven't actually tried TLA+, but I plan to.)
  • hwayne 9y ago
    It helps in two ways: 1) You have to specify your system, right? With TLA+, you can just wave you hands and say "okay this part does something, I guess." You have to force yourself to understand what, exactly, you want your system to do and what you want out of it. 2) Most systems have edge cases, side effects, and race conditions. Are you sure your design is robust against them? You might think you have good arguments for that, but wouldn't it be better to rigorously _check_? Tests and types and stuff help you find bugs in your implementation. TLA+ helps you find bugs in your blueprints.
    • tasuki 9y ago
      Good points! Writing unit tests before code can help avoid mistakes in the interface design. Perhaps similarly, writing formal specification could expose the holes in your domain understanding.
  • jkaptur 9y ago
    > “The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.” Did you mean something different from that?
• igravious 9y ago
  So. Minus all the doom and gloom. Better safety harnesses, better developer abstractions, more interactive/responsive programming environments. Whatever Bret Victor's selling, I'm not buying. He's the type of self-promoter who doesn't acknowledge all the actual hard work that has been going on for decades in all of these areas.
  • worldsayshi 9y ago
    If someone actually want to work with such things as opposed to trying to solve the problem directly with huga amounts of code, where to apply?
  • shalabhc 9y ago
    Can you point to what work specifically has improved the situation in terms of `developer abstractions` and `interactive/responsive programming` in the last few decades?
    • igravious 9y ago
      Yup, I can. Safety harnesses -> work in type theory and proof theory, witness the success of Rust and Haskell and Coq and so on. Developer abstractions -> work on design patterns and anti-patterns among other things. interactive/responsive programming -> IDEs, refactoring, time-travel debugging, visual programming spring to mind. To write off all these advances is suspect in my opinion. Also, why so glass half empty? Why not glass half full? Why not say, "wow – given how many lines of code are out there isn't it amazing how much has not gone tits-up? (pardon the expression!) That wouldn't fit the Bret Victor narrative though. One last thing – the claim that we are oh so crap at manipulating symbolic machinery. That too is suspect, one could argue we actually seem hard-wired through evolution for linguistic, logical, and symbolic thought.
      • shalabhc 9y ago
        > interactive/responsive programming -> IDEs, refactoring, time-travel debugging, visual programming spring to mind. > one could argue we actually seem hard-wired through evolution for linguistic, logical, and symbolic thought. I think you're still talking about programming environments layered on top of the text centric representation, while Victor seems to be talking about something a little different. Sure we can do some symbolic and linguistic manipulation, but consider that rigorous blueprints for physical products such as cars and buildings are 'diagrams', not text. So purely language based description and manipulation doesn't apply everywhere. Now, what if many programs, or parts of programs may be better represented not as text with symbols, but in some other form that we haven't discovered yet?
• valuearb 9y ago
  "For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round is my rough sketch, the second is written when I fully understand the problem, which for me only occurs once I've tried to code it.
  • Latty 9y ago
    Exactly. This is ignoring the fact that code is a more useful blueprint than anything else for programs. I'm sure if architects had the ability to magically conjure building materials out of thin air and try things in real life for free, architecture would involve a lot more trying and a lot less planning. Of course, I'm sure the article is talking about people just rushing into production code without thought, and I get that is a problem. It's just when people make comparisons like that it can imply this horrendous future where we whiteboard program for months, which is just a terrible idea.
    • hwayne 9y ago
      Coding isn't always the best blueprint. One example: what if you're writing a service that talks to two other internal services and a third-party API? Your code might capture what your specific service does, but it doesn't capture the overall design and intent of the complete system. That's one of the places where formal methods like TLA+ excel.
      • KirinDave 9y ago
        You might be interested in Servant, a haskell library that uses types to capture these high level interactions between components and then validate and even generate clients, documentation, servers, and simulators.
        • hwayne 9y ago
• KirinDave 9y ago
  The irony is the "this is all too hard write less code use more axiomatic principles and compiler assistance" is the functional programmer's call and it keeps getting shot down as 'too complex.'
  • whipoodle 9y ago
    There is no silver bullet.
  • Periodic 9y ago
    Where I get the most resistance to functional programming is more in the abstractions: both that they are too complex and that people aren't already familiar with them. High-level/complex/abstract patterns are hard to understand the first time and FP seems to make those patterns easier to express. I'm surprised how much we take for granted an understanding of object-oriented coding in the industry. Any graduate with a four-year degree in CS can be expected to write passable object-oriented code, but many have absolutely no exposure to functional idioms. Of course, those same people may have very little exposure to more complex OOP design patterns. I've seen people's eyes gloss over the same why when saying, "It's just a monad" as when saying "It's just an interpreter pattern".
    • KirinDave 9y ago
      > I've seen people's eyes gloss over the same why when saying, "It's just a monad" as when saying "It's just an interpreter pattern". Same. All we can do is try and change education patterns. Neither are that complex.
• gabriel34 9y ago
  That which this article describes is only possible to some extent. In my experience code generators are great until you run into a case for which you have to manipulate the generator to account for some edge case or some unforeseen problem, then they tend to become more complex than simply writing the code yourself. Most of the problems described are already tackled in modern software development. TDD, Correct-by-Construction and input validations are some tools to ensure resilience. The car acceleration issue could also have been avoided with a default to safe approach. Spaghetti code should have been refactored. It is not programming itself that is the issue, it is the auto maker that is at fault here. In ETL there are some tools to visually manipulate the data flow from one end to another. Some ETL software even allow you to visualize the effect of the changes on the fly, much like the Mario game. Solutions developed like this are easily understandable and maintainable by others even with minimal documentation (but require understanding of the business problem). But, much like normal programming, once you want to do something that exceeds the capabilities of the ETL software you are using, or when performance is an issue, you have to understand how the underlying software works under the hood. You can become really good at solving one set of problems with a ETL software once you have mastered it, but this is limited to one domain of problems. Likewise, specialized software allowing easy visualization and manipulation is usually very domain specific. You can tackle complexity in programming hiding it behind libraries and databases that do the heavy lifting while the programmer integrates the pieces and accounts for particularities of the problem he is solving. I could envision representing library functions as black boxes and connecting arrows to integrate them, having input validation and strong typing or automatic typecasting. Still, when you get too far from the machine, you miss the edge cases, the things you can't imagine when you visualize whatever you are creating in your head, the problems that only arise when you externalize and codify the knowledge. I think this is at the core of the issue; in order to instruct the computer to do something, you have to externalize tacit knowledge. In doing so you come across problems you just can't see from too high up.
• mongmong 9y ago
  "The software was doing what it was supposed to do. Unfortunately it was told to do the wrong thing" I feel the value of Domain Driven Design more and more every day and I think it is one method to make the business intent be reflected clearly in the code base, using domain language and modelling the domain to be self documenting.
• rhinoceraptor 9y ago
  I’m surprised no one’s mentioned it yet, but unintended acceleration is most likely a myth. In any functioning car, the brakes can easily overpower the engine and stop the car.
• Karrot_Kream 9y ago
  Our company uses memcached to store short-lived pieces of user-specific data for one of our (web) products. The way this was architected, any time a user visited a page, a request would be made to memcached with the user, check to see if memcached had data, fetch the data, and then clear the cache. This feature had always been a bit buggy, but then we decided to start adding more things to this user-specific data store. And it blew up. Data we wanted to store for the user wasn't being stored at all, data was being fetched many requests after they should have been fetched. Sometimes stale user data was being fetched days after the data should have been cleared, and the data was not being cleared. After being pulled into the war room for this, I started looking into the code and architecture of the issue and was appalled. Code for the feature was designed piecemeal, tests were nonexistent, and of course only certain cases of the code were tested. The whole thing was a concurrent nightmare and would not hold up to concurrent reads/writes. Rather than sit there and make sense of it all (I started sketching it out on paper because it was so convoluted), I ended up writing the spec out in TLA+. Just forcing myself to write the spec out made me consult the implementation dozens of times, to verify the exact behavior in a way that TLA+ could model it. And then after I did that, it was obvious that the code was broken. So in my TLA+ model I shored up what I thought were the problems, ran the model checker, and was expecting a fix. Nope. The model checker found another bug. I tried a different strategy, and it found another bug. I iterated with the model checker dozens of times, and slowly changed the model entirely, making it simpler and clearer to understand. Finally the model checker couldn't find any bugs. I converted the model to real code and, after some code review, I shipped the fix. It worked. I wish more people would spec their code with something like TLA+, but as I've seen in my own teams, the mantra is ship first think later.
• shusson 9y ago
  One of the biggest benefits of model driven development is having a common language to talk about design with other people. State becomes clear and any complexity is inherently linked to how you designed your model. I really hope it becomes more popular and more companies start supporting it.
• firethief 9y ago
  One of the best arguments for Lisp I've heard this decade
• drawkbox 9y ago
  Programmers write code badly due to time constraints in many cases or really disconnected teams being led by business not engineering. Rarely is budget allotted for quality code, you have to fight for it as a coder to your own detriment internally on timelines/shipping. Engineer led companies, or companies that value engineering as a main decision maker in the company usually fare better with issues like this and are already smart about design, architecture, standards, security, reliability, interoperability, user experience and more.
  • maerF0x0 9y ago
    Even given good amounts of time engineers often skip tools that could catch some bugs. Examples, TLA+, fuzzers, full code coverage etc. Sadly all things are economic, so we apply the tools where the cost of a bug is high. In the case of 911, its very high but underfunded. In the case of some consumer app, its (presumably) very low...
• osteele 9y ago
  This article reports uncritically the plaintiff’s claim that Toyota runaway acceleration issues were a software issue. The Wikipedia article presents a more balanced report; the black box data is particularly interesting. https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...
• HumanDrivenDev 9y ago
  A lot of it comes down to the fact that this isn't engineering, and we aren't engineers.[0] The field has a very low barrier to entry (much lower than a bachelors degree). The standards are low, the expectations are low, and there's a strong anti-intellectualism streak. Don't believe me? try talking about "esoteric" stuff like category theory, logic programming, LISP or writing functional specs. At the workplace most of your fellow professionals will stare at you blankly, and even on self-selected places like here or proggit, half the people will rush to dismiss it. There aren't - as an example - mechanical engineering "bootcamps" because mechanical engineering is an actual engineering field, with high standards, real accreditation, and professionalism. We don't have that, we have middle aged men giving talks in t-shirts and saying stuff like "ninja" and "awesome". I think we need to face up and rectify the fact that we aren't engineering before we can advance. And yes this requires excluding people who aren't up to standards. We're not the equivalent of chemical engineers - we're the equivalent of alchemists. [0] with the Caveat that stuff done in Avionics, or Medical Imaging, or anything else with very high standards and rigorous processes could probably be called that.
  • Aeolun 9y ago
    > category theory, logic programming, LISP or writing functional specs But does it fix my problem? I'm sure category theory is interesting for it's own sake, but it won't help my boss add this extra attribute to our product, so it won't help me get paid. Given that I've already added fifteen form fields this week, my mind is too overburdened to care much about category theory, which will have exactly zero relevance to my next week of adding form fields.
    • HumanDrivenDev 9y ago
      If your role in a company is so removed from the business or stakeholders that you're being assigned tasks like "add 15 fields", then IMO you're already in trouble. That's part of a larger issue though, where we actually let non-technical people dictate technical specs to us.
  • mac01021 9y ago
    I remain open-minded to the idea that category theory could help me make better computer programs, but I have yet to see anything that suggests to me that it really would. FWIW, I understand how monads work in Haskell & co, and I definitely see their value. But I don't consider myself to know any category theory at all.
• bitwize 9y ago
  Model-based design has been the wet dream of software managers looking to eliminate costly, finicky programmers for what? Decades now? I remember when I was a college student being told that eventually, the work products of software architects would be UML diagrams that could be turned into code by a simple turn of the crank on an automated generating tool. I didn't buy it then and I sure don't buy it now. The reason why is because once you specify models with sufficient granularity to be automatically turned into code, the graphical symbols in your modelling language become isomorphic to keywords in some programming language, and your programmer-replacing code generator becomes a compiler. As for Bret Victor... Programming is hard because you are trying to reason about not just the future of a dynamic process, but all possible futures of that dynamic process. That's way too much information to be represented in a visual manner for all but the simplest of systems, and it's why visual programming tools have been met with spectacular failure outside of constrained niches (e.g., LabVIEW, Max and its relatives).
• chis 9y ago
  Does anyone work in the field of formal verification? I’m a senior in school and always enjoyed the actual “computer science” more than coding itself. I’m gonna end up at a google/Microsoft type place programming webapps unless I find something else to do in the next couple months. I guess my question is just: is it a worthwhile career, and is the field growing?
  • jahewson 9y ago
    Microsoft Research has a group which explores tooling for software engineering: https://www.microsoft.com/en-us/research/group/research-in-software-engineering-rise/?from=http%3A%2F%2Fresearch.microsoft.com%2Frise https://www.microsoft.com/en-us/research/group/research-in-s...
• Aeolun 9y ago
  I don't know. I think the problem with software is that as we become able to do certain things with it, people realize they can do that and then want to do more. Ad infinitum this adds up to hopelessly complex software.
• zubairq 9y ago
  For me, it was nice to see Chris Granger (now working on Eve at witheve.com) and the Light Table guys get recognition for Light Table influencing Apple. To quote: "The default language for making new iPhone and Mac apps, called Swift, was developed by Apple from the ground up to support an environment, called Playgrounds, that was directly inspired by Light Table."
• 3131s 9y ago
  "a software developer who worked as a lead at Microsoft on Visual Studio, an IDE that costs $1,199 a year and is used by nearly a third of all professional programmers." It's tangential to the article, but is that really true?
• vssr 9y ago
  Even though this article resonates with me, I think it portrays everything much too glamorous. I wish the subjects described were the only source of problems. I suspect that in reality, most mistakes have quite 'simple' causes. Some observations: - By putting an abstraction layer in between, people visually creating applications, the problem is pushed to the layer below and new problems will be introduced. - Supporting intricate, bespoke functionality in a visual environment will be incredibly hard and error-prone. - If you have trouble thinking about how your software will run, you should run it on a computer instead of your brain. I.e. continuous builds, debuggers and sandboxes. - Pushing for deadlines and using prototypes as production software is part of this. - Those millions of lines of codes usually include a number of Linux kernels. - Before getting to all the fancy stuff and visions about the future, why not first: --- Get all software unit tested / test driven. --- Get all software functional tested / behaviour driven. --- Use domain driven techniques to close the gap between 'reality' and code. --- Create truly comprehensive tests and testing environments for areas that matter.
  • imtringued 9y ago
    >- Those millions of lines of codes usually include a number of Linux kernels. Yes. They didn't write the majority of the code themselves. Here is a repository that shows how much opensource software is inside a BMW i3 https://github.com/edent/BMW-OpenSource https://github.com/edent/BMW-OpenSource
• kwhitefoot 9y ago
  WYSIWYG has been mostly a disaster. We now have several generations of people who 'paint' documents instead of writing them and styling them. Every paragraph has its own explicit style. It's next to impossible to render such documents to a different published format because nothing is tagged to explain why it looks the way it looks. I was at least as productive writing in Wordstar 35 years ago as I am now in Word 365 or whatever the current name is.
• kazinator 9y ago
  A programmer should be able to dive straight into code and get it right the first time, up to a certain level of complexity of problems. I'm not going to say that the bigger the problem you can solve just by throwing code at it the better the programmer you are. But it speaks well for you; you have an advantage in an certain dimension. If I can visualize the solution, see all the cases and debug it in my head, why not go to code? We should encourage that; the more you practice taking a problem straight to code, the better you get at it. Just people have to be reasonable about it; don't try to just code something whose complexity is two orders of magnitude out of the ballpark for that. Currently I'm grappling with the design of compiling functions with nested lexical scopes. I haven't written any code on this for a couple of weeks, but I have some box and arrow diagrams representing memory and pointers. I've mulled it over in my head and have hit all the requirements. I have a way to stack-allocate all of the local variables by default, and hoist them into the heap when closures are made. I have kept in mind exception handling, special variables and such. Amid all this thinking, I barked up a few wrong trees and backed down, thereby avoiding making such mistakes more expensively in coding.
• sjm 9y ago
  This seems over the top to me. Everything has issues, and everything is increasingly complex, not just programming. Take any industry and over a long enough time-span I'm sure things have also increased in complexity in drastic ways. Sure, programming is relatively new, and we are ramping up fast, but we already have vastly complex systems, tools, and infrastructure relying on programming which has incredibly impressive uptime and efficiency. Yes, people will die from errors in the code of autonomous cars, but at the same time can anyone argue that autonomous cars won't be significantly safer than us? The argument here seems to be that it's dangerous if the programmers relying on StackOverflow to copy/paste solutions work on real problems without "stepping up". I think that's like someone suggesting a bricklayer would suddenly be in charge of designing blueprints for a 150 storey skyscraper. They are different jobs performed by people doing very different things. They may write code in the same language, but they're not in the same profession.
• sharno 9y ago
  After reading the whole article, it seemed impressive .. Although didn't like his way of writing so simple ideas in a very very very long article. Anyway, TLA+ and Formal Methods seem a promising thing and definitely need to check that out. I totally agree with him with the way we are not giving a good weight to planning especially for applications that need robust security and safety. Especially after the appearance of Agile methodology and alike. (no system is perfect anyway) But definitely we need more of that verification and we don't need it in the esoteric way they mentioned but in the easy way that allows every programmer to use without so much complexity. Maybe tooling around something like TLA+ could make it easier to understand. People in here though say that it's not that hard but it's not beneficial in every single situation just when you have complex algorithms. I got convinced though with another idea that's easier to apply at least for now, using type systems (type theory) through using a programming language with sound type system (Facebook is making nice progress in that) on the front end FB made ReasonML , a language derived from OCaml to generate javascript. It really erases a whole set of bugs by getting a good type system like that. I'm learning these days OCaml and Reason. New languages as Rust are doing great too. I think writing code is improving these days but it'll get definitely better in the future as we understand more about how we actually do it. The field is just around 70 years old and it's still in its infancy I think.
• YeGoblynQueenne 9y ago
  >> The whole problem had been reduced to playing with different parameters, as if adjusting levels on a stereo receiver, until you got Mario to thread the needle. With the right interface, it was almost as if you weren’t working with code at all; you were manipulating the game’s behavior directly. This sounds remarkably similar to the ambition of the Logo language (from 1967): https://en.wikipedia.org/wiki/Logo_(programming_language) https://en.wikipedia.org/wiki/Logo_(programming_language)
• jasonrhaas 9y ago
  Like some others have said, I think that the specific tools they mentioned for "model based programming" are not the be all, end all, solution. However, I agree with the very high level premise of this article, that programming will continue to evolve to higher levels, and eventually "writing code" may be abstracted all together. We have already been moving towards this approach for quite some time, even though the author doesn't mention this. If you are going to build a web app or API today, do you just start writing code wily nily? No, of course not. You look for frameworks and proven/established ways of doing this. We're practical, we don't want to re-invent the wheel (unless its a side project). I've recently built an event based API for a client, and much of the work is not "writing code", but figuring out the right tools for the job, based on the requirements of how I believe the tool should work. A lot of it is plugging in frameworks and tools that already exist (and are established), which mitigates (but doesn't solve completely) the question of using complex/untested code. For example, most people use take advantage of TCP or HTTP for a web app. Do we test that low level code? Of course not... its already the most tested code in the world. I think there is a danger in writing a lot of "custom code" as I like to call it, because then you really are introducing brand new functionality, that potentially has never been tested before. You can and should test your code, but often that will fall short, because you (or your team) cannot possibly test every imaginable scenario the code will face. My general belief is this: the programming of the future won't involve much programming at all, it will be more like "system architecture", where you pick and choose the tools to meet your requirements. In the world of open source and AWS -- all the building blocks are there, but its your job to figure out how to put them together.
• BerislavLopac 9y ago
  "Since the 1980s, the way programmers work and the tools they use have changed remarkably little." On one level this is very wrong -- since that time we have introduced and improved numerous amazing tools like Internet and its family (protocols etc), distributed version control systems, CI systems and Stack Overflow, to name just a few. On another level it is close to truth, as we still do most of the coding in various text editors -- but not for a lack of trying to find something better. If we found something that would provide the same balance between simplicity and power, we would be more than happy to switch.