Subscribe: Bevan on Drupal, Usability, Web, Open Source, Tech...
Added By: Feedage Forager Feedage Grade B rated
Language: English
code  drupal security  drupal  drupalgeddon  group  highly  make  psa  quality  read  security team  security  shuttle group  software 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Bevan on Drupal, Usability, Web, Open Source, Tech... Bevan on Drupal, Usability, Web, Open Source, Tech...


Writing the Right Stuff, in the 21st Century

Mon, 06 Feb 2017 23:55:44 +0000

I was recently discussing the problems of software security and code quality. These articles inspired the conversation; Everything is Broken, a sincere recount of the awfulness of almost all software. They Write the Right Stuff, how the Shuttle Group makes nearly-perfect software for NASA space shuttles. The Explosion of the Ariane 5 was because of a software bug. There are lessons for us software engineers/teams in these articles, especially in “They Write the Right Stuff”. But all of these quality control mechanisms come at a cost. But first, let’s put the article in perspective; It was published in 1996, 20 years ago. Git didn't exist. (And CVS sucked.) "Agile" meant something about your sporting ability, not software. And a tonne of software tools and modern high level languages didn't exist or were in their infancy. The Shuttle Group probably had few or no choice of libraries to use, and had to write their own GPS software, among other things. Further; NASA is probably the perfect client/employer; Big budget, high technical capability, commitment, and detailed specs. Few software teams/engineers are so lucky to have such a client/employer. On the flip-side, if the software fails, astronauts die. And the world’s media looks for someone to blame. And the US government will make sure some heads roll. There are high consequences to buggy software. "If the software isn't perfect, some of the people we go to meetings with might die. Finally, Fast Company is a media company. They publish high quality content that attracts the eyes of consumers, which allows Fast Company to sell advertising or subscriptions. That means they sensationalise the story. NASA’s own “Computers in Spaceflight” appears to be a more realistic account of the history of NASA shuttle software. Now; What are the costs? Most notably, the Shuttle Group followed a strictly waterfall process; “...about one-third of the process of writing software happens before anyone writes a line of code. “The specs for [a change that involves 6,366 lines of code] run 2,500 pages.” Second, the Shuttle Group was expensive to run; “... the group’s $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations. Extrapolating some other numbers; The program had about ~424,400 lines of code in 1996, which had been worked on for 21 years at a total cost of ~$700M. That's ~$1,650 per line of code. (Not that lines of code is a meaningful measure of code complexity.) I've not accounted for inflation. The economic costs are just the software; I.e. travel and office expenses, but predominantly, people's time (salaries). I first read that article about 9 years ago. After rereading it last weekend, I realised it had a profound impact on how highly I value software quality; I have always strived for the most elegant, simple and readable code. More recently I've learned that it's almost never worth the effort to get software to its highest possible quality. The problem with making software right in the first round of development is that you probably haven't found the best solution yet. You probably missed a more elegant solution. And you probably have not fully understood the entirety of problem and all its edge cases. Further, the more time you spend refining a work, the more emotional value you give it. This makes it harder to recognize or admit that it might be the wrong solution, and much harder to delete. (Good code deletion skills are highly valuable, by the way!) In other words, we have to find the balance between "It works" and "It is right" (correct, easy to read, simple, elegant, deduplicate, etcetera), considering the risk of not making it right (yet) along with the time, people and money available. Usually it is better to get something out which only mostly works but is not totally “right”, then only make it “right” once we understand the problem and possible solutions better. That might be hours or[...]

Make it work, make it right, make it fast

Wed, 01 Feb 2017 22:15:25 +0000

I’ve recently come to appreciate

Make it work, make it right, make it fast.
— Kent Beck

Applied to an individual development task, it means to distinctly separate each of these phases of development and to only transition from to the next task when the previous one is complete;

  1. Get the feature to work as fast as possible. The goal here is only to understand the problem and find solution(s). Nothing more. Be prepared to discard any/all of the code you write.

read more

Flowtype vs Typescript

Mon, 12 Dec 2016 23:06:44 +0000

Flowtype has a small set of features focussed on typechecking. It is a superset of JavaScript. It can be transpiled to JavaScript by simply stripping the type annotations. It allows you to specify types almost as little or as much you like. It becomes more powerful the more detail you specify. So you can easily leave some or most of your code with no type specifications.

read more

Wonderful Webpack tips

Mon, 12 Dec 2016 22:55:42 +0000

Here are my recently learnt tips for advanced usage of the wonderful Webpack

  1. --hot does not do would you would expect. webpack --watch and webpack-dev-server do what you'd expect --hot to do, even without that option.
  2. --lazy stops WDS from doing what you'd expect --hot to do.
  3. --hot allows modules (files) to be updated in place, without reloading the webpage.

read more

Not so highly critical?

Wed, 13 Jul 2016 21:43:30 +0000

The Drupal security team published a PSA to warn about upcoming security advisories. I shared my advice and predicted attacks within the hour after the security advisories are published. The security advisories are now published. Here is my followup.

I applaud the Drupal Security Team for warning about the highly critical updates. However the public service announcement (PSA) left the impression that this event was going to be much more serious than it was. Such a PSA would have been perfectly appropriate for SA-CORE-2014-005 "Drupalgeddon". But the only PSA there was in hindsight.

I guess it is resonable for the Drupal Security Team to be over cautious, especially given the lessons learned from Drupalgeddon fallout. And of course, such decisions and criticism is much easier with hindsight.

But now I am concerned how the Drupal Security Team can realistically raise the level further there is another vulnerability that is as serious as Drupalgeddon. Even if they raise the alert level using language in the PSA, will people still believe them? It reminds me of the boy who cried wolf.

Of course serious vulnerabilities like these are rare events in Drupal, so there is not yet a standard to compare alert levels to.

read more

Drupalgeddon; Are you ready?

Tue, 12 Jul 2016 21:57:20 +0000

Just arrived here? Read my followup first.

Original post

The Drupal security team announced multiple highly critical updates to Drupal contrib modules in PSA-2016-001. Expect attacks within less than one hour from the announcement; 18 hours from the time this article is published. This is probably going to be Drupalgeddon all over again.

My advice

If you are prepared, you will save yourself a lot of time. If you are late or too slow, you will probably find yourself with a lot more work, e.g. the rescue workflow for Drupalgeddon 1.


Don't skimp on the first two. And do at least one of "3. Update a contrib module" or "4. Learn how to apply patches". Which one you choose depends on your skills and how out of date contrib modules are on your Drupal websites. Ideally, do both steps 3 & 4; You might find one of them is significantly challenging for you.

read more