July/August 2019 issue of acmqueue The July/August 2019 issue of acmqueue is out now

Subscribers and ACM Professional members login here

The Bike Shed

Web Services

  Download PDF version of this article PDF

Error 526 Ray ID: 5276b49b6e40c5c0 • 2019-10-18 01:23:11 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 11, no. 12
see this item in the ACM Digital Library



Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - Metrics That Matter
Critical but oft-neglected service metrics that every SRE and product owner should care about

Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - Tracking and Controlling Microservice Dependencies
Dependency management is a crucial part of system and software design.

Diptanu Gon Choudhury, Timothy Perrett - Designing Cluster Schedulers for Internet-Scale Services
Embracing failures for improving availability

Štěpán Davidovič, Betsy Beyer - Canary Analysis Service
Automated canarying quickens development, improves production safety, and helps prevent outages.


(newest first)

Displaying 10 most recent comments. Read the full list here

rembal | Fri, 26 Dec 2014 20:28:49 UTC

The email case is not one person against a group of experts. It's a case of group of experts vs group of experts, but working in different ways.

One group gathers together and quarells over a standard that will be based on the compromise they reach. It often ends up as a medley of their ideas, as everybody wants to have a say, and the hierarchy of the gruoup is based more on their esteem then their input.

Members of the second group works individually, creating a set of standards. Good standards attract more colaborators, creating a positive feedback loop and weak standards gradually die out. Hierarchy is created ad-hoc.

The second approach is more evolutionary. It makes me wonder how would a living organism look like if it was created by a comitee. That might explain plytapus...

Fred Mellender | Fri, 17 Jan 2014 22:52:00 UTC

The European wheelbarrow used for gardening has a small wheel in front to make the carrying bed low. This means the cargo does not have to be lifted very high to load the barrow. A large center wheel would raise the carrying bed. A small wheel in the center would not work because the front of the barrow would hit the ground when the handles were lifted to waist height. The Chinese barrow was made for long hauls where the effort to lift the cargo is outweighed by the easy in pushing over the distance. The short haul, ease of loading European barrow is ideal for gardening.

Moody | Sat, 11 Jan 2014 05:00:56 UTC

Interesting perspectives in your article. There are many models / metaphors that can be applied in this context. Each one highlights different aspects of the the underlying structural dynamics: 1. Larger organizations typically don't have processes to match skill to task. People with design skills may end up doing testing. Architects may end up in analysis. The metaphor here is of asking the right hand to do a foot's work. Overall architecture and design are critical to the success / failure of the project. These are often relegated to people who are not matched to that task. 2. Missing feedback loops at all levels - a project is a learning process on several fronts - requirements, architecture, design, implementation, testing, deployment. There are missing feedback loops between these stages to change requirements, architecture, design, etc. as the project learns. Tasks tend to be siloed as a way to manage complexity. And those silo walls in complex, dynamic leads to the high failure rates we see in such projects. The metaphor here is driving while looking in the rearview mirror. 3. Project decisions for funding, resources, schedules are often made by people who don't have a good grasp of the dynamic complexity of such projects. And these decisions become rigid milestones where project / process learning is not fed back to change the milestones. The metaphor here is sailing with the sail in a position fixed at the shoreline and not adjusted with major shifts in the wind direction. 4. IT culture tends to be monolithic silo oriented, i.e., individual / group / small team oriented with such entities having an adverserial mindset against each other rather than a cooperative project mindset. The metaphor here is that we lots of lone rangers wanting to do their own hi ho silver away.

This list could go on a bit longer as there are other dynamics at play in this context. Some thoughts for you to consider. Enjoyed reading your article and your insights into IT projects.

Torben Mogensen | Tue, 24 Dec 2013 17:16:51 UTC

One reason a single person (or a small team) can succeed where a large corporation will fail is that the single person will realise that he can't ever complete a complex solution, so he simplifies, challenges assumptions and maybe solves a slightly different (but equally relevant) problem than the one presented to him in the first place. The large corporation will blindly try to implement the complex solutions, creating more complexity on the way, and nobody will dare question the assumptions or solve slightly different problems, because the best way to keep their jobs is to do exactly as they are told. And because of the multitude of people involved, miscommunication will go undetected for a long time, so different parts of the system that don't work together will get layers of patching put on top.

Nearly all successful large systems have started out as small well-functioning systems that have evolved slowly over time. While that can also lead to undue complexity and "baggage", it is incredibly difficult to design large systems from scratch, and in all too many cases such attempts fail miserably. We really only hear about failures of public systems, but there are equally many (and maybe more) failed colossal IT systems in industry.

Claus Gravesen | Mon, 23 Dec 2013 10:59:32 UTC

"The point here is that politicians point to the 1-man wonders and then legislate 10.000-man fiaskos into existence."

So incredibly well put..!

Happy holidays one and all :-)

Mike Small | Sun, 22 Dec 2013 20:48:41 UTC

I think because you don't have friends or colleagues working in that area, perhaps, you're letting a bit of jargon from another industry trip you up. (The use of the word tool maybe is especially confusing.) Brochures, pamphlets, videos, static html etc. is the form that decision aids take from what I've seen of my friend's work. I suppose an expert system could function as a decision aid as well, but I've never heard of one of the foundations who produce them creating such a thing (on their budgets it would not be realistic I expect).

Here's another example of an organization, this one in Canada, who creates such things and has the term in their name: http://decisionaid.ohri.ca/about.html

Here is a sample of one of their decision aids: http://decisionaid.ohri.ca/AZsumm.php?ID=1648

Thomas L. Kjeldsen | Sun, 22 Dec 2013 20:24:01 UTC

Does complying with regulations slow down development?

In Utopia someone will read all relevant laws and regulations and can work as a Verifier during system development, to ensure that the current solution and future plans comply with regulations. Ideally, the Verifier can decide in constant time, but this is most likely not the case. This can slow down development speed because, ideally, every step would have to be verified by the Verifier. With frequent changes to laws and regulations the Verifier becomes even slower. As a consequence, development speed slows down, the overhead gets bigger and the cost increases.

Another approach is to not care about regulation or even break it intentionally. This way you can move fast, but I doubt you'll win any big governmental contracts.

Poul-Henning Kamp | Sun, 22 Dec 2013 20:15:45 UTC

@Mike Small:

To paraphrase Justice Antonin Scalia: "I trust Congress know how to write 'brochure' if they intend to write 'brochure'."

Mike Small | Sun, 22 Dec 2013 18:09:40 UTC

That description doesn't at all imply a computer program to me. Rather it could describes a brochure (online or otherwise) or similar document with writing and pictures. It engages the way your article engages. It could be produced by the likes of organizations like the following with no programmers or computer scientists on staff: http://www.informedmedicaldecisions.org/

Poul-Henning Kamp | Sun, 22 Dec 2013 17:43:11 UTC

@J Story:

Correct, it's obviously inconvenient volumetrically to have the wheel in the middle of things, but not as a matter of mass. But read the article in Low-Tech Magazine (ref #2) and you'll see that it is far more interesting than that. (Sails on a wheelbarrow ??)


The point here is that politicians point to the 1-man wonders and then legislate 10.000-man fiaskos into existence.

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2019 ACM, Inc. All Rights Reserved.