Floating on technology

Looking at four teenagers at the mall on a school day made me think.


The masses in north America have a cellphone, an ipod, are using Twitter and FaceBook. On the other hand, they couldn't make a simple HTML page from scratch, explain how the Internet works or tell the difference between a content-driven web page and a blog. “It just works man. What's your problem?” People forgot the basic things, like work, questioning, reading or learning a new thing so your brain doesn't die. I thought technology was supposed to push us further and faster. Looking around, it seems we're sitting down in our big technology lazyboy.

At the same time, the new generations in Asia are rising to build themselves a future. They want to learn and thus they learn fast. They fight for a chance at education and value it. Not only are they using technology but they understand it from the ground up. We should too. Once we'll completely rely on somebody else so we can 'float' on technology we'll be in trouble.

I don't think that everybody must learn all the subtle details, but our society as a whole must continue to understand and respect what is holding our life's comforts.

Math daemons

So, numbers are talking to me. No big deal uh? Patterns seems to jump out of chaos, begging me to write down a equation defining theme. I can't even talk to the people I know about this stuff, because I and the people around me, didn't studied in math. So, thanks to the web and a few hours here and there, I do some maths alone.


It all started three years ago when my brain decided that it liked math more than before. A lot more. How do you fight something like that? Why would I even fight it? It only cost time, paper and a pencil, so that is one cheap pastime.

One cool thing about loving math is the the sheer quantity of problems that need to be solve. Its' an endless sea of 'fun'. Let the nerd in you free and take a look at the Clay Institute Millennium Problems. If I had time, I'd work on P vs NP and The Navier-Stokes existence and smoothness all day long. Just because it's there, like the mountain for the rock climber.

I bet, if I was in high school, I'd get my ass kicked for saying stuff like that. Good thing I'm 37.

I'll just keep filling pages after pages of notes, hypothesis and calculus about 'why in the world' some points in a non linear dynamical system are not stabilizing when m goes to infinity. I'm so close to the answer I can smell it.

Creative Programming

Some time ago, I was asked to give a presentation about Creativity At Work. This was part of a series of presentations where people from different fields were asked to give there view on creativity. I wasn't very shocked (but a bit sad) to find out that most of the speakers were visual artists or designers and I was the only programmer. So, holding the fort, I started working on my presentation which mostly revolved around my personal view of creativity and my creation process. All the time, I was expecting some weird comments coming from non-programmers regarding the fact that a 'computer-guy' would have something to say about creativity but, to my surprise, most of the sarcasms came from other programmers. That'll teach me not to watch my back. Apparently, for some coders, no creativity was involved or needed when programming...

I was baffled, because I see coding as a medium. I use it to create, the same way I use paint or clay. I then decided to spend a good part of that presentation demystifying coding and showing it for what it really is: just another tool. Now, it's one of my favorite presentation to give. I love the reactions I get out of it.


Why would a person sitting at a piano be closer to creativity than a programmer at is keyboard? Playing the piano is pretty hard an not that many people can master it. But if they do, it can be used to invent and break new barriers. For me coding can be used that way too, whether the output is music, image, video, robotics or anything else that can be experienced by other people.

#define JAZZ printf(“Do de do, de do wha!\n”);

I could fix keyboards

I got my first computer when I was 20 years old (a late bloomer) back in 93. At the time, if a keyboard stopped working, I could fix it. It was no big deal, most of the people I knew could do it to. Troubleshooting the problem was easy.

Open the thingy and look inside.
If it's dirty: Clean it.
If a piece is loose: Push or bend it back in place.
If a piece is visibly broken: Make a new one or replace it with part from another dead thingy.
If a circuit was visibly burned: Replace it with the same part from another dead thingy or declare that one dead but keep it for the parts.

With this check list, you were able to go a long way before throwing something away. So I kept on fixing keyboards, mouses, laptops and PCs for years. Then one of my Natural-Keyboards broke. “No problem!” I was thinking, getting my tools out. It's been a long time and couldn't wait to see what it looked like inside. It was a shock. There's nothing in there. It was two pieces of clear plastic sheets, one of top of the other, covering the space under all the keys. Imbedded in the plastic is a bunch of circuits lines and by pressing the two plastic layers, lines on each layers would form a contact. It was not dirty, there was no pieces to get loose and it was not visibly broken or burned. I was screwed. 'So long' my 120.00$ keyboard and 'Hello' the cheapo 19.99$ keyboard. Yet another reminder of to the consuming world.

Nowadays if something breaks, most of the time we throw it away. If we bother to open the thing, it often brakes in the process since it's not meant to be opened. Once inside, we look at the one chip that, somehow, does everything in-there and sigh before throwing the pile of pieces in the garbage.

I like to fix things. Most of our tables, desks and cupboards in the house are nice old things having a second life. Not that long ago, my wife came home with an old sowing desk that we turned it into a side table in the living room. While fixing it I remove the sowing machine pedal that was still attached inside the desk.


It was begging me to open it and so I did.


It was simple swivel harm that could make contact at five different places on one long coil resistor, or be in the 'fully on' position or the 'fully off' position.


I had a mixture of emotions. I started by being impressed with the simplicity. I knew I could fix that and I knew I could use that design in an eventual project. I was also angry that things are not made like that anymore.

Points vs Hours

The pains of task estimation. It makes that warm feeling of starting a new project disappear completely. No matter what's your method, Waterfall or Agile, you have to tackle that features list at the beginning of the project and estimate like there's no tomorrow. It's always too big and all those estimations will enable the team to scope. And so, you get to it. It take all of your team days to get through it and a the same time you know you'll have to re-estimate all of those features throughout the entire project.

I got tired of that. Not fast enough, but after 16 years of estimating with hours I couldn't face another project like that. That's when I gave a good try to the Story Points system. It appeared a bit suspicious so I 'googled' away on the subject. My goal was to find THE reason that would convince any programmers on my team to switch to a points estimation. Lucky me, I found one and here it is:

Behold the one reason to use points over hours when estimating.
>> If you show two different features to two programmers, chances are they will not agree on how long, in time, it would take to code it. They will, on the other hand, always agree on which task is bigger than the other one. <<

It takes us now 2-4 hours to estimate what took us a full week before. Here are the easy steps:
1) Put all the possible stories in a spreadsheet.
2) Create a second spreadsheet that will contain, in the end, your estimated backlog (aka the list).
* In this list, the big stories will be at the top and the small ones at the bottom.
3) Copy the first story into the list. Since it's the first item, just drop it at the top of the sheet.
4) Copy the next story into the list by doing an insertion sort based on the simple question “Is this new story smaller or bigger?”.
5) Repeat step four for all the stories.
6) Giving points to the stories starting at the bottom of the list, by giving the first one 1 point.
7) Using the Poker Planning scale (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100), ask yourself if the story above the last one is in the same scale.
* If it is: Give it the same estimate.
* If it's bigger: Give it the next increment in the scale.
* If it's smaller: Move it down until it fits.
8) Repeat step 7 for the entire list.

Tips:
- Try to make most of the list fit between the included values 1 and 13.
- Sometimes micro stories are at the bottom of the list. Give them the value ½.
- At the top you will probably find some Epics of values 20, 40 and even 100. those will have to be broken down into sub stories latter.

Those stories will never have to be re-estimated unless the descriptions changes dramatically. The velocity of the team can be calculated by the total of points they can burn in one sprint and that velocity normally stabilize after 2-3 sprints. With that value you can also predict how many sprints it will take to complete the backlog.

Go points!