5 ms·

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and

by fitzn 5y ago

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to think about things.

dr-detroit 5y ago
Undergrad CS profs are teaching everyone that theres "Nothing new under the sun."
habitue 5y ago
Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering. I would guess many of the best practices in bridge building in the modern day were developed in the last 70 years. I think it's that engineers of physical things have many more hard constraints they have to wrestle with, and software engineers largely don't. Your code doesn't need to obey the rules of gravity and chemistry and materials science, it just needs to somehow accomplish the task. And you see those best practices in the places of software engineering where there are hard constraints: cryptography. high performance code. realtime systems. It's not just a senior engineer's opinion whether you should use ruby or C if you're writing the firmware for your race car. If you use md5 to hash user passwords on a major site, you'll be hung from the rafters.
- Drew_ 5y ago
  > Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering. Is it actually anything like civil engineering? To my knowledge chip engineering revolves around yield. There's no such analogous concept in designing buildings that can only be reasonably constructed correctly 70% of the time and attempting to reuse the bad buildings for other projects.
  - habitue 5y ago
    Sure, and civil engineering is really different from chemical engineering. But those are minor compared with the differences between physical engineering disciplines and software engineering. Software engineers: - cost of components is $0 (use one class or split into 2, there is no cost metric to decide) - physics don't apply to components (we can't use this doping agent because X or Y. We need to move the factory to an area of low seismic activity to improve yields etc.. etc..) Basically, physical engineers have so many constraints, solving the problem is the hard part. Software engineers have so few constraints, usually solving the problem is the easy part, and we have time left over to argue about abstract cleanliness concepts like composition vs. inheritance and such. (Again, this is the rule, the exception is problems like "We need this service to do 2 million requests per second", and there we don't argue about functional vs. OOP, you do anything you can to hit the number)
    - Drew_ 5y ago
      Well I think this is just a case of easy Software Engineering vs hard Software Engineering where the requirements are hard to satisfy. Most of the industry does easy Engineering and that's what we talk about for the most part. The part of the industry that does hard engineering (the largest orgs, developers of mission critical systems like weapons) keep mostly quiet about how they solve their problems because that's a trade secret or highly classified.
  - 8note 5y ago
    Buildings are constructed correctly closer to 10% of the time, I assume. The ones built incorrectly still get used, just with lower lifespans and are more likely to run into issues.
sidlls 5y ago
Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc. Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to ask why or whether. I think we'll automate away much of software engineering (likely with very poor, inefficient, and buggy implementations) before it matures enough as an industry to be actual engineering. Engineering (and the science behind it for that matter) advances from curiosity and a healthy skepticism, not the rampant ego-driven self-promotion that runs through SE.
- julianlam 5y ago
  I feel like I already spend 90% of my day gluing together various disparate APIs. Is this the logical conclusion to software development? I adore the craft-like parts of software dev, wouldn't trade it for anything.
- pjmlp 5y ago
  What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC
  - zdkl 5y ago
    Define "specifications" and "conform" in terms that I might hear from a non technical client.
    - wheelinsupial 5y ago
      The engineer is responsible for taking non-technical language from the client and turning it into technical engineering specifications. Why does this fall to the client in software?
    - 5y ago
lou1306 5y ago
Furthermore, there are far fewer physical constraints in software, so the range of possible designs is dramatically wider. (Actually I dare say that sotware itself has no physical constraints at all: software artifacts and software executions do.)
- JohnWhigham 5y ago
  Which is why I don't buy the "software has only been around for 70 years so give it time" argument. Software has nothing to be grounded in like other engineers do with physics. It's most likely always going to be endless cargo culting.
  - choeger 5y ago
    That's simply not true. Software is grounded in mathematics. Most people just try to ignore that fact for convenience. There are, for instance, famous books written about which errors can be proven to be absent in your program and how (vulgo typechecking). There is a huge amount of research about data structures and their internal logic (and at least one, very weird observation about the meaning of the derivatives of data structures). And I don't need to mention complexity theory, do I? Just because a huge part of the practitioners ignores the scientific base of our discipline doesn't mean it doesn't exist.
    - TuringTest 5y ago
      As an oficially qualified computer scientist, I can say that software is grounded in mathematics, but this does not imply what you're thinking. *All* formalisms, including mathematics, are in the end nothing but an incredibly precise language to talk about ideas in your head. Programming languages are created for communication, so this is specially true for them. The fact that code has an extremely precise semantics comes from it being a formal system. But its close relation with maths and physics, besides that they are all formal systems, is mainly because mathematicians and physicists were the first to create it; it's mostly a matter of tradition. There are ways to create, use and study software that are closer to language studies than they are to math, and those are legitimate comp-sci too. Non-formal aspects of building software, like which style guide to establish in your organization, are part of the discipline even if you don't use math to study them. Formal proof is a convenient way to check that your detailed, precise assertions are consistent with your initial axioms. This doesn't prove at all that there are no errors in your code, only that there are no contradictions in what you are saying. Your specification could still be wrong, and then you could still be saying the wrong thing in terms of what you intend to say or achieve; and the formalism won't help. It is not surprising that managers gets to decide how software is built in their department. Software is an explanation of concepts with a particular style, and those who set the tone implant their quirks in it. You're building what the manager tells you to build, and end using the same language.
afarrell 5y ago
Also, there isn't that much in the way of scientific grounding. Mechanical engineering has physics as a foundation. Chemical engineering has chemistry as a foundation. What is the scientific foundation of software engineering? I suspect it is a mix of cognitive science, linguistics, and anthropology.
- NikolaeVarius 5y ago
  Math. Which seems that many practitioners are proud of not knowing
  - katbyte 5y ago
    Logic maybe but a very large amount of software written does not use much if any math beyond the very basics.
    - mywittyname 5y ago
      Lots of people in other engineering disciplines don't use math beyond the very basics either. A large amount of parts are designed in CAE software which handles most/all of the mathematics. And in some larger companies, the person designing the part and the person testing the part are on different teams.
  - Epa095 5y ago
    Math provides no answer for a lot of the problems one encounter in day to day software development. It does not help you decide how much test coverage you need,it does not help you decide how to review, it does not help you figure out what features are desired, it does not help you collaborate with the juniors etc etc. I agree that math describes limitation to computer science and formalisation. But software engineering is more than computation.
- choeger 5y ago
  How about math? Complexity theory, all kinds of logic, computational theory, category theory?
MarkLowenstein 5y ago
Programming changes practice quickly and often because it's cheap to do so compared to physical engineering which is slowed down by execution time, high materials cost, and sunk costs. The interesting question is this: would other engineering pursuits (say civil) have just as much chaos and lack of authoritative practices, if changing practices would be equally fast and cheap for them?

by fitzn 5y ago

dr-detroit 5y ago

Undergrad CS profs are teaching everyone that theres "Nothing new under the sun."

habitue 5y ago

Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering. I would guess many of the best practices in bridge building in the modern day were developed in the last 70 years. I think it's that engineers of physical things have many more hard constraints they have to wrestle with, and software engineers largely don't. Your code doesn't need to obey the rules of gravity and chemistry and materials science, it just needs to somehow accomplish the task. And you see those best practices in the places of software engineering where there are hard constraints: cryptography. high performance code. realtime systems. It's not just a senior engineer's opinion whether you should use ruby or C if you're writing the firmware for your race car. If you use md5 to hash user passwords on a major site, you'll be hung from the rafters.

Drew_ 5y ago
> Eh, I mean we've been building computer chips for approximately the same amount of time as computer software, and it's pretty clear chip engineering is more like civil engineering than software engineering. Is it actually anything like civil engineering? To my knowledge chip engineering revolves around yield. There's no such analogous concept in designing buildings that can only be reasonably constructed correctly 70% of the time and attempting to reuse the bad buildings for other projects.
- habitue 5y ago
  Sure, and civil engineering is really different from chemical engineering. But those are minor compared with the differences between physical engineering disciplines and software engineering. Software engineers: - cost of components is $0 (use one class or split into 2, there is no cost metric to decide) - physics don't apply to components (we can't use this doping agent because X or Y. We need to move the factory to an area of low seismic activity to improve yields etc.. etc..) Basically, physical engineers have so many constraints, solving the problem is the hard part. Software engineers have so few constraints, usually solving the problem is the easy part, and we have time left over to argue about abstract cleanliness concepts like composition vs. inheritance and such. (Again, this is the rule, the exception is problems like "We need this service to do 2 million requests per second", and there we don't argue about functional vs. OOP, you do anything you can to hit the number)
  - Drew_ 5y ago
    Well I think this is just a case of easy Software Engineering vs hard Software Engineering where the requirements are hard to satisfy. Most of the industry does easy Engineering and that's what we talk about for the most part. The part of the industry that does hard engineering (the largest orgs, developers of mission critical systems like weapons) keep mostly quiet about how they solve their problems because that's a trade secret or highly classified.
- 8note 5y ago
  Buildings are constructed correctly closer to 10% of the time, I assume. The ones built incorrectly still get used, just with lower lifespans and are more likely to run into issues.

sidlls 5y ago

Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc. Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to ask why or whether. I think we'll automate away much of software engineering (likely with very poor, inefficient, and buggy implementations) before it matures enough as an industry to be actual engineering. Engineering (and the science behind it for that matter) advances from curiosity and a healthy skepticism, not the rampant ego-driven self-promotion that runs through SE.

julianlam 5y ago
I feel like I already spend 90% of my day gluing together various disparate APIs. Is this the logical conclusion to software development? I adore the craft-like parts of software dev, wouldn't trade it for anything.
pjmlp 5y ago
What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC
- zdkl 5y ago
  Define "specifications" and "conform" in terms that I might hear from a non technical client.
  - wheelinsupial 5y ago
    The engineer is responsible for taking non-technical language from the client and turning it into technical engineering specifications. Why does this fall to the client in software?
  - 5y ago

lou1306 5y ago

Furthermore, there are far fewer physical constraints in software, so the range of possible designs is dramatically wider. (Actually I dare say that sotware itself has no physical constraints at all: software artifacts and software executions do.)

JohnWhigham 5y ago
Which is why I don't buy the "software has only been around for 70 years so give it time" argument. Software has nothing to be grounded in like other engineers do with physics. It's most likely always going to be endless cargo culting.
- choeger 5y ago
  That's simply not true. Software is grounded in mathematics. Most people just try to ignore that fact for convenience. There are, for instance, famous books written about which errors can be proven to be absent in your program and how (vulgo typechecking). There is a huge amount of research about data structures and their internal logic (and at least one, very weird observation about the meaning of the derivatives of data structures). And I don't need to mention complexity theory, do I? Just because a huge part of the practitioners ignores the scientific base of our discipline doesn't mean it doesn't exist.
  - TuringTest 5y ago
    As an oficially qualified computer scientist, I can say that software is grounded in mathematics, but this does not imply what you're thinking. *All* formalisms, including mathematics, are in the end nothing but an incredibly precise language to talk about ideas in your head. Programming languages are created for communication, so this is specially true for them. The fact that code has an extremely precise semantics comes from it being a formal system. But its close relation with maths and physics, besides that they are all formal systems, is mainly because mathematicians and physicists were the first to create it; it's mostly a matter of tradition. There are ways to create, use and study software that are closer to language studies than they are to math, and those are legitimate comp-sci too. Non-formal aspects of building software, like which style guide to establish in your organization, are part of the discipline even if you don't use math to study them. Formal proof is a convenient way to check that your detailed, precise assertions are consistent with your initial axioms. This doesn't prove at all that there are no errors in your code, only that there are no contradictions in what you are saying. Your specification could still be wrong, and then you could still be saying the wrong thing in terms of what you intend to say or achieve; and the formalism won't help. It is not surprising that managers gets to decide how software is built in their department. Software is an explanation of concepts with a particular style, and those who set the tone implant their quirks in it. You're building what the manager tells you to build, and end using the same language.

afarrell 5y ago

Also, there isn't that much in the way of scientific grounding. Mechanical engineering has physics as a foundation. Chemical engineering has chemistry as a foundation. What is the scientific foundation of software engineering? I suspect it is a mix of cognitive science, linguistics, and anthropology.

NikolaeVarius 5y ago
Math. Which seems that many practitioners are proud of not knowing
- katbyte 5y ago
  Logic maybe but a very large amount of software written does not use much if any math beyond the very basics.
  - mywittyname 5y ago
    Lots of people in other engineering disciplines don't use math beyond the very basics either. A large amount of parts are designed in CAE software which handles most/all of the mathematics. And in some larger companies, the person designing the part and the person testing the part are on different teams.
- Epa095 5y ago
  Math provides no answer for a lot of the problems one encounter in day to day software development. It does not help you decide how much test coverage you need,it does not help you decide how to review, it does not help you figure out what features are desired, it does not help you collaborate with the juniors etc etc. I agree that math describes limitation to computer science and formalisation. But software engineering is more than computation.
choeger 5y ago
How about math? Complexity theory, all kinds of logic, computational theory, category theory?

MarkLowenstein 5y ago

Programming changes practice quickly and often because it's cheap to do so compared to physical engineering which is slowed down by execution time, high materials cost, and sunk costs. The interesting question is this: would other engineering pursuits (say civil) have just as much chaos and lack of authoritative practices, if changing practices would be equally fast and cheap for them?