|
Writing code has little science behind it. Mechanical engineers can base decisions on physics and knowledge of materials. Software engineers have no such base to stand on. For example you can get rid of all buffer overflows with a compiler flag, but it slows down the software a lot. When is it better to have the safety versus the speed? Is the software engineer the one who actually makes that decision? There is no standard formula you can use to decide that question. Before you can make programming an engineering discipline, there has to be some science behind it. Until then "best practices" is probably the best that can be done and that is just a checklist, not calculated engineering. Another issue is domain knowledge. A programmer can write code for any application, medical, automotive, chemical plant control, nuclear reactor control, aircraft flight control... What engineering principles of software design cover all of those? Certainly there would be some, but each domain has it's own criticalities and requires special knowledge. Instead of teaching beginners to write code it may be necessary to teach them to write medical code, automotive code, etc., or else they would learn the wrong lessons and have to unlearn them later. That specialized training might help turn software development into an engineering discipline, but it would also divide the field into specializations making it much more difficult to find and train people and make it more difficult for programmers to switch fields. The number of specialized types of programmers is huge, everything today is computerized. Maybe the creation of special libraries for each kind of code would bring some standards and uniformity? For example, requiring that you can only write medical code using one of a few approved HL7 libraries, or one of a few medical image processing libraries that are freely available to all companies. Standards and approved libraries might be one way to start turning programming into engineering. It would slow down innovation, but maybe that's a good thing since today a lot of "innovation" is more like customer lock-in. Liability for flaws in code is another open-ended issue given there is absolutely no way to assure there are no flaws in code under all possible circumstances. You can write some math that says a bridge will support a weight load for 50 years if built of the correct materials. You can not do the same for code. Even the tools programmers use mutate over time. Compilers can have bugs. How do you certify a compiler for medical, space, automotive, and all the other applications it might be used for? What about open source software, who is liable for that? There is no such thing as an open source bridge or skyscraper design. |