Hacker News new | comments | show | ask | jobs | submit login

> If you know exactly what you are doing (i.e. you have a

> deep understanding/knowledge of these models), there is

> no reason for you to observe some unexpected failures.

It's not bugs that doom projects, it's misunderstandings.

Most software fails because it doesn't meet it's users' requirements. Because there's so many possible ways to write a program, and it's impossible to get an upfront specification that captures all of the needed detail, we end up building things that aren't fit for their intended use.

This is a big difference between us and other engineers. In most cases their requirements are well-understood by both the builders and the users. Build a bridge from X to Y that can carry 20,000 cars an hour, that will withstand a 9.0 earthquake, etc. That's why the models are so key, their job is figuring out how to make objects to meet those requirements.

Software's advances come through either better methods of capturing requirements, eg agile programming, together with better tools that make it easier to prototype and iterate on a product to figure out what users really want.




> In most cases their requirements are well-understood by both the builders and the users.

Software has the luxury of the ability to have rapid change in the hands of users. Web startups are a good example. Even desktop software is a good example. Generally you don't want to apply a strong engineering model to them because the engineering process is costly in time and people. Software on a submarine or for the disk brakes on a car is not a good example because the rapid change can't be cheaply and transparently pushed to the users. Those systems require engineering.

For material products, show me examples where one does not HAVE to get upfront specifications. How would you release early and iterate on an MP3 player or a stove or shoes? The exceptions I can think of are food and landscaping.

Systems (material and software) are engineered because they HAVE to be engineered, not because engineering is inherent in material products and absent in software products. If the system does not require engineering (for safety, cost, risk) then it doesn't look like a good candidate for engineering. Do you engineer your dinner? I don't but NASA does for their astronauts.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: