Hacker News Reader

Comment by NumberSix | Hacker News Reader

Both "Uncle Bob" and the author are selling extremely complicated, cumbersome, expensive ways to develop software -- great for them as consultants if they can pull it off, not necessarily great for their customers. Giant near monopolies such as Microsoft or Google can afford these methods, may even benefit from this sort of super-bureaucratic "gold plating" of software and certainly do benefit from convincing small potential non-monopoly competitors to adopt these slow, expensive, bureaucratic methods that smaller firms cannot afford (they run out of money trying to create perfect software instead of software that works and gets the job done).

View on HN

Perhaps if the methods are sound (even if expensive) then someone can step up and make tooling or refine them so the methods are more accessible to smaller firms. Uncle Bob's opinion's might be discouraging people from exploring them and finding ways to drive down the cost of adopting these better methods.

> Perhaps if the methods are sound (even if expensive) then someone can step up and make tooling or refine them so the methods are more accessible to smaller firms.

To his credit, Hillel is trying to evangelize (in general, not directly through the post linked) a particular tool (TLA+) whose creator (Leslie Lamport) wants to do exactly this. I don't know how big Hillel's employer is, but from what I understand it's nowhere near the biggest engineering firm in number of technical employees. Lamport's current objective with TLA+ is to get people to learn concepts for formal description/specification of systems, and he happens to provide an effective tool for testing those system specs.

Check out his TLA+ tutorial at https://learntla.com.

If you want an example of solving concurrency issues, jump to here: https://learntla.com/concurrency/processes/.

We have about ten engineers, so nowhere near the size where people consider formal methods "appropriate". Nonetheless it's still been incredibly useful for our work.

I'm a pretty huge evangelist of TLA+, but I don't think it's the silver bullet of software correctness. It just happens to be the tool I'm most familiar with and the one I thought could benefit most from a free guide. If people start widely using TLA+, I'll be ecstatic. If people ignore TLA+ but start widely using Alloy, I'll still be ecstatic. Software correctness is a really huge field and there's lots of really cool stuff in it!

Speaking of making methods more accessible, I'm working on a tutorial about Stateful Testing. Hypothesis (https://hypothesis.works) is an absolutely incredible property-based testing library for Python, and I think it could potentially make PBT a mainstream technique. One of the more niche features is that you can define a test state machine that runs by randomly selecting transitions rules and mutating your program state, then running assertions on the new state. It's really neat!

Perhaps as people who call themselves "engineers" we should move away from the idea that "gets the job done" is good enough? Especially when we have security breaches left right and center.

There is no obvious connection between the methodologies peddled by "Uncle Bob" or the author of the piece and security breaches. They are not claiming to be computer security experts. How exactly are unit tests or code reviews or similar rituals supposed to have prevented the numerous breaches by Julian Assange and his WikiLeaks associates, especially when most of the information appears to have come from insiders with authorization to access the data? (for example). In the Bradley/Chelsea Manning case the government has consistently implied that Manning had authorization to access the vast State department archive of diplomatic cables, as implausible at that seems. I don't see how unit tests or code reviews would have prevented John Podesta from clicking on an obvious phishing link. :-)

Reply on news.ycombinator.com