Personally I think it's very good and I like the industrial sounds they put in it. I don't know much about the group itself and about the rest of their music, bu I'm sure going to look into it now.
Sep 18, 2009
Sting - Police fan?
My wife found this group called Nouvelle Vague. They are doing an interpretation of the Police 'So lonely'.
Personally I think it's very good and I like the industrial sounds they put in it. I don't know much about the group itself and about the rest of their music, bu I'm sure going to look into it now.
Personally I think it's very good and I like the industrial sounds they put in it. I don't know much about the group itself and about the rest of their music, bu I'm sure going to look into it now.
Sep 15, 2009
Left behind
Normally when I watch TED talks, I come out very motivated and dive into my work for hours. This time it was different, Bjarke Ingels's talk left me both motivated and disheartened. Here he comes showing incredible architecture solutions, beautiful buildings and enormous projects, but something was not quite right. Most of those amazing projects are nowhere near North America or Europe. Are we not a bit worried about making amazing buildings, cities and bridges? When I see all this crazy developments I wish there was more of them here. I know we have some, but with the amount of money flowing here, it feels like we're left behind on this.
We shouldn't be the old square-gray-building world, we should be leaders too. We sure have the minds & means to do it.
Bitch, moan, cry... shut up Phillipe and do something about it.
We shouldn't be the old square-gray-building world, we should be leaders too. We sure have the minds & means to do it.
Bitch, moan, cry... shut up Phillipe and do something about it.
Sep 13, 2009
Canada Population 2008
This is a representation of Canada and its Provinces by Population ratio. The numbers are comming from Statistic Canada web site for 2008.
The size of the words are the ratio of population compared to the smallest province populations (Nunavut with 31,400). There should be 13 provinces (plus Canada) in the picture but Nunavut, Northwest-Territories and Yukon are to small to be displayed.
Link to the original image created with wordle.
The size of the words are the ratio of population compared to the smallest province populations (Nunavut with 31,400). There should be 13 provinces (plus Canada) in the picture but Nunavut, Northwest-Territories and Yukon are to small to be displayed.
Link to the original image created with wordle.
Sep 12, 2009
Error handling with the user
One of my development strategy for software tools is to always give a result and working in cooperation with the user. Here are my three basic rules:
1.Software must always output some result
2.Communications with the user must be done by using the current data format
3.Errors must be clearly identifiable compared to normal outputs
Rule #1) Software must always output some result
Software should never just stop. If a minima is reached, a meaningful descriptive of the problem should always be displayed. If an algorithm fails halfway through execution, that first half should be displayed. Why is that important? Because the point at which it stopped is the biggest clue you'll ever give to the user on 'why it failed' and it's the biggest lead for the user on 'how to fix his inputs'. It is of course imperative that those errors outputs are non-destructive to the rest of the data.
Rule #2) Communications with the user must be done by using the current data format
Why use a different language than the one utilized by the user? Imagine that a problem occurs when doing some calculation base on vector data in 3DS Max (a 3D modeling software). Lets say that the problem lies in one of the vertices (points). Your code is trying to process the problematic vertex but it can't. Why? There's about as many reasons that there is users and 3DS drawings, so forget the reason. Of course if you just display a text box trying to describe the problem, it might have a chance at helping the user. But if you highlight the problematic vertex and pan/zoom to it, now that's helping the user. You don't have to do this in the original file. You can use a separate file but keep a similar medium. If the user is doing vector graphics use vector graphics.
Rule #3) Errors must be clearly identifiable compared to normal outputs
Highlight the errors and the thing that you're not sure about. An errors as to be flagrant, make it bold and use red a lot. The user should be able in one glance to identify the problems but still recognizer the surrounding data. This ability to see the bad data in its real context is the key for the user to quickly see the problem.
A good example of this way of working is MS Words handling of typos. While you type, it highlights errors but never stops your actions. You can then fix the problem(s) whenever you want and they're easy to fix because they're in context.
1.Software must always output some result
2.Communications with the user must be done by using the current data format
3.Errors must be clearly identifiable compared to normal outputs
Rule #1) Software must always output some result
Software should never just stop. If a minima is reached, a meaningful descriptive of the problem should always be displayed. If an algorithm fails halfway through execution, that first half should be displayed. Why is that important? Because the point at which it stopped is the biggest clue you'll ever give to the user on 'why it failed' and it's the biggest lead for the user on 'how to fix his inputs'. It is of course imperative that those errors outputs are non-destructive to the rest of the data.
Rule #2) Communications with the user must be done by using the current data format
Why use a different language than the one utilized by the user? Imagine that a problem occurs when doing some calculation base on vector data in 3DS Max (a 3D modeling software). Lets say that the problem lies in one of the vertices (points). Your code is trying to process the problematic vertex but it can't. Why? There's about as many reasons that there is users and 3DS drawings, so forget the reason. Of course if you just display a text box trying to describe the problem, it might have a chance at helping the user. But if you highlight the problematic vertex and pan/zoom to it, now that's helping the user. You don't have to do this in the original file. You can use a separate file but keep a similar medium. If the user is doing vector graphics use vector graphics.
Rule #3) Errors must be clearly identifiable compared to normal outputs
Highlight the errors and the thing that you're not sure about. An errors as to be flagrant, make it bold and use red a lot. The user should be able in one glance to identify the problems but still recognizer the surrounding data. This ability to see the bad data in its real context is the key for the user to quickly see the problem.
A good example of this way of working is MS Words handling of typos. While you type, it highlights errors but never stops your actions. You can then fix the problem(s) whenever you want and they're easy to fix because they're in context.
Sep 10, 2009
Three, two , duh!
Even if you don't like space exploration, you'll probably like this one. Japan launched its HTV automatic space vehicle en route to the International Space Station. I'll direct you to a video of launch, but I have to tell you something before you click on it.
Remember when you did countdowns before starting a game with your friends? The first few times we learn pretty much everything about the 'duration' of the count. A bunch of people start at ten, a nice round number, and then realize half way to zero that it's awkwardly long. Ten is good if you want to make it an official moment, like jumping into the pool from the roof. It also give you time to rethink things. Once you've done ten, then you start at five, much shorter and about one second from being awkward. Finally, if you're in a hurry, you start at three. Anybody that ever started a countdown longer than ten, let's say twenty, knows that this is a bad idea. Normally people start shutting up at sixteen, talk about the jerk that started it, and get back in the count at five.
This should be it. I lived with those notions of countdowns for thirty plus years and I'm pretty happy. NASA reinforced my neuron connections by starting at ten almost all the time. Then came JAXA, the NASA of Japan. They were launching that big new rocket and I was not going to miss it. So I sat in from of my computer and saw this:
The launch link
Why? Three minutes? Now, how much are they paying that girl? Did she lose a bet? Maybe it's a prank they play on new employees. Imagine doing that in English or French, you'd need some speed talker from the Guinness book.
Anyway, if they keep that up, I'm watching their next launch with no sound.
Remember when you did countdowns before starting a game with your friends? The first few times we learn pretty much everything about the 'duration' of the count. A bunch of people start at ten, a nice round number, and then realize half way to zero that it's awkwardly long. Ten is good if you want to make it an official moment, like jumping into the pool from the roof. It also give you time to rethink things. Once you've done ten, then you start at five, much shorter and about one second from being awkward. Finally, if you're in a hurry, you start at three. Anybody that ever started a countdown longer than ten, let's say twenty, knows that this is a bad idea. Normally people start shutting up at sixteen, talk about the jerk that started it, and get back in the count at five.
This should be it. I lived with those notions of countdowns for thirty plus years and I'm pretty happy. NASA reinforced my neuron connections by starting at ten almost all the time. Then came JAXA, the NASA of Japan. They were launching that big new rocket and I was not going to miss it. So I sat in from of my computer and saw this:
The launch link
Why? Three minutes? Now, how much are they paying that girl? Did she lose a bet? Maybe it's a prank they play on new employees. Imagine doing that in English or French, you'd need some speed talker from the Guinness book.
Anyway, if they keep that up, I'm watching their next launch with no sound.
Sep 8, 2009
Agile - step 1
In the past, I had some small management experiences, though at the time I thought they were significant. Sure it was easy, I only had to manage autonomous people (See previous post about Planing & Foresight for my definition of autonomous). So as a manager, my real challenge began when I was faced with a team largely composed of young graduates. Some of them were dependent some were autonomous.
In the months before the project started, I prepared myself for this leadership position by reading a lot about the subject. I was convinced to try Agile, or more precisely Scrum. Why? Because one of my previous colleagues was using it for years and swore by it. He gave me some key words like 'Scrum' and 'Ken Schwaber' and I was off, learning about Agile planning, development & management.
We started small with agile. I told my guys we would have a scrum meeting every morning and that we would do 4-week sprints. We set our goals for the first sprint and that was it, our first agile iteration was started. We only did two sprints with a duration of 4-weeks. It was a good length at the beginning because we had to set a lot of basic code and procedures. Later they would be 2-weeks sprints. Also, at that time, we did not have many requirements from our owner.
Owner?
The fact was we didn't have an official owner because we were the only ones using agile and nobody else wanted to participate. So I created a virtual owner in my head. His requirements were derived from the needs of the people I identified as The-people-who-should-be-the-owner and I created my own backlog using Jira. We had no way to calculate our velocity but I documented the results of all the sprints on a wiki page that was shared with the team.
I also had two computer screens setup in plain view on which I had a hand-made manually-updated Excel spreadsheet displaying our sprint burn-down and the status of each task. Yes manually-updated, now is that commitment or what? After some time my people started meeting spontaneously in front of the screens to discuss current problems.
When thas project started people were not accustomed to self-organized team work. But I remember the first day I saw 3 people standing up at a workstation, talking lively and pointing at the computer screen. They were discussing possible ways of solving a problem and planning their work. That was a good sign!
In the months before the project started, I prepared myself for this leadership position by reading a lot about the subject. I was convinced to try Agile, or more precisely Scrum. Why? Because one of my previous colleagues was using it for years and swore by it. He gave me some key words like 'Scrum' and 'Ken Schwaber' and I was off, learning about Agile planning, development & management.
We started small with agile. I told my guys we would have a scrum meeting every morning and that we would do 4-week sprints. We set our goals for the first sprint and that was it, our first agile iteration was started. We only did two sprints with a duration of 4-weeks. It was a good length at the beginning because we had to set a lot of basic code and procedures. Later they would be 2-weeks sprints. Also, at that time, we did not have many requirements from our owner.
Owner?
The fact was we didn't have an official owner because we were the only ones using agile and nobody else wanted to participate. So I created a virtual owner in my head. His requirements were derived from the needs of the people I identified as The-people-who-should-be-the-owner and I created my own backlog using Jira. We had no way to calculate our velocity but I documented the results of all the sprints on a wiki page that was shared with the team.
I also had two computer screens setup in plain view on which I had a hand-made manually-updated Excel spreadsheet displaying our sprint burn-down and the status of each task. Yes manually-updated, now is that commitment or what? After some time my people started meeting spontaneously in front of the screens to discuss current problems.
When thas project started people were not accustomed to self-organized team work. But I remember the first day I saw 3 people standing up at a workstation, talking lively and pointing at the computer screen. They were discussing possible ways of solving a problem and planning their work. That was a good sign!
Sep 7, 2009
Planning & Foresight
In my opinion, other than the capability of doing their job, the most important skills employees must have or acquire are Planning & Foresight. The most basic of the two is Planning and without it the employees are not functional. This is my 'non-P.C.' scale using Planning & Foresight as the metrics:
Dead weight: Can't plan, Can't foresee anything
Dependent: Plan at task level (actions), Rarely foresees
Autonomous: Plan at module level (tactics), Foresees with little inter-dependencies
Leader: Plan at macro level (strategy), Foresees with inter-dependencies
This is a linear way of comparing the two skills because planning skills depend on foresight. i.e. A good planner cannot be a great planner without foresight but somebody can have great foresight with little planning skills.
After you're done with your list: 1) I take it as a failure of management to either hire a person who is not qualified or failing at motivating that person through work. If you're stuck with a dead weight, let that person go. But wait, you are not done yet. Find out why 'you' (as a person or as a management team) failed so 'you' can prevent it in the future. 2) Create a good environment around the dependent people. Put positive pressure on them to see if they will grow into dead weight or autonomous people. 3) Keep your autonomous people challenged and encourage leadership in them. 4) Don't forget your leaders. Most of the time they're doing fine, but sometimes they
need to vent or to know they're doing a good job.
Note: I'm pretty sure there is a parallel between this way of sorting people and the 'Ability & Willingness' four-quadrant[1] table I recently heard about. I'll post about that later.
References
1. Don Phillips, 2007, The four-quadrant leadership team
Dead weight: Can't plan, Can't foresee anything
Dependent: Plan at task level (actions), Rarely foresees
Autonomous: Plan at module level (tactics), Foresees with little inter-dependencies
Leader: Plan at macro level (strategy), Foresees with inter-dependencies
This is a linear way of comparing the two skills because planning skills depend on foresight. i.e. A good planner cannot be a great planner without foresight but somebody can have great foresight with little planning skills.
After you're done with your list: 1) I take it as a failure of management to either hire a person who is not qualified or failing at motivating that person through work. If you're stuck with a dead weight, let that person go. But wait, you are not done yet. Find out why 'you' (as a person or as a management team) failed so 'you' can prevent it in the future. 2) Create a good environment around the dependent people. Put positive pressure on them to see if they will grow into dead weight or autonomous people. 3) Keep your autonomous people challenged and encourage leadership in them. 4) Don't forget your leaders. Most of the time they're doing fine, but sometimes they
need to vent or to know they're doing a good job.
Note: I'm pretty sure there is a parallel between this way of sorting people and the 'Ability & Willingness' four-quadrant[1] table I recently heard about. I'll post about that later.
References
1. Don Phillips, 2007, The four-quadrant leadership team
Subscribe to:
Posts (Atom)