Josef Assad

If Useless e-Services have bad security, does it matter?

josef — Fri, 02 Aug 2013 12:45:05 +0000

tl;dr EURES is an EU e-governenment service where password resets are broken, and the support agents ask for your passwords and will happily delete any account given a username or e-mail address without any form of verification.

Some years back, I was job hunting. In good faith, I registered on EURES (the EURopean Employment Service).

The EURES service has never provided anything even remotely useful; I might have been approached about a job as a chimney sweep in Bulgaria once.

The service does send you a lot of uninteresting newsletters though, and today I have been trying to log in to unsubscribe from these bureaucratically mandated opt-in snoozefests. This has turned out to be a very interesting exercise.

Right off the bat, the password reset does not work. They send you a new password in plain text by e-mail. Great. It's still possible they are only storing the password hash, but what does your gut tell you?

Having obtained this new password, the login still does not work. So you search their site looking for alternative ways of getting in to the system. They have a Contact page where you can choose either a web based livechat or a skype chat with a support agent.

Skype chat. with a support agent. That's the bad news. The good news is, no one is answering on the skype account.

So I choose the web chat, which reassuringly is run over https. But, is it? Hovering over the live chat link shows an https URL (good), but the popup window it opens is unencrypted (sigh).

Well, they do answer the web chat support. That is the good news. There's a lot of bad news though. The first piece of bad news is, when you explain that you cannot log in, they ask you for your password so they can try to log in. If you refuse and explain that this is bad practise, they say that they always ask you to change your password afterwards.

That isn't even the worst thing. The worst thing is, I gave them my username and asked them to delete my account, which they did promptly and without any form of verification at all.

You can essentially give them any valid username or email address of a valid account and they will delete it. I am speechless.

To conclude on a positive note, if anyone loses their account on EURES due to their shockingly bad security, the service is so useless it doesn't matter. EURES is useless and - like so many public sector IT services - only exists to distribute public funds to IT vendors.

A Bollocks-free Enterprise Architecture Repository with Semantic Mediawiki

josef — Sat, 22 Jun 2013 11:07:50 +0000

One of the biggest reasons there is so much bad software is that business schools pump out people who have been led to believe that the ability to draw diagrams is an acceptable substitute for the ability to read a line of code or assess a technical standard.

One prominent victim of this phenomenon is the whole area around enterprise architecture. Gartner calls it:

...the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution

It's a clear enough definition and - as with everything Gartner - it doesn't help anyone accomplish much of anything. Not counting the dubious objective of creating a market for MBA graduates.

Here is my alternative definition of Enterprise Architecture. You are free to use this definition for any purpose, especially if you intend to tattoo it on your CIO's backside:

The systems we are responsible for are legion, they are heterogeneous, they are wicked, and they conspire. We wield the autocratic staff of Enterprise Architecture and it sheds light and builds highways (and occasionally bike paths). It fosters empathy for the whole in the heart of each subsystem.

I am fortunate enough to have a employer who has an appropriate level of appreciation for the abstract notion of Enterprise Architecture, coupled with a sensibly low level of respect for established frameworks such as Zachman and TOGAF.

Look at this picture taken from the wikipedia page on the Zachman Framework. It shares structure and semantics with drawings scratched on cell walls in Guantanamo:

Where I work, we have overall governing and coordinating responsibility for a fairly large systems complex. Specifically, a big subset of the Danish national library systems infrastructure. It's a lot of systems, a lot of integrations, a lot of protocols (some quite esoteric, many derivative), and a lot of churn in the evolution of the individual components.

In human language, it's complex and it's driven by a lot of people and philosophies which don't all dance to the same tune. This is the mating call which draws the attention of the wielder of the Staff of Enterprise Architecture.

We needed a way to model the whole such that changes to one component does not cause another to launch any nukes. We needed a tool which allows us to conduct impact assessment of tweaking an integration protocol. And we thought it would be nice if the development plans of each component exhibited a form of technosocial cohesion; if ground-level development plans increased empathy for the whole rather than triggered firefighting in vaguely related subsystems.

As any good business consultant will tell you, we needed an Enterprise Architecture Repository. As responsible architectural autocrats who know what a Makefile is, we said bollocks to that and went the practical way

Real Enterprise Architecture Repositories

A real Enterprise Architecture Repository (hereafter EAR) is one which is sold in a cardboard box with the words Enterprise Architecture Repository Suite Deluxe Enteprise Edition. It is sold for amounts of money so vast that the base license includes the very souls of 10 to 15 fairly recent management school grads who will spend the next five years drawing diagrams and sending Visio diagrams to an Indian offshore development team who "adapt" (primarily, writing 1000 line stored procedures and building out God objects) the system to your organisation.

In the meanwhile, your systems go down the shitter.

A bollocks-free Enterprise Architecture Repository

Those of us who prefer an existence where systems don't go in the shitter take an alternative path. In our case, we have chosen to go with a Semantic Mediawiki.

Here is wikipedia's explanation of what Semantic Mediawiki is:

Semantic MediaWiki (SMW) is an extension to MediaWiki that allows for annotating semantic data within wiki pages, thus turning a wiki that incorporates the extension into a semantic wiki. Data that has been encoded can be used in semantic searches, used for aggregation of pages, displayed in formats like maps, calendars and graphs, and exported to the outside world via formats like RDF and CSV.

That was a big load of do-not-care. Let me translate it for you:

Semantic Mediawiki allows you to attach properties to wiki pages. And to query the pages based on these properties.

This isn't minor. This means that the only difference between a vanilla Semantic Mediawiki and an EAR is your ability to model your architecture in categories, properties, and templates. Our Mediawiki-based EAR is still under development and evolution, but we already have a base structure which does an astonishingly good job at modeling our EA.

Let me share some key notions from our Semantic Mediawiki structure and use cases with you.

The EA Model

We operate with the Semantic Forms extension. Strictly speaking we don't need it, but there is a certain elegance to comboboxes in forms which are automatically populated from Categories.

Category	Purpose
System	Pages in this category represent each unique system in the collective, regardless of whether we govern it or not. A System page links to a Vendor page.
Vendor	Pages in this category represent the vendors; the gatekeepers of change of the system components of the whole architecture
SSO	Standards-setting organisation; includes pages on organisations such as OASIS or NIST or Library of Congress, but can also link to vendor pages
Integration Protocol	Includes pages such as NCIP, SAML2, etc. Each page links to an SSO page. This linkage happens in the Semantic Form defined for these pages.
Integration Transport	Things like SOAP, ReST, sneakernet, RFC 2459, etc.
Integration	Pages in this category are semantically linked to two pages under the category System, one Integration Protocol page, and one Integration Transport page.
...	and so on

Properties

For each page type, we define "interesting" properties. Our page template for System currently includes properties such as:

Property	Attached to Category	Purpose
SystemSourceURL	System	The canonical URL to system source code.
SystemDocAdminURL	System	The canonical URL to administrator documentation.
IntegrationProtocolCurrentVersion	IntegrationProtocol	The latest version of the protocol
IntegrationProtocolCurrentVersionDate	IntegrationProtocol	The date when the current version of the protocol was last bumped.
... and so on

And so on. Now the clever thing is, Semantic Mediawiki allows you to query your wiki based on these properties, and based on the connections between pages in different categories. Since Integration links to System, and IntegrationProtocol links to Integration, we have an automatically generated view on the IntegrationProtocol page which lists the systems that depend on this protocol.

This specific example is useful since it allows us as the Wielders of the Enteprise Architecture Staff to understand how a change in ine part propagates. It improves the empathy of the individual (single System or IntegrationProtocol) for the welfare of the collective (Enterprise Architecture).

Governance (aka sic'ing the kids on the wiki)

As this EAR is in its early days, we are still using it internally for the purposes of seeding the data and stabilising the semantic model. In the medium term, we intend to open the wiki up to stakeholders. This includes administrators of some systems and vendors of others. We also expect to open the wiki to the public, albeit in read only fashion.

In the longer term, we will be looking at the possibility of creating some form of harmony between the vendors' software lifecycle toolchains (e.g. roadmap and development tracking systems) and this EAR. It's all a matter of metadata creating a semantic link between an issue in a bug tracker up through the semantic interlinkages to enterprise-wide context.

Our Semantic Mediawiki will continue to evolve and grow. We have painted a picture of our EA using categories, properties, templates, and semantic forms. It's still fingerpainting but it's lightyears ahead of commercial behemoths like Casewise Corporate modeler (yes, that is a real product name) in pragmatism, effectiveness, flexibility, and above all our ability to really own our EAR and wield it to tame the beasts in our systems portfolio.

On hiring good engineers

josef — Fri, 21 Jun 2013 17:53:35 +0000

An interview with a Google HR person was brought to my attention. Apart from the fact that Google dehumanises their employees by calling this area "People Operations", the following quote was interesting:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

This seems fairly obvious to me, but technical candidates will probably have to live with this bankrupt assessment method for a while yet.

I have done my fair share of interviewing; I am not an HR professional, but I am often called upon to assess the technical side of candidates. I'm fairly happy with my hit rate, and since it is quite simple I will share some of it here. It's worth noting, this probably only works for vacancies up to intermediate levels of technical depth. It worked well for me at Ramboll Informatik, it worked well for KMD, it worked well during my time with the Grameen Foundation and with IT Synergy. I don't think it will work well if you're hiring for a position requiring a very vertical and deep skillset.

When speaking with the candidate, I rarely take more than fifteen to twenty minutes. This is partially because there's a lot of other non-technical people who want their slots in the interview process (sigh); it's also because it doesn't take a long time to spot a candidate who has the right mindset.

Mindset over CV.

Since fifteen minutes isn't a long time, I can't waste time on questions like "how long have you programmed in C#" or "what kind of classes did you do at university". And since every single job description ever written comprehensively fails to describe the job in any meaningful fashion, it's a safer bet to hire someone who can do the job described but who won't break down if it turns out that the new DBA hire also needs to know how to tune hardware.

A simple approach to interviewing doesn't deserve a long blog post. I ask questions which reveal the professional inquisitiveness characteristic of problem solvers. The questions are mostly freeform, and they do not require paper and pencil. The questions are hard to impossible to prepare for, and in most cases the specifics of the candidate's answer matter less than the way the answer is delivered. How long the answer is, the degree of animation, articulation of clear opinions.

Here are some of the questions I ask. I have annotated the first few to illustrate intent.

In previous projects, what technical limitations did you work under that you wanted to change thereby improving the quality of your work? - Here we're looking for a combination of two things: diplomacy, and an individual sense of what good engineering is; not just a knowledge of corporate guidelines and methods.
When is it a good reason to use non-current software versions, for example as developer toolchain or libraries? - A lot of engineers will fall back to stories about corporate standards or licenses forcing obsolete versions. Some will consider more interesting aspects like API changes. A few will tell stories about terrible library updates that they felt were detrimental. This type of question is good for getting an impression of the engineer's experience and independent judgment.
What is hard about working in a team of 2, and what is hard about working in a team of twelve? - Good question for provoking stories. Stories are always good.
When you first learned to program, what was the most difficult thing to understand? - Same as above; added benefit, it improves the conversational nature of the interview. I always lead with a story about how C pointers always drove me up the wall.
Have you ever picked up a project that was in maintenance mode, and not to be developed from scratch? How was this different? What made it easier, what made it harder?
Exposure to other languages and operating systems? - I am looking here for professional inquisitiveness. I find this to be sine qua non. Google helps a lot here also.
Have you ever seen code in a system that you could see should have been split off in a module and vice versa? What is too little modularisation and what is too much?
Tell us a little about the best designed source code you ever saw and also the worst.
Ever done web development? Tables vs divs. How do you feel about using either for UI layout?
Why do you think an Oracle installation is so many Gb when a postgresql or myqsl installation is only some megabytes? Why the huge footprint? Why is Outlook so big compared to say Thunderbird or Eudora?
Say you have a db driven web UI system with many users. It does a lot of complicated things. There's a bug. When a user sometimes enters a value in a specific box and clicks OK, sometimes it gets written to the database and sometimes not. They cannot reproduce the problem but you know it's real and not imagined. How do you proceed if it's your responsibility to get it fixed?
If you could make all programmers follow one good practise or change one thing about how they work, what would that be?
If you have to hire a programmer and you have too many applicants to interview, what question would you ask them to exclude as many as possible as quickly as possible?

A little practical note: this is a list I accumulated over a period of time. I do not ask all of these questions in one interview; there is usually only time for 3 or 4 in one fifteen minute slot. But that is often enough; at least at the level at which I have had experience conducting technical skill assessments.