Jean-Marc

I just received the most interesting email from WPML today after they helped with me a problem with my website.

WPML and M2i3 have a similar philosophy there: we don’t want access to something longer than it’s needed.

Yet, very often, client will give me their password so we can manage their accounts or help them troubleshoot issues.

In the best of world I would be able to have an account specific to me. Otherwise, I tell them to change it before they give it to us (since most people will reuse passwords) and to change it again after we are done.

Do I go and check if they truly have removed the accounts or changed the passwords?

No

That would be inappropriate and, to some extent, an attempt to breach their infrastructure. In any case I get to know if they have changed it the next time they ask for assistance.

So, I ask you this question: “how careful are you to remove accounts and change the passwords you have given to the suppliers who assist you?”

It matters quite a bit nowadays, if they are breached, your own infrastructure is exposed. Potentially your client’s data is exposed.

And, if you are in Québec, with Québec’s Law 25, you’ll be required to disclose the event which will impact your credibility. Not doing so can expose you to hefty fines (as if loosing credibility was not enough).

How can you close these doors?

There are a few things you can do to improve your security posture:

1. change your password before and after giving it to a supplier (it’s actually a good practice to change passwords on a regular basis)
2. create accounts specific for your suppliers when possible, make their name clear that they are suppliers (use the name of their organisation instead of the name of the person who is helping you).
3. keep a registry of who you gave access, until when it’s needed and remove those accounts when they are no longer needed
4. review who has access to which system on a regular basis. Remove anyone who should no longer have access.

With these little steps, your infrastructure and your data will be kept much safer.

—
Jean-Marc

There are many questions a child can ask but none as powerful as the “why” question. You know that phase when the kids around us will ask “why” about just about anything imaginable (and even some we’d rather not imagine). This question is so important that Toyota has even incorporated it into its own troubleshooting process in the form of the “5 whys”.
The method works elsewhere than in problem solving. It’s actually one of my favorite tools in analysis, as it allows us to dig deeper into a request, a motivation, a problem, the reason behind any request (well, as long as both parties are honest and knowledgeable). I won’t hide from you that being asked repeatedly “but, why?” can be very frustrating (any parent can tell you that). This being said, it is worth the effort, since in the end you will obtain a clear situation, free of any preconceived ideas.
Of course, it takes a bit of good will to get there.
Let’s take a hypothetical example:

• Client: “I would like the background of my page to be pink with moving bling”
• Designer: “why?”
• Client: “because pink is my company’s color and I want pink on the website”
• Designer: “Okay and the bling bling?”
• Client: “because just pink will be too simple and the background of a page is like a wall and it must be painted to be pleasant”
• Designer: “like a wall? why do you think that?”
• Customer: “I read it somewhere”
• Designer: “And the pink and the bling, where did they come from?”
• Client: “because I sell fashion accessories for young girls and pink is feminine and young, just like bling bling”

The amount of information obtained in such a conversation is enormous. Educational potential too. The designer can now educate on the importance of not distracting the visitor about the products sold and the purchase transaction. He also obtained a mountain of information on the age and style of the target clientele. And, in the end, whether the background of the page becomes bright pink (or not), as a designer you now have a lot of information on hand to integrate and better reach the clientele than if you had stopped at the first question.
As a client, being the target of these questions may seem unpleasant and in fact it is because we then revisit information acquired a long time ago. However, keep in mind that the designer of your website does not know everything about your company and your mission. You have to educate him a little on what led you to choose such a color. In the end, you may even learn or even rediscover something important about your business.
As my father used to say: “there are no stupid questions”. Well, in fact there are, but you get my point.
All aspects of a design and a website should be analyzed and dug to their core motivation. Each request auscultated on all its angles. It’s the only way to know if you want something solid or just a “we’re going to put a kitten, it’s beautiful a kitten, I love kittens”.
There is a risk in following logic and digging too much into a design. First, because a design often appeals to emotion and people will react differently to colors and fonts. There is also the issue of knowledge. The person working with you may not know the underlying reasons. In fact, sometimes, there is simply no reason or the latter is so ridiculous that we will prefer to keep it secret. Honesty is paramount in such a process and answering “I don’t know” is perfectly acceptable.
That said, there are other methods to get a solid design. Experimentation and A/B testing are among the tools allowing the designer to create a user experience that will support business objectives. And let’s not forget that he is not the only one who can ask “why”. As a client you can and should question your designer’s choices.
So why is the sky blue? An innocuous question, heard thousands of times. And yet, the most important design tool we have.
—
Jean Marc

Tags: agile movement, manifesto, philosophy

Our site features a French version of the manifesto for Agile software development and after a month into the new year I think it’s important to put it back on the agenda. Not because I doubt the quality of the work of my colleagues who work with SCRUM, but because it’s time to get back to basics.

The signatories of the manifesto have thought long and hard about the manifesto’s values for making software development more viable, more sustainable and more humane. Personally, I see this manifesto as a reminder that, as a profession, we’re still at the master-apprentice-apprentice stage. We’ve formalized and codified many aspects of our business, but there’s still so much to discover about the dynamics of software development that I think it’s still too early to adopt engineering behavior and methodologies.

And even if we had reached this stage, the manifesto gives a much-needed human dimension to our work. It takes into account the constant changes inherent in learning processes (even in 2013).

So I’m re-inscribing the official (French) version of the manifesto as a testament to its principles:
People and their interactions rather than processes and tools
Operational software rather than exhaustive documentation
Working with customers rather than negotiating contracts
Adapting to change rather than following a plan
(source: http://agilemanifesto.org/iso/fr/)

—
Jean Marc