|
make a program that programs for you and be done with it
|
|
#
?
Feb 21, 2013 12:10
|
|
|
|
| # ? Jun 11, 2024 07:23 |
|
|
Zap! posted:There's a reason why those systems cost a lot of money and take a long time to construct: they have to work drat near perfectly every single time they're switched on. but things like light switches, a lock on a door or Coca-Cola bottles also have to work almost perfectly almost all the time simply on account of there being so many of them Cocoa Crispies posted:software engineering can skimp on validation because the costs of pushing a faulty design are low, especially with online distribution or continuous deployment where the goal is to reduce the manufacturing and distribution costs to zero what if you waste hours of your employer's time with an open source library that turns out to be subtly flawed in a way that makes it unsuitable for its advertised purpose? what if you bring a visitor to your workplace and they steal 1000€ from your employer? with software time should be tabulated just as fully as money
|
|
#
?
Feb 21, 2013 12:54
|
|
|
What your culture really says / Toxic lies about startups' 'culture' in silicon valley
|
|
#
?
Feb 21, 2013 13:33
|
|
|
Win8 Hetro Experie posted:but things like light switches, a lock on a door or Coca-Cola bottles also have to work almost perfectly almost all the time simply on account of there being so many of them Their designs has been proven to be safe, reliable, cost effective, and manufacturable. The abundance of those items is the effect, not reason, of meeting those four design guidelines. If a light switch started a house fire, it would be pulled from the market. If a bottle of Coke became increasingly difficult to manufacture, they'd find a new process or a new material. Engineering is process of optimizing all four of these design guidelines with proof. The proof is in the calculations done to prove the design before a single piece of metal is formed. Software doesn't have the luxury of having reliability calculated before a single line of code is committed. It's is almost the reverse of this. You can't quite prove the reliability of software before the code has been written because the implementation affects the overall reliability.
|
|
#
?
Feb 21, 2013 13:52
|
|
|
MononcQc posted:What your culture really says / Toxic lies about startups' 'culture' in silicon valley owns
|
|
#
?
Feb 21, 2013 14:13
|
|
|
Formal verification is pretty cool stuff but can only be very narrowly applied (provably so, since it overlaps immediately with complexity theory). On the other hand controlling side-effects is still pretty much where things are (successfully) going, which makes many things more tractable, both verification and enabling things like universal transactional code. A bridge being safe does not rely on every bolt in the bridge being perfect, it relies on a larger framework of redundancy, which is hard to achieve in code unless one can achieve proper separation of concerns.
|
|
#
?
Feb 21, 2013 14:21
|
|
|
Zap! posted:Wrong. I agree for the most part, but that's not exactly what I was getting at even if there was no safety concerns and by making some ad-hoc changes to an existing design you could end up with a properly optimized design by chance, there still exists a motivation to follow and keep following proper engineering principles a plastic bottle of cola that costs 20% less per unit but with each unit there's a 10% chance that the neck of the bottle comes clean off when it's closed again after opening it at home would never be accepted, even if it always happened in a completely safe manner. the fault would be too widespread and too visible and the product would fail its requirements on quality
|
|
#
?
Feb 21, 2013 15:06
|
|
|
Win8 Hetro Experie posted:a plastic bottle of cola that costs 20% less per unit but with each unit there's a 10% chance that the neck of the bottle comes clean off when it's closed again after opening it at home would never be accepted, even if it always happened in a completely safe manner. the fault would be too widespread and too visible and the product would fail its requirements on quality in this specific example no, but there are plenty of goods where this sort of tradeoff is done, often when the purchaser and the user aren't the same person. for example, stop & shop's grocery bags tear at the handle if you have as much as a can of corn in them
|
|
#
?
Feb 21, 2013 15:20
|
|
|
Zap! posted:Their designs has been proven to be safe, reliable, cost effective, and manufacturable. The abundance of those items is the effect, not reason, of meeting those four design guidelines. If a light switch started a house fire, it would be pulled from the market. If a bottle of Coke became increasingly difficult to manufacture, they'd find a new process or a new material. Engineering is process of optimizing all four of these design guidelines with proof. The proof is in the calculations done to prove the design before a single piece of metal is formed. Eh sometimes. about half the mechanical guys at work are analytical like this, and the other half are empirical, and we make products that get certified as intrinsically safe and explosion proof. Different companies and different fields probably have different balances, but in practice the two complement each other. In software there are near zero people who lean towards analysis though
|
|
#
?
Feb 21, 2013 15:24
|
|
|
OBAMA BIN LinkedIn posted:make a program that establishes requirements for you and be done with it
|
|
#
?
Feb 21, 2013 15:39
|
|
|
Win8 Hetro Experie posted:I agree for the most part, but that's not exactly what I was getting at You could hit the optimal solution simply by chance, but you don't know if it truly is without doing analysis. That's the sticking point: you must be able to prove that this it is the optimal solution, not just think that it is. quote:a plastic bottle of cola that costs 20% less per unit but with each unit there's a 10% chance that the neck of the bottle comes clean off when it's closed again after opening it at home would never be accepted, even if it always happened in a completely safe manner. the fault would be too widespread and too visible and the product would fail its requirements on quality As you've said, there's no way this would be accepted in the market. So why accepting to ship a flawed product? You're doing high enough volume to use analysis tools like six sigma, so get to it. Manufacturing has been around long enough that we have mature analysis tools to deal with issues. Software hasn't been around long enough to have adequate analysis tools that can determine code quality and reliability. The only way to get to that point is to be like Shaggar and reject everything except your own personal opinions and form the analysis around that. But here's his difficulty: he can't back his initial assumption when a peer reviews his toolset. There's no mathematical constant to work from. Just his posting.
|
|
#
?
Feb 21, 2013 15:40
|
|
|
it's almost like the rules of physics and materials and the real world don't apply to the world of beep bboop computer!
|
|
#
?
Feb 21, 2013 15:43
|
|
|
in software you've got tons of people doing analysis that goes into professional languages and frameworks (c#/java) as well as the software underneath them (oses). if you don't have a lot of resources to throw to maintain the underling linuxes or open sores, you buy that analysis from a real company like Microsoft or, to a lesser degree, redhate. IIS comes with tons of performance counters and easy to use tools and a pile of best practices. Its super easy to know what to monitor and what statistics mean what because it was designed with that in mind. Its designed for server janitors (not developers) to manage. Tomcat comes with some performance counters but they're much harder to get at. There are also kind of some best practices, but its open sores documentation so it can be hard to find and interpret cause a lot of it will assume you understand the code inside tomcat. However, you can buy almost the same level of monitoring tools from a company like redhate OR you can build them yourself OR you can ignore the whole thing if it doesn't matter. Its designed for people who are both server janitors and developers. You are trading the upfront costs of the Microsoft stack for the long running costs of open sores maintenance. If your team is as good as the Microsoft guys in software engineering, you can save yourself money over the long term vs Microsoft licensing. By focusing engineering on the underlying systems you can offload tons of effort from the development of the stuff sitting on top of them. Both tomcat and iis are good application servers that have gone through massive amounts of internal and real world testing. They provide a stable, proven platform on which you can write your own code without having to worry about underlying platform specific stuff. This is why we laugh when someone suggests php or ruby or rails or whatever. those things have been tested and proven to be garbage, are completely untested, or both (ruby on rails). People say "no ones ever been fired for buying redhate/Microsoft" and theres an actual reason behind that, despite what the fad-langers would have you believe. Its the software engineering that's gone into those platforms that people are buying.
|
|
#
?
Feb 21, 2013 15:46
|
|
|
really my point there is that software engineering is possible, but a lot of it is optional if your product doesn't matter (ex: most web "development") TBC makes a porn site and if its down or someone cant view a porn for a few minutes while hes testing in production it really doesn't matter and throwing a pile of expensive software engineering on to his work would be a waste.
|
|
#
?
Feb 21, 2013 15:48
|
|
|
Otto Skorzeny posted:Eh sometimes. about half the mechanical guys at work are analytical like this, and the other half are empirical, and we make products that get certified as intrinsically safe and explosion proof. Different companies and different fields probably have different balances, but in practice the two complement each other. In software there are near zero people who lean towards analysis though Out of curiosity, how much experience do the MEs have that work empirically vs. the analytical? I've seen that as a huge driver for people that work like that.
|
|
#
?
Feb 21, 2013 15:49
|
|
|
Zap! posted:You could hit the optimal solution simply by chance, but you don't know if it truly is without doing analysis. That's the sticking point: you must be able to prove that this it is the optimal solution, not just think that it is. that's not entirely true. you can measure the inputs and the outputs to see if things are working and measure their performance to see how well they are working. with enough points of visibility into a given process you can figure out what code is bad so it can be fixed. these points are tests in development and monitoring in production.
|
|
#
?
Feb 21, 2013 15:53
|
|
|
Shaggar posted:in software you've got tons of people doing analysis ... none of these things that you call analysis here are analytical (all of them are empirical); they could be used as part of a system to verify if a system's actual performance matches what was expected analytically however
|
|
#
?
Feb 21, 2013 15:58
|
|
|
Shaggar posted:that's not entirely true. you can measure the inputs and the outputs to see if things are working and measure their performance to see how well they are working. with enough points of visibility into a given process you can figure out what code is bad so it can be fixed. these points are tests in development and monitoring in production. How do you know that the code you will write is better than the code that the next guy may write? Part of the discussion we are having is the engineering effort that goes into predicting performance and reliability, not measuring and continued support after implementation.
|
|
#
?
Feb 21, 2013 16:00
|
|
|
Zap! posted:Out of curiosity, how much experience do the MEs have that work empirically vs. the analytical? I've seen that as a huge driver for people that work like that. on the mech-e side, probably a dozen years for the most empirical guy and 8 or so years for the most analytical guy (i caught him photocopying chapters from an old textbook to solve some freaky diffeq one day, it was a mixture of  and  )for the EEs, the most empirical guy has been here almost 35 years and the most analytical guy 20
|
|
#
?
Feb 21, 2013 16:02
|
|
|
Otto Skorzeny posted:on the mech-e side, probably a dozen years for the most empirical guy and 8 or so years for the most analytical guy (i caught him photocopying chapters from an old textbook to solve some freaky diffeq one day, it was a mixture of That's what about what I thought the divide would be. The only thing the older engineers analyze is new weird design they come up with. EEs typically have to be very analytical in their designs without too many assumptions.
|
|
#
?
Feb 21, 2013 16:08
|
|
|
Zap! posted:As you've said, there's no way this would be accepted in the market. So why accepting to ship a flawed product? You're doing high enough volume to use analysis tools like six sigma, so get to it. High enough volume of what? The problem is that bottles of coke should all be the same, while lines of code should all be different.
|
|
#
?
Feb 21, 2013 16:14
|
|
|
i just wanted to bbeep boop a computer
|
|
#
?
Feb 21, 2013 16:18
|
|
|
I somewhat disagree that six sigma is a useful quality tool, based on the anecdotes of my brother in law who was a chemist at GE (now uh... "momentive" or something like that) during Peak six sigma i believe the description he used was 3 working neurons per million brain cells
|
|
#
?
Feb 21, 2013 16:28
|
|
|
JawnV6 posted:i just wanted to bbeep boop a computer
|
|
#
?
Feb 21, 2013 16:28
|
|
|
Otto Skorzeny posted:I somewhat disagree that six sigma is a useful quality tool, based on the anecdotes of my brother in law who was a chemist at GE (now uh... "momentive" or something like that) during Peak six sigma yo moto is very heavy on 6S and we're all certified and they give you mad kudos if you go up in your 6S belts. for 90% of the company it's vestigal and annoying, for 10% it is the grease that oils that fuckin' machine
|
|
#
?
Feb 21, 2013 16:29
|
|
|
Zap! posted:How do you know that the code you will write is better than the code that the next guy may write? Part of the discussion we are having is the engineering effort that goes into predicting performance and reliability, not measuring and continued support after implementation. because you test the code and examine the outputs. the idea of "code analysis" is some autismal math major poo poo that doesn't exist. you have to expect something out of the code before you can analyze it.
|
|
#
?
Feb 21, 2013 16:31
|
|
|
re: engineering. girlfriend has been stuck for 20 minutes waiting on the road because the train track barriers or fences that come down when there's a train activated themselves for no reason and snow banks make it impossible to turn around on each side of the road. Now it's a roadblock too.
|
|
#
?
Feb 21, 2013 16:36
|
|
|
Shaggar posted:because you test the code and examine the outputs. the idea of "code analysis" is some autismal math major poo poo that doesn't exist. you have to expect something out of the code before you can analyze it.
|
|
#
?
Feb 21, 2013 16:36
|
|
|
MononcQc posted:re: engineering. girlfriend has been stuck for 20 minutes waiting on the road because the train track barriers or fences that come down when there's a train activated themselves for no reason and snow banks make it impossible to turn around on each side of the road. tell her to get out and push the barriers up. goddamn
|
|
#
?
Feb 21, 2013 16:37
|
|
|
MononcQc posted:re: engineering. girlfriend has been stuck for 20 minutes waiting on the road because the train track barriers or fences that come down when there's a train activated themselves for no reason and snow banks make it impossible to turn around on each side of the road. but nobody's been hit by a train, right?
|
|
#
?
Feb 21, 2013 16:38
|
|
|
Jonny 290 posted:yo moto is very heavy on 6S and we're all certified and they give you mad kudos if you go up in your 6S belts. i work with a couple of guys (1 engineer and 1 product manager) that were former moto people. holy poo poo were they on the loving ball. errything they do is 6∑ to the max and their process control and execution is something to be seen
|
|
#
?
Feb 21, 2013 16:39
|
|
|
Shaggar posted:tell her to get out and push the barriers up. goddamn yo rail lines are huge nazis about people touching their poo poo i got glocks aimed at my facehole by 3 cops when i was walking to work down the tracks at 9am on a saturday morning
|
|
#
?
Feb 21, 2013 16:39
|
|
|
MononcQc posted:What your culture really says / Toxic lies about startups' 'culture' in silicon valley This was awesome and so much resonated with me. Just sucks that we got the short end of the stick since our boss is a thrifty mormon, no luxuries, no beer but all the rest of the lovely startup mentality.
|
|
#
?
Feb 21, 2013 16:48
|
|
|
Hard NOP Life posted:This was awesome and so much resonated with me. Just sucks that we got the short end of the stick since our boss is a thrifty mormon, no luxuries, no beer but all the rest of the lovely startup mentality. lol this sounds loving terrible
|
|
#
?
Feb 21, 2013 16:54
|
|
|
this is your startup this is your startup.... on weed
|
|
#
?
Feb 21, 2013 16:55
|
|
|
Jonny 290 posted:lol this sounds loving terrible I get paid enough to put up with it though and I'm sure that my US coworkers hate it more. At least I get to call the shots down here. I'm about a year away from paying off all our debt and have about 5k saved up to relocate, hopefully sometime next year.
|
|
#
?
Feb 21, 2013 17:15
|
|
|
Shaggar posted:you have to expect something out of the code before you can analyze it. you're operating under a different definition of analysis than the rest of us. analysis tells you what to expect. incidentally, your petulant remarks about back-of-a-napkin arithmetic are telling
|
|
#
?
Feb 21, 2013 17:28
|
|
|
Why write good code when you can just measure it harder. In prod. We'll call that the testing phase.
|
|
#
?
Feb 21, 2013 17:38
|
|
|
Zombywuf posted:Why write good code when you can just measure it harder. In prod. We'll call that the testing phase. i would settle for getting my coworkers to do real profiling instead of printing timestamps 
|
|
#
?
Feb 21, 2013 17:43
|
|
|
|
| # ? Jun 11, 2024 07:23 |
|
|
Otto Skorzeny posted:you're operating under a different definition of analysis than the rest of us. analysis tells you what to expect. incidentally, your petulant remarks about back-of-a-napkin arithmetic are telling got a thumbnail sketch of "real analysis"? i would like to know more, but i am a simple unfrozen caveman, unused to your modern ways
|
|
#
?
Feb 21, 2013 17:43
|
|