Hacker News Reader

Comment by VLM | Hacker News Reader

I have some engineering background and you only have engineers in stable predictable fields. You can predict quite accurately the failure load of a bridge truss or a transistor and its easily testable and the whole process can be simulated and verified top to bottom.

My guess is the wedge to bring in engineering would be network operations, classic operations (not devops which just means we're gonna pencil whip the ops responsibilities). Maybe large data center operations (thermal, electrical loads, UPS, etc) is amenable to engineering workflows.

Software is simply too unpredictable. Both in development and operation. Software is still in the "greeks and amber and rabbit fur experiments" stage of electrical engineering.

View on HN

Software is unpredictable because there is little demand for predictability. As it is a trade-off, predictability requires experience. Inexperienced application of methods to enhance predictability is expensive.

Speaking from experience:

- Isolate state in modules (micro-services)

- Focus on systems language first, external behaviour second, implementation details last.

- Design systems to fail and fail fast.

- Do not adhere to Postel's law. Be strict in what your systems accept. This forces the systems designer to create a language which is extensible.

And general advice for teams:

- Consistency is the most important factor in success. Choose rarely and choose wisely your: languages / eco-systems / OSes / cloud services / frameworks. Change based on requirements, not HN popularity.

The ethical and competency attributes are still relevant. Particularly with respect to actual engineering (architecture of the overall solution) aspects of logic systems development and deployment.

I think one of the main problems with ethics is the abstract nature of software and development. Let's say you create an encryption algorithm. That algorithm can be used by terrorists and pedophiles or it can be used by banks and civil disobedients. Or let's say you create an encryption breaking algorithm. That algorithm can be used by law enforcement and the judicial system or it can be used by identity thieves and oppressive governments. Are you as the developer responsible for all those uses? It is hard enough to know how your employer will use your code in the future, but it would be literally impossible for any open source software.

This kind of argument applies to anything, even paper. Encryption is just a tool. A pipe can be used to hide and carry water, it can also be tampered with to poison someone or conceal explosives.

Which is why we don't force an ethical code on those producing pipes. We instead decided to regulate their finished product. However if someone on HN suggests regulating encryption, they aren't met with the most open arms.

You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. It's not that it can't be done. It's the market is not suitable for that sort of development. It's a management problem, not a software engineer problem.

There are a huge number of combinations of various statements that have to be iterated over meticulously. If you want to write tests for each and every one of these conditions, it's going to eat a ton of time to do just that and hence add tons of cost to your project. Developers use intuition when dealing with logic, and they make mistakes or don't understand all the possibilities that could occur... because the brain is limited like that. You can't make them not do that. You can just test for it after the fact and fix problems that are identified, that potentially adds huge cost if you are looking to make it fully predictable.

Lots of testing happens in production systems. Especially in open source software. Or during implementation of some library. Those are identified and fixed when identified. To do that within a single effort will add huge cost to the projects.

"You can make software a predictive profession, by adding an order of magnitude of cost to every software development effort. 10x. "

This is a recurting myth. The field of high-assurance software delivers it on a regular basis in regulated markets. They built tools and reusable modules that drove costs down a lot. Still high cost vs throwing crap together.

So, methods were invented far as the 80's to get most of those benefits on the chesp. Cleanroom methodology got very low defects with cost modifier ranging from cheaper to 20 or so percent more extra. That debugging & hard-to-change codd were greatly reduced offset upfront cost. LOCK secure kernel reported about 38% extra cost with full, formal verification & leak prevention. Altran/Praxis does it today for their clients with a mix of Z, Ada, and SPARK for claimed 50% premium. None of these are "10x" higher. Maxed out at 1.5x for most. Market can bear that.

Only proven weakness of highly-assured development is time to market. Features do take longer to build if verified thoroughly. Medium-assurance like Cleanroom has some slowdown but acceptable. Less debugging and breakage by extensions offsets that, too.

  This is a recurting myth.

"Comprehensive formal verification of an OS microkernel" by Gerwin Klein et. al. (2014) [1] reports that it took 20 person-years to perform a comprehensive formal verification of the seL4 microkernel, which was designed, coded, documented and tested in 2.2 person years.

Did they mess it up and take 19 person-years longer than they needed to? I don't know much about this stuff but I thought Klein's work was pretty state-of-the-art? Are there better ways of doing this stuff?

[1] http://www.nicta.com.au/pub?doc=7371

I already told you what it took in numerous projects plus one company's regular work to deliver low-defect software. Vastly lower than that. That means something is missing in either your data ir mine. Thing is, the NICTA papers clearly tell us why:

1. They were mathdmatically proving equivalence of spec, security policy, C code, and assembly. Latter two were state of the art methods requiring more time and brains. Not necessary in most projects to achieve low defects or 0-days.

2. The methods were new. When that happens in formal developmemt, most of the work goes into building tooling and even figuring out how to apply the methods to the class of problem. The seL4 and L4.Verified reports said exactly that predicting that reuse of that tooling would drop cost dramatically. It did drop to a quarter later with COGENT. LOCK, Cleanroom, Praxis, etc reused existing tools and methods where possible to avoid huge costs.

3. Cleanroom, Eiffel, Ada, or even Haskell all cost similar to regular development in commercial use despite knocking out many issues more easily. That they achieve low defects and cost should already establish my claim (strong QA is affordable) as baseline.

Just a note, looking at the way most companies I've been involved with handle RF testing, it still feels like some electrical engineering is at a premature stage also.

Testing a transistor is the equivalent of testing an if statement. Both are trivial. The difficulty comes from testing multiple of these components acting in sync. Let's be honest, it's sometimes not worth the return on investment to test outside of your requirements.

If software has potential to injure someone, I would hope that it's been tested to similar specifications that hardware is tested on.

> Software is simply too unpredictable. Both in development and operation

You could make it much more predictable if the developer had the legal authority and obligation to sign off on all software. Fuck you I'm not putting my name on that, if you fire me I'll raise a stink about you trying to coerce me into putting my name on something unsafe.

This really isn't needed in most cases though.

Reply on news.ycombinator.com