I agree. Sadly, software engineering is not engineering. Nobody, out side of safety critical systems, analyses the program structure and makes valid correctness claims for it as part of their quality process.

Software is at a stage that architecture went through before structural engineering really became widely adopted towards the back end of 19th century.

While we have pretty good tools these days that could do formal verification of our software, the process is incredibly time consuming. Moreover, all formal verification can ever do is show conformity to the specification. The specification can, of course, still be wrong. The move from the informal world of business to the formal specification of a system leaves a lot of room for mistakes.

How does a buyer of software know whether one piece of software is higher quality than another? Is there any real way for them to independently judge the quality of the code in most purchases?

My final thought to reflect on is that acceptable quality is enough quality and for most users that is reached fairly quickly. People will tolerate software that is really quite buggy. Games developers are actually giving us relatively deep insight in to that part of the economics. They still make money shipping games that are basically broken.

This point about game development is quite illuminating I think. The reason that most software is quite buggy is fundamentally an economic question - not an engineering question. Generally speaking, people are not prepared to pay for quality. They want enough quality that the software isn't a false economy - and we as an industry largely supply software of that quality.

It's one of these things I find online, especially talking to Americans, is this desire to believe in any wild conspiracy theory that crosses their mind.

A vast conspiracy within the Democrats to deliberately turn off their own power to hurt Trump's re-election chances is just laughable. Extraordinary claims require extraordinary evidence. Who did it? How? and Why? I'm not convinced your why is good enough.

Between 160,000 dead American and him saying "it is what is" - he doesn't need a giant conspiracy to take him down. He can do that all by himself.

Not a lot of great reasons to log into Slashdot these days but honoring Roblimo is unquestionably one of them. The man and his editing calculations will be forever missed ...

This, I believe, is the story of EVERY migration. It's not necessarily that older is better, or "they don't make them like they used to", but that software development is a bug-prone and arduous process that you will not get right the first time.

This is absolutely the case. Software projects are still incredibly risky. You only have to read the Standish Group's CHAOS report to see how risky these sorts of projects from a management perspective.

The fact that the system is still there doing it's job means that the original project was one of the lucky ones that made it through to a somewhat successful conclusion. You need a very good reason to run that risk again.

In general, just upgrading your dependencies and tool-chain is probably not a sufficient excuse. You need some other compelling reason.

He posted a blog post yesterday and it's currently cached but essentially he promises to move BTC from early blocks to do the final verification. This was up yesterday before his stupid wah wah redirect went up. I'm reposting it here in case it's ever removed from google cache (I hate scammers):

If only we had a website the covered this sort of stuff ... oh right, we do! New VPN IP addresses probably take a while for them to identify the traffic on and block. But there are plenty of services like HMA that constantly roll out new ip addresses. So as long as you're a mouse willing to play whackamole with your cat overlords ... Annoying, yes, but that's the definition of the internet in China.

In response to the second part, that is always true regardless of the answer to the first part. Not only are members of the government are treated differently but also their families. The "party" class enjoys many many perks. Unmonitored VPN connections would be laughable compared to their insider trading, disregard for the law and instant attack dogs they routinely utilize.

While you're accepting suggestions, why isn't my aforementioned article linked in the "You may like to read:" section of this page? Those stories seem to have nothing to do with China's firewall yet a simple google search shows a whole slew of those stories on Slashdot. I think you could get timothy's family to help you track that stuff if you would return his body to them. They only want closure, it doesn't matter if it has to be a closed casket funeral!

If your tester is finding 100 bugs a week, you're doing it wrong. Your underlying quality is much too low. It's much more expensive to find a bug by functional testing than by code inspection. This is because all those bugs need to be fixed and retested. This usually requires a rebuild and other ancillary tasks that drive up cost.

Worse, it's usually a geometric progression with this kind of pattern in that for every hour spent bug fixing, there's a ratio of new bugs introduced that have to be removed by the process. This process repeats until the defect count is acceptable. Even with a relatively low co-efficient of bug introduction, the geometric series usually adds 20-30% additional cost to the development.

This comes back to my earlier point on people ignoring published research because they feel they know better. Do you know there's actually properly controlled scientific trials that actually establish the truth of what I'm saying? Why is your thought superior to this research? Why is this research defective?

Code inspections work best when they're formal with clearly defined roles and clear reporting steps. There have been large scale studies done that confirm this. The research fed in to the development of the Cleanroom methodology pioneered at IBM.

The less formal the structure, the less well it works.

One of my big bugbears with software development as a craft is our failure to really learn from experience. There were lots of studies done on the craft from decades ago that cleanly establish these basic principals. We choose to ignore them because developers feel they know better than published research.

The truth is that people suck at writing software. Even the very best developers in an organisation are not as a good a team of lower quality people that inspects their own output. Teams > individuals.

Honestly, it isn't as corporate as it first appears. Once the roles are defined, the work turns to inspecting the source. It takes a few seconds to cover off that part of the meeting and from there the real work begins.

There are other benefits

One is that everyone has read everybody's source. There's none of this "Only Bill knows that piece of code." The whole team knows the code very thoroughly.

Another is that relatively junior people end producing code just as solid as person with 25 years experience. They end up learning a lot on the way. Do not estimate the tremendous power of that.

My teams enjoy the process and they certainly enjoy not getting as many bugs coming back to bite them in the future when the feature is out in production. Once they're done, they tend to be done and are free to move on to the next feature.

The benefits of having a cleaner code base, fewer issues and more accurate delivery times has a huge affect on morale.

I find this example really odd because Linux is built around a process of a huge amount of code review. They do it differently because they're a distributed team but they absolutely have a rigorous code review process.

Well I'm the head of development at our place so I inhabit both worlds. Businesses like to measure return on investment. By being able to speak that language, I can generally frame activities developers naturally want to do in those terms. This leads to developers getting more of what they want.

You know what developers really, really, really hate? Having to work with technical debt and having no process to remove that technical debt because the program is now "working".

The best way around technical debt is not to put it in to the program in the first place. This process does a sterling job at that. So our developers are generally a pretty happy bunch.

In our organisation, we have teams of six people that work together on their sprint. QA staff are included in this team.

On major features, the team code reviews the feature together in a special session. Roles are assigned. The author is present, a reader (who is not the author) reads the code. There is an arbitrator who decides whether a raised issue gets fixed. This arbitrator role is rotated through the team on an inspection by inspection basis. Finally, there is a time keeper role who moves the conversation to a decision if one topic is debated for more than three minutes.

This process typically finds a humongous number of issues. It takes us about 4 hours of applied effort to discover a bug in pure functional testing. This process discovers bugs at a rate of 1.25 bugs per man hour of applied effort. So if you have five people in a room for one hour, you have applied 5 man hours. You'd expect to find 6-7 bugs. If you include all the stylistic coding standards bugs, this is typically 10-15 bugs per hour.

So while on the surface it looks expensive to have all those people in a room talking. The net result is that it tends to accelerate delivery because so many issues are removed from the software. Better still, the review occurs before functional testing begins. This means the QA staff on the team can direct their testing at the areas highlighted by the inspection process. This further improves quality

It's true that about 50% of the ossies are stylistic issues. But usually we get 1 or 2 bugs per session that present a serious malfunction in the program. The rest could be problems under some circumstances or minor faults.

Team reviews are vastly, vastly superior to pair-programming. There really is no contest.

As a software developer here that likes to fiddle with all languages, the second paragraph from Wikipedia seems to answer your question nicely: "It is a statically typed language with syntax loosely derived from that of C, adding garbage collection, type safety, some structural typing capabilities,[2] additional built-in types such as variable-length arrays and key-value maps, and a large standard library."

So from the first few words someone might know C and desire garbage collection to be handled for them? Golang might be a better selection for them than Java.

Personally for me, the built-in primitives for concurrency make it a great language for tinkering in realms of software design that were once onerous to me. But that's only one of a few of the language's goals.

Maybe a better set of questions would be for an elevator pitch on why someone should use golang? Or perhaps if they have dropped some goals of golang for others as development went forward?

In conversation, I refer to it as golang. You are right on your point about potential for confusion but I don't think your example is apt anymore. Googling for programming go appears to yield only results about golang. Also, it is not without tangential benefits like being able to call Go developers "gophers."

I think when I first started programming Groovy long ago I stumbled upon a website promising that software development was groovy ... that's no longer the case when I google for groovy programming resources.

In short the success of your language is a big enough concern than the name of your language is negligible (with the exception of negative words). The search results will follow.

I am neither a leftist nor a corporate shill. I believe in beating the shit out of private companies that deserve to have the "shit beat out" of them. You need only look at the lengthy history of consumer protection in the United States to find instances where this was and is necessary. Take, for example, Debt Collection Practices. Please, please, please "beat the shit out" of unscrupulous collection agencies. Please "beat the shit" out of the companies that call my grandmother to deliver unsolicited advertisements about a "warranty extension" on her car. There are plenty of private companies that should have this done to them. The issue I take with China's implementation is 1) that it will never target a state owned business and 2) the guidelines are by no means clearly laid out and can be ambiguously interpreted. Who will interpret them? When will they interpret them? Why just in time and by the same state body that made them. Please tell me, how can I prove that my product's advertising does not "Cause detriment to national dignity"?

It's not that binary. The United States has its own truth in advertising laws that, in my personal opinion, are beneficial at both the federal and state level. Slashdot readers are free to go the Libertarian route and claim the free market would alleviate these issues on its own or perhaps point out how downright pedantic it can be at times. But the truth of the matter is that, as a consumer, we only have so many hours in a day to decide which of the thousands of products we consume in a year we should spend our money on. So it does come down to federal guidelines for what is "Grade A" or "Organic" or "Green" when there is a label espousing these properties and there are consumers paying a premium for this notion. Without those guidelines those words will mean absolutely nothing and there will be no way to tell where your product was made, how much cadmium it has in it or whether it is the end result of spewing carbon into the atmosphere. Without similar laws, you wouldn't be able to trust the nutritional information at the grocery store. Is it free speech to claim that my potato chips cure cancer and lead to weight loss no matter how many of them you eat? People will know that I'm lying? Cigarettes used to sooth sore throats. Trans fats used to taste awesome.

Speech used by an individual to express ideas is free speech. Advertisements -- especially advertisements representing a very large organization -- are not. Corporations should not have the same rights individuals have and I feel that free speech is one of those clear cut distinctions. There is a long history of consumer protection everywhere in the world -- learn about your own country's struggles with it. It's not a simple issue and advertisement should not be regarded as free speech.