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

Software, in general, is hundreds to thousands of years behind metalworking as an engineering discipline.

Most software is still made like early firearms: each piece uniquely crafted one at a time from scratch.

We don't even know how to measure the quality of software, let alone how to systematically improve it.

I wish Apple's software was better, but I feel the same way about everyone else's software too.




This, I feel, is so accurate and is why I bristle when people call me a "software engineer". I do not feel like an engineer as I went to a university with many engineering degrees (my degree was from the mathematics department) and I have friends who are actual engineers (not in the train-sense, in the "constructing things" sense). Very little of what I do in software conforms to what I would consider engineering practice.

I'm not suggesting that there aren't software developers who construct software with an engineering mindset. I just see so few of them.


I went to school for computer engineering with greater emphasis upon hardware and over the years I've tried to approach software the way that I've learned how reliability is increased in hardware and electrical engineering, and the business drivers are nothing alike between the two worlds to me on top of the technical differences in disciplines.

When we write ASICs in HDLs, most commercial designs have at least 10 to 100 times as many lines of code for test harnesses compared to the actual design. I've never seen a general commercial software product with anywhere near that much test code in my life (SQlite included perhaps). Furthermore, much of what allows hardware testing is through problem spaces being enumerable (or at least approachable on a statistical basis similar to how memtest works with various bit patterns aimed at different failure modes) and with cross-disciplinary lessons (materials sciences, chemical engineering, etc.). The closest we have in software is the functional programming test ecosystem, especially with Haskell's QuickCheck. But commercial software typically just doesn't care about software reliability to the extent anyone in real world systems does, and there's probably a lot more people pumping out random code now than there are hard sciences engineers thanks to the accessibility of modern software and computers. Combined with software developers as a community being more fashion driven than Milan, London, New York, or Paris we're constantly reinventing the wheel. This is both the blessing and curse of modern software.


"commercial software typically just doesn't care about software reliability to the extent anyone in real world systems does"

And there is nothing wrong with this! I'm not suggesting every line of code should be "engineered". I do think that more projects could benefit from the engineering mindset you are talking about here. Operating Systems for example.


I like this way of viewing software development: as an engineering field that is just in its infancy. Makes me excited to see what the future holds.

That said I disagree that Apple's software is bad. Sure some of it is simplistic and lacks features that some third parties have adopted, but I have never found it to be lacking in either design or usability and it's always been very stable. I sometimes wish they would utilize more flourishes of their own design language in their software, but overall I find it of good quality.


What would the point of software development be if it weren't uniquely constructed? We already have the technology to make copies. I'm not sure where you're going with this.


Actually software can be repeatedly created with 100% accuracy.

Writing software is creating the design of a gun. Not the construction.


Perhaps I misunderstand you, but writing software is not like creating the design of a gun. Creating an algorithm is like creating the design of a gun. You can implement an algorithm poorly, and you could build a gun from a blueprint poorly, for example, using a soft metal. I am not trying to be pedantic. I genuinely do not understand your point.


The specification of an algorithm is the code. Other ways of defining an algorithm is simply a useful but leaky abstraction.

Once you understand that code is the (highly detailed)design, a lot of the reasons why software is so hard to do well makes a lot more sense. Compiling the code or running in a vm is the construction.

It explains why estimates are hard, and why software is not something pump out like manufacturing line easily.


Ok, I agree completely




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

Search: