Hardly.
I write software for fun, everything from low level drivers up the stack to web apps. My job is engineering mechanical systems more complex than the space shuttle - and with more lives at stake.
The two are not even remotely comparable.
They did it with an almost insane level of attention to detail.
http://www.fastcompany.com/magazine/06/writestuff.html
So it certainly is possible to do.
In a sense, the problem with Adobe seems to me to be the alignment of organizational goals with user benefits, and not software process.
Software is expected to scale by many orders of magnitude in many dimensions. The equivalent would be a vehicle that supports carrying between 1 and 1 million people, can travel anywhere between 1 and 1 million mph, running off fuel between 1 and 200 octane. Physical objects are never expected to support such wide scaling parameters, and yet this is very common in software.
Software is also expected to run on lots of different kinds of hardware with different features and performance characteristics. A rough analogy is a physical design that has to support being constructed from either aluminium or steel.
Since software is more abstract in nature, you'll often hear people saying that they weren't even sure what they were building until version 2. The requirements are also more likely to change during the engineering process. Mechanical things seem more likely to have a well-defined purpose and scope throughout the engineering process.
As for your specific examples, 'different kinds of hardware' is no different than saying my system needs to work at -30F and 130F temperature. Materials behave very differently at different temperatures and we have to account for that. Some metals are weaker in temperatures as high as +25F. That's something you will see all the time.
You are also vastly over-rating the complexity of scaling. It's really not that hard. Are you really going to tell me it's harder to figure out how to scale a web site than it is to build a rocket engine? Because there are about 1,000 web sites out there with millions of users and only about 10 organizations building rockets.
No (which I admitted up-front). But have you ever worked on large, high-availability distributed systems? When you say that scaling is "really not that hard" I'm suspect that the answer is no. It is absurdly more complex than single-machine programming. There may be more people building large websites, but that probably has a lot to do with the fact that a lot more people visit websites than ride on rockets. If you look at the number of support staff needed to run a website like Amazon vs. launch a rocket, I bet they wouldn't be that far off.
I'm not saying mechanical engineering is easy, I'm just saying the software isn't easy either. I also don't think that you can draw the conclusion that because we have 60 years of mechanical engineering process that software should fit into the same processes.
So what's your database system like. Well, we are 1/2 though the transition between A and B, we don't have a DBA so Bob wrote something to create build scripts based on changes made in this file. It's buggy and we are starting to try out C but if you ...
Have you read papers like:
http://www.allthingsdistributed.com/files/amazon-dynamo-sosp...
http://research.google.com/archive/bigtable-osdi06.pdf
http://kowshik.github.com/JPregel/pregel_paper.pdf
http://www.research.ibm.com/people/m/michael/ieeetpds-2004.p...
These papers all describe solutions to "hard real world software problems" and have nothing to do with legacy systems. If you think there aren't hard problems in software, you're probably not working on one.
We have fatigue/vibration, corrosion, and wear. What's the equivalent in software? There is a reason they park perfectly good airplanes in the desert - we can't gaurentee they won't fall out of the sky because it's impossible to perfectly predict fatigue.
And I have issues all the time related to things failing 3 or 5 years after they were built (yet they have a 40 year design lifetime). Metals always seem to find a new way to corrode and bearings find new ways to fail. There is no equivalent to a corrosive, hostile, environment in software.
Not to mention the random things thrown at you in the physical world. If you design jet engines, be prepared for birds to get sucked in (hopefully not too many, and if so, hopefully your pilot can land in a nearby river full of ferries to pickup the passengers). If you design buildings, get ready for earthquakes of unknown size, hurricanes of unknown wind speed, and terrorists with various methods of taking your structure down.
We can't gaurentee anything. In fact we can barely test most of the complex stuff because it's too expensive. Cars are cheap relative to most things. They don't crash 737s to find out what happens or shake an entire city just to ensure that it is built correctly. You have to predict all of this stuff using calculations and it largely goes untested.
Most mechanical components obey underlying physical principles that have linear or quadratic approximations, at least in certain regimes of environmental and other factors. Therefore, we can model the component and we can know when we are unable to model it.
We manage overall system complexity via physical/mechanical modularization, with things to insulate against thermal, mechanical, chemical, electrical coupling. By testing individual components, we have basic assurances on overall system behavior.
Software attempts to do this with "good design principles", but the truth of the matter is that just about any software component in a typical application can completely jack up the global environment for other components, and processes can make OS and environment modifications that completely break other processes belonging to the same user.
Try issuing performance guarantees on an airplane whose fuel pump can set μ0 and ε0 to -1 if the ground crewman that filled the wing tanks was named "Bob Null".
With unit tests and behavioral tests, we can assume basic assurances on individual components working as a whole.
Engineering also has good design principles. One does not make gear teeth perfectly angular (take a look at the Antikythera Mechanism) because it can lead to premature wear and will have poor performance. In fact, there are hundreds if not thousands of kinds of gear teeth, and interchanging them within the same application can have all kinds of long lasting effects. Take a look into any vehicle recall in the past 2 decades and see that nearly every one of them is an edge case bug that slipped by Q&A.
Not accounting for the string null being valid is a bad design principle within the domain of software. Just as using Frozen water as a bearing surface in high speed rotational machines (Hey! It's hard and slippery! It's perfect!) is a stupid mistake, not accounting for valid "Bob Null"s will also lead to premature failure if not for the database but for the business.
We've only been at software engineering for less than a hundred years. We've been at mechanical engineering for a good 2000 (see the aforementioned Antikythera). We might need a few more years to iron out best practices as an industry.
With digital computers, however, the size of the state space that the system can occupy grows exponentially with the number of bits of state in the system, and changing a single bit can result in an explosive cascade of changes to the rest of the system[0]. Accumulated random failures of computer software very rarely lead to a nice, smooth, predictable probability distribution. Software failures are not caused by anything remotely resembling wear and tear.
[0] Please excuse and correct any inadequacies in my autodidactically acquired understanding of information complexity.
I humorously submit "The win32 API" and "The JVM garbage collector" as examples of hostile environments :)
And yeah, software and mech. Eng. ate tricky in very different ways.
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.
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.
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.
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.