4 ms·

I never did any mechanical engineering so I trust your statement. It's still a good example when trying to convey the complexity of software to people who don'

by doc4t 14y ago

I never did any mechanical engineering so I trust your statement. It's still a good example when trying to convey the complexity of software to people who don't understand computers since most have an idea that space shuttles are very complex (which they of cause are) My point was that that testing all possible combinations of how your app can execute is next to impossible unless you are willing to cough up a serious amount of money for rigid mathematical proving. Which would then make it too expensive.

krschultz 14y ago
I think it does a disservice because it overlooks the fact that people have figured out how to solve these problems. All engineers are human. Whether you are working on a space shuttle, an airliner, a nuclear power plant, or an iPhone app, you are a human. Humans make mistakes. Humans overlook things. So how do we engineer really complex systems with hundreds or thousands of lives at stake to an exacting standard - knowing that the engineers are human? The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process. I know a lot of guys who love to wrench on cars. They swap parts, add horsepower, change out the suspension, etc. They can build a really fast car. But that's not mechanical engineering. They are mechanics. In a lot of ways writing software is like that. Glue together some libraries and APIs the same way a tuner supercharges an engine. But that isn't engineering. Obviously we don't need the rigour of the space shuttle to make an iPhone app, but if your application calls for that complexity (or your budget/liability is large), then you need to bring in the process mechanical engineers have been using for the last 60 years. That means multiple people checking all the code. That means a well planned out arrangement/architecture. That means testing the individual parts thoroughly and the whole system together. And it means very specific configuration managament of every dependency. It's not impossible, it's just not the willy-nilly fun part of hacking stuff together. It's the ugly paperwork inducing lame part of working in a big company. But that process if done correctly helps catch mistakes.
- doc4t 14y ago
  "The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process." I agree. I'm not sure it ever will. But comparing software to a car and the relationship between the buyer and seller is too simplified. Software have bugs. Many more bugs than cars. Because it's not tested properly. Which we don't do because no one would buy it at the price which comes from proper testing. You can accept this and write your contract accordingly or you can sit down, muck and be disappointed when it fails. I'm not saying it's right - it's just how things are.
- cicero 14y ago
  You can build software as reliable as a car, but that's not the issue. You cannot build software with all of the features desired by management in the time allotted and also make it robust. It's a matter of priorities, and robustness is not Adobe's priority. Although you're right that for some projects, the poor quality is because it's more fun to just hack it together, but for many, it's a matter of business priority. I've worked on projects (avionics software) that had the rigor that you describe. I've also worked on projects where the developers consistently tried to add robustness, but management kept redirecting them to add more features.

by doc4t 14y ago

krschultz 14y ago

I think it does a disservice because it overlooks the fact that people have figured out how to solve these problems. All engineers are human. Whether you are working on a space shuttle, an airliner, a nuclear power plant, or an iPhone app, you are a human. Humans make mistakes. Humans overlook things. So how do we engineer really complex systems with hundreds or thousands of lives at stake to an exacting standard - knowing that the engineers are human? The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process. I know a lot of guys who love to wrench on cars. They swap parts, add horsepower, change out the suspension, etc. They can build a really fast car. But that's not mechanical engineering. They are mechanics. In a lot of ways writing software is like that. Glue together some libraries and APIs the same way a tuner supercharges an engine. But that isn't engineering. Obviously we don't need the rigour of the space shuttle to make an iPhone app, but if your application calls for that complexity (or your budget/liability is large), then you need to bring in the process mechanical engineers have been using for the last 60 years. That means multiple people checking all the code. That means a well planned out arrangement/architecture. That means testing the individual parts thoroughly and the whole system together. And it means very specific configuration managament of every dependency. It's not impossible, it's just not the willy-nilly fun part of hacking stuff together. It's the ugly paperwork inducing lame part of working in a big company. But that process if done correctly helps catch mistakes.

doc4t 14y ago
"The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process." I agree. I'm not sure it ever will. But comparing software to a car and the relationship between the buyer and seller is too simplified. Software have bugs. Many more bugs than cars. Because it's not tested properly. Which we don't do because no one would buy it at the price which comes from proper testing. You can accept this and write your contract accordingly or you can sit down, muck and be disappointed when it fails. I'm not saying it's right - it's just how things are.
cicero 14y ago
You can build software as reliable as a car, but that's not the issue. You cannot build software with all of the features desired by management in the time allotted and also make it robust. It's a matter of priorities, and robustness is not Adobe's priority. Although you're right that for some projects, the poor quality is because it's more fun to just hack it together, but for many, it's a matter of business priority. I've worked on projects (avionics software) that had the rigor that you describe. I've also worked on projects where the developers consistently tried to add robustness, but management kept redirecting them to add more features.