devopsy.kinsta.cloud

Author: Bertrand Besnard

The 3L rule, a general piece of advice

What I am going to describe will sound elementary to most of you, even trivial but I know that there is a difference between being aware of something and actually doing it.

I have been working hard to spread the DevOps word these last few years and through experiences, project, conferences and articles I have come up with my very own little personal piece of knowledge; what I call the 3L rule.

Learn from the world.

This is the easiest of the three. Use Bing, Yahoo, Google, blogs like www.devopsy.kinsta.cloud, specialized websites, books and everything you want. The world is now at your reach, thanks to the internet and the wide spreading of smartphones. How many persons in the bus or metro around you are watching a screen nowadays? How many of those are actually watching the screen and learning something new? I know I see many playing cwazy cupcakes or any other game that is a time killer. However, they are exactly that, time killers.
Why would you want to kill time when your brain is most likely craving new knowledge, begging to use it for more than just identifying a simple pattern on a screen, dodging monkey poop or even cutting fruits? On a personal note, if you really feel like a samurai, go cut some fresh fruits and make yourself a nice juice.
The internet is available to you at all times with an almost infinite amount of information to collect. I am not telling you to stop playing, I am a hardcore gamer myself, but for your brain’s sake, you have to diversify activities. Do not always play, your brain is a sponge, make it absorb data or it will go dry.

Learn from those around you.

This one is a bit harder; it requires a couple of things:
– Some attention span: it is not always easy to be ready to listen to someone when you reach your tenth hour of meeting of the day (but then maybe you should learn to better plan your days) but try to make an effort. Many might disagree with that but most meetings have a message to convey. It might not be the main topic but a well-driven meeting can be a valuable source of information. To figure it out, the only way there is, is to actually listen to the person talking.
– Empathy: some persons struggle to get their message through, not matter how important it is. That is where you should try to demonstrate what might be a new skill: empathy. Instead of watching the speaker desperately and painfully trying to make a point, why don’t you try to help him/her. Do not jump in with what you know, that is stealing the light, instead why don’t you ask a question to put him/her back on track? It’s super easy and by making a human contact (mute people in meetings can be scary), you create a link with the presenter and might relieve some of the stress.
– Capacity of analysis: people do things around you, all the time. They work, they speak; they create value. If you are at the office right now (you should not be reading this but please continue), look around you. Take a quick break and go ask one of your teammates what he/she is doing and why. You might actually learn something. Do this repeatedly until you got the whole picture of who does what. Then try to wonder why and repeat the process many times until you reach the big bang. Through every single iteration, you will most likely learn something new. Forest Gump used to say: ”life is like a box of chocolate: you never know what you’re gonna get”. I prefer to think that life is like a puzzle, it is up to you to put the pieces together.

Learn from yourself

The hardest of the three rules.
You are flawed. Humans are flawed and make errors. What makes us worth something though is that we can actually learn from our mistakes. Once again, the big question you should ask yourself when facing an error is why.
Why did that happen? Was there an error in the process? Did I misunderstand something? Do I lack knowledge or skill to perform that task? Did I not get enough time to perform that task? Ask yourself all the questions you need until you can come up with a definitive answer.
When you do, that is where the tricky part starts. If you are to blame for the problem, make sure that if you were to redo the same task there would be no chance of the same error happening again. Fix the process, correct the documentation, train yourself, speak up! If this is someone else’s fault, do not point fingers, you are not in third grade anymore, instead help that person to do a better job so that, in turn you can perform your task as expected. Who knows, that very same person might help you one day.
The problem with that rule is to admit that you might make mistakes. Once again, humans are flawed and it is only normal to fail every now and then. Some of the greatest things were invented by mistakes: the tarte tatin, corn flakes or even the microwave oven. Maybe you will create something life changing too.

While that 3L rule should not surprise anyone, especially people in IT where learning is key, I find it a good reminder and always recommend everyone to apply it. It works very well in our domain since it is evolving so fast but it can be applied to everything really. Try the last rule with your better half for example, this might prevent conflicts to come like another fight about why you washed a pair of black jeans with his/her white underwear.

Good learning!

August 31, 2015
Why I became DevOps Certified

I usually do not care too much about diplomas or certifications. To me, one’s value isn’t reflected by a piece of paper but rather by his or her actions, dedication, motivation and efficiency. And yet, I decided to become DevOps certified and furthermore, become a teacher for that very same certification. Have I gone insane or did I make a choice based on reasons that could appeal to you? Read further to find out.

Set up a standard.

I have been advocating DevOps for years now, reading everything I could about it when it was just a fun word created by Debois and recently writing quite a lot and giving conferences about it too. One thing that always strike me is that, no matter the context, no matter the experience of the people I’m speaking to, there is always one person asking me: “but can you tell me what exactly is DevOps?”.

DevOps strength is also its weakness. By not defining a manifesto, a chart of good conduct or even a clear definition, DevOps leaves room for improvement over time but also creates what it tries to break down: silos. By being so undefined, you end with people “in the know” and the others who are desperately trying to get a grasp of an idea that’s clear to many.

A certification, while arguable, brings exactly that level of standardisation we needed. By enabling me to have a clear definition of what DevOps is, it gives me the opportunity to spread it further but not only that, I also finally talk about the same thing as others around the globe. Gone are the days where you would see a new definition a minute, now that we all know – and agree on – what we are talking about, we can finally start to actually do it.

I could have stopped here, taking the certification, being all knowledgeable about that topic but it would have been a bit against DevOps’ philosophy. Sharing is caring and if I get people to understand at least the basics of I what I preach, then we understand each other better and I make others better at their job (hopefully). And that’s exactly why I became a teacher: to spread the word and get people who don’t know to finally know. People over everything else, right?

The DevOps Institute.

Ok this part will sound a bit like a commercial but I’m just going to explain the reasoning behind my decision to go with that one.

There are many certifications about the topic popping up these days so it was not necessarily an easy decision to make. After all, since we are still discussing whether or not to have a certification on that specific field, nobody was more legitimate than another. And then I read this article by our dear Alan Shimel: here.

The fact that his name was associated with a certification intrigued me and I went to check it out. Then I realized that names I was already familiar with were also a part the institute (Lisa Schwartz and Jayne Groll) which made me think I was actually facing serious people.

I read a bit more about them and discovered that both Gene Kim and Sanjeev Sharma, two persons I highly respect and read a lot from, were part of the institute’s board.

That was it! It all went super-fast after I took contact with the institute. I filled up the usual forms and in no time, I was in the program, training myself to become the trainer, reading even more about DevOps, learning some new things and exchanging with brilliant minds before taking the final exam.

What it all means

While it won’t change your life, those of you who wanted to become unicorns still have to buy a costume for that, becoming a certification trainer gives you the opportunity to meet and help people who want to know more. Whether or not they take the actual test does not really matter. What matters is that you hold the same speech as others around the world and that people who come to you with questions might leave with a bit better understanding of what it is that you talk about.

Before comments rain down on me, telling me that this is heresy and that I should be condemned to watch Nyan cats for 48 hours non-stop, I just want to precise that I do not have any interest in anything other than my job. I am just advocating for a certification and explaining why I took this one more than another.

August 25, 2015
How DevOps could save the world; like your colleagues’ day
DevOps is about a few things but above all, it’s about communication and understanding each other. In that spirit, I decided to create a new day to celebrate: “Like your colleagues’ day”. The rules are simple:

The first rule of like your colleagues’ day is: You do not talk about Fight…
- Each year, on the last Thursday before summer (Thursday the 18^th of June this year).
Thursdays are ideal days to make people happy since they’re right before the week-end but not totally there. Right before the summer as it’s all sunny and nice outside.
- Present a token of your affection to your dear colleagues. Remember, it is a token, not a romantic dinner for 2 in a 3 stars restaurant in Paris. It could be anything from a rose to a beer after work or anything that makes sense to you and the person who receives the gift.
- Since DevOps is all about loving each other, the day is called “colleagueS’ day”, meaning that you should make as many people happy as you can. A box of chocolates for a team is a good way to make many happy at once for example.
- Once again, DevOps is about love so you should also consider this day as a good opportunity to bury the hatchet. If you have notoriously grumpy colleagues, maybe all they need is some consideration. A smile, an uninterested chat (meaning you actually listen to what’s being said and do not expect anything in return) and maybe a sweet or a coffee are excellent ways to make people around you happy.
- Even better, try to make someone you do not know happy. After all, people you have not talked to yet might be full of surprises, right?
- Money is not the point. For once, you can bake a cake, you can offer to get coffee for your colleagues, you can listen to them and maybe even share a bit too, after all discussions are better with two or more persons.
Actions have consequences.

It’s quite simple really, once you’ve introduced your colleagues to the concept (beforehand for better results) and the day has happened, take a step back and draw your own conclusions.

The first few times I have tried this, only a few persons followed but as the actions were not focused on one person only, others got to enjoy the day and joined in in later editions. The results were above expectations, people got to talk about food, cakes and pretty much everything that can be said during mingling. Where I really saw a good DevOps potential in this is when people from different teams started to play the game and started to communicate together. Some went for beers after work and got to know each other, making things smoother and easier at work afterwards.

LYCID is also a good opportunity to have activities. While you can think of a management breakfast, it’s not too hard to imagine a technological lunch where everyone is invited or a wine/beer lottery in which everyone can play. As long as the normal work time is respected, everyone should be happy.

Don’t stop me now, I’m having such a good time.

Well, you get the point by now, make your colleagues happy and try to create a better work atmosphere by being nice to each other. But that should also open your mind a bit and maybe you could apply a layer of niceness to the world around you. Let people out before going in the subway, hold the door to the person behind you, try to smile when you think the moment is right (you have to figure that out for yourself) and why not, give your change to the first person in need you see.

This can sound naïve, maybe borderline stupid but imagine a world in which people were nice to each other, no matter the social class, gender, religion… If we were a bit more tolerant, a touch nicer to everyone and a tad less self-centered, this world could actually be really pleasant to leave in.

Add a pinch of DevOps in that and what do you get?

Repeat the operation as many times as you want, being nice never killed anyone. Make it a part of your personal and professional culture to be nice, available and polite. Through an iterative process, determine when you can smile without looking like Forest Gump and after a while it will be automatic, you will naturally become good and this will feel nice, trust me. Check the impact of what you did on your colleagues, measure their happiness and if you think things did not change enough, don’t wait until next year, be spontaneous and repeat the operation. After all, baking a cake and getting the coffee for your team should not take too much time or efforts, should it?

If you feel this could do a difference, spread the word, DevOps is about communication and sharing. Feel free to improve the rules, feel free to ignore some, in the end, all I want is to make you happy.

I’ve said this before during a conference but as we talk about unicorns, rainbows and other nice things when we mention DevOps, why not dream that we could also make a little difference in the world surrounding us. A little is better than nothing. DevOps could save the world!
June 4, 2015
Service virtualization – The hows and the whys.

Close your eyes and take a deep breath. You are on an island, smelling the iodine coming from the sea, the sun is gently caressing your cheeks and you are sipping on a cocktail in the middle of the afternoon. Your phone is off, in a place you forgot and you do not have direct access to the internet. You are a sysdamin and for the first time since the beginning of your career, you take a break, an actual break to reload your batteries and you are not even thinking about work because you KNOW. You know it is all going to be alright, as it has been since you implemented service virtualization in a really DevOps oriented way.

What is service virtualization?

First of all, let me say that service virtualization is not something new but many are still unaware of what it actually is and only a few good products are available.

You can find a really good explanation of what it is in this post from Chris Riley: https://devopsy.kinsta.cloud/blogs/service-virtualization-window-advanced-devops/ but I will try to sum it up.

In order to avoid confusion, it is also necessary to briefly explain mocks and stubs. Mocks are usually programmers written tests that check the behaviour of a specific piece of code like which methods are called, in which order and if sub processes were created. Stubs on the other hand check that for any given input, the expected result is outed. I often refer to them as logic tests and I/O tests.

Service virtualization has nothing to do with mocks or stubs. It mimics the entire behaviour of an application as if it was an actual one deployed on a server and connected to a database, backend etc. In order to enable this, data will be recorded from QA (and anonymized) and the whole behaviour of the application will be recorded. Going through security layers, calls to a database, updating some values, even timings can be recorded for performance testing. Absolutely every single operation is stored and if the test data is well chosen at the time of recording, all cases can be covered.

For those of you who are into gaming, think of it as an emulator. You do not need a SNES, Genesis or Neo Geo to play your favourite oldies, instead, all you need is an emulator software and the ROMS. The emulator will behave like a gaming console on your computer, reproducing inputs and outputs with high fidelity and translating CPU instructions into different ones your computer can understand.

If you are not into gaming, and that is a shame if you ask me, think about virtual machines. When you install a Fedora in a confined environment on top of your favourite edition of Windows (or Mac OS), what you do is pretty similar to service virtualization as well. Your Guest OS will send instructions to the different components of your computer which the virtual machine will catch, translate into commands your Host OS can understand and send to the concerned components. It sounds complicated but it works like a charm.

What it can do for you.

As it operates on local servers or even better, on containers (check out Docker if you have not done so yet), it is virtually always on. Downtime is a thing from the past and updates can be scheduled and performed when people are not at work. How much of your project you want to cover is up to you and your needs but once you have started the process, why not go all the automated way? If you do, that means that your programmers will have access 100 percent of the time to environments that are up, running and that reflect actual services.

What is the point of having test environments then you might ask. And here is the answer you can give stakeholders: none. You can achieve good environment resilience, actual data tests and higher-than-ever response time through service virtualization. If well applied, and I really want to emphasize on that, service virtualization makes good ol’ test-environments obsolete.

Once again here, the benefits mentionned by Chris Riley will speak for themselves: https://devopsy.kinsta.cloud/blogs/service-virtualization-window-advanced-devops/

Taking DevOps one step further.

Like all great things, service virtualization comes at a cost. In order to fine tune it to your requirements, it is going to take great efforts. You have to decide which services, ideally all of them, you will provide your programmers, which data sets are representatives of a functional application and of course, install and configure it all. The biggest benefit that you can identify here already is that developers, testers and operations have to be involved and work in a close collaboration. This is your opportunity to make different teams understand what others do. Get them all together, make them work together in a form they are not necessarily familiar with: cross-teams brainstorming.

Brainstorming, if well done, can be a very powerful tool to come up with creative solutions to problems that were not identified as such beforehand. It has to be directed though. To brainstorm doesn’t mean talking nonsense about non topic related things. Having a neutral person in the room who focuses the discussion around a few pre-established points and who keeps track of time is the way to go. Scrum masters are generally good at this since they have an overview of the project and its problems and can quickly identify the right persons for a task.

Getting developers to update their own service virtualization server with the latest data from QA means better communication with testers. Operations have a critical role here too since they setup the environments and give the how-to to the different teams.

Another glass sir?

Once your teams work together on an almost 24/7 available server and understand how it works, all you have to do as a sysadmin, is to relax a bit for once and focus your brain and time on how to improve processes even more, enhance the quality of deliverables and tighten up the now-existing bonds with your colleagues. Oh yeah, and if you’re on holidays, stop worrying about that potential catastrophic phone call, just worry about yours and yourself.

March 20, 2015
Tips to change culture (at least in your team).

DevOps is all about automation, enhancing the Application Lifecycle Management and culture change. In the last few years there have been tons of conferences and articles about the benefits of a cultural change on a project, but I have yet to read a paper about how to actually change culture.

How do you manage to get people to change the way they think and act towards each other and professionally? This is a huge challenge that most DevOps leads will have to overcome. Here are some of my ideas.

Create cohesion.

The first thing to keep in mind when trying to implement DevOps (or on any other kind of project for that matter) is that people who don’t have fun at work will not perform as good as they could. How to make people happy to go to work is up to you, but I find that simple activities such as team exercises and/or after-work beer work best.

Whenever a new member comes to a team, try to get everyone together to have fun and talk. Take them out to a game of laser tag, get some sumo suits and make people try wrestling amongst other sports. Try to identify a common interest for a sport and have everyone play together. Remember, this is not a competition, do not force people to participate if they don’t feel like it. There are neither losers nor winners, so try to balance the teams as well as you can.

Another way to get people to know each other and ease potential tension is to take people out. Take your team out to discover a new restaurant or pub and discuss the place together, what they would have changed in the decoration, which Belgium beer is missing from the menu, why on earth do they serve foie gras on a scallop… The point once again is to try to discover others’ interests and behavior outside of work. This specific activity however needs some rules; try to limit the alcohol intake and by all means – do not talk about religions or politics. While those two topics can be fascinating with your friends, some people might get offended, even if they say they don’t mind.

Back on the project, the use of Scrum is highly recommended. Even though the benefits are debatable, I find that shy people tend to open up and contribute more during those sessions than they normally would. On top of that, Scrum meetings include everyone on the ladder, from bottom to top. Only one rule here: no matter what, remember to actually do your daily stand-up, if you can’t do it personally, get one of you team members to conduct it and check afterwards that is has been done. Delegating is not a sign of weakness; it just shows trust in your team.

Create incentive.

People make mistakes, always. There are, however, ways to get to get people to make fewer of them. Pointing fingers and blaming people is definitely not a solution. Making people pay for their mistakes is more efficient. Say each team member has to pay 50 cents (adapt to your own country and project) for every mistake (new bugs, fail in commit, forgot to write a comment in SVN/Git at commit…) they make, and things might start to change. The point here is not to rob your employees, so you will have to find a creative way to use that money. You could for example gather that money at the end of the month to buy candies for everyone. But then that’s just punishing people, which does not make it fun, so you have to come up with a way to compensate for that too. If the management doubles every penny in game, then everyone is involved and there starts to be some interest. But then again, you might get extra bugs because everyone loves candies, so you could triple the sum of gathered money when there are fewer problems than the previous month.

At that point of reading, you might think it’s actually costly and doesn’t benefit anyone except dentists. Well you’re wrong. In the worst case scenario we’re talking about tens of dollars a month, and given that you will actually get some accurate metrics about this, this is a no-brainer.

If candies are not popular in your project (is that possible?), you can also get the good old “employee of the month” award to whomever created the least problems and reward him/her with cinema/theater tickets, a dinner for two… Please note that on high stress periods, dinners for two, even though a lot more expensive than regular rewards, are a lot more appreciated as they might represent a good opportunity to ease work related tension in a couple.

Develop people.

Don’t see your colleagues, especially the young ones as just resources, rather think of them as potential wonders. Everyone aspires to shine and it’s all up to you to make it happen. Do not ever take someone else’s ideas and get the glory. That would be idiotic, mean and potentially a good way to get your colleagues to quit or resent you. Instead, go on, try to encourage people to speak up, make them give technical presentations, make them speak and give them a positive feedback (even on failures, there are always good ways to explain how one can improve).

Once again, Scrum can help you with that. Identify the elements in your team who need some help and pair them with some others that are more comfortable for some small sessions of peer-programming, peer-presenting, peer-testing… once a week. It can cost some time in the beginning but the benefits are potentially huge in a long term perspective. There is nothing better than a team that has learned to work together and where the first reflex when someone ask for help is to actually help, not to ignore.

Demonstrate values.

One of the things that really is important to remember, is where you come from. No matter your position today, you didn’t start at the top and you’ve had to learn all the values that you try to get your team to demonstrate today. So show them every day, what it means to create DevOps; a potentially highly stressful job, especially in the beginning, where tension between people should not exist. Smile as much as you can, take time to help others even if you that means staying later at night, be proactive once again, try to identify potential bombs and defuse them before they are seen by others. All in all, be nice to others, treat them as you would like them to treat you.

But what if you are faced with a pigheaded team member? Someone who is convinced they are right, no matter how many people disagree? Well once again, do not ignore them; that will only create frustration. Instead, get some documentation or an expert and talk openly about the topic without being aggressive. In the end, the team member should be respectful of your efforts and have won some valuable knowledge in the process.

The biggest piece of advice I have is this: Do not ever be arrogant, do not ever be pompous. Help others, always, and do it nicely and in a humble way. The leaders we like are not the ones that talk too much but the ones that are the nicest to work with.

Changing a culture on a project is a tough thing, but it can be done with a few tricks and a lot of time spent helping others. Luckily, smiles and good atmosphere have a tendency to spread fast and the tight links between Dev and Ops can be strengthened quite fast with some goodwill.

December 11, 2014
DevOps: What It is and How to Cook It

What is DevOps?

DevOps is a funny concept.I have spent the last few months trying to find an accurate explanation of what it is, reading books, articles and participating in discussions which led me to the following personal definition: DevOps is a set of processes which aims to enhance the Application Lifecycle Management (ALM) of an Agile project by creating tighter links between the different actors (Developers, Operations and testers) through the use of automation and communication. Wow!

Why DevOps?

The traditional development cycle of an Agile project usually leads to two to four major releases a year which means the delivery of a lot of new functionalities, tons of bugs fixes and therefore a lot of testing pre and post production. Such releases can prevent the good visibility of specific problems in the application itself; create a huge stress on the people involved as it is not conceivable to miss a deadline with two releases a year, and create an ever-extending list of requirements for the next release.

While many important projects succeed in this approach, many major companies such as Facebook, Amazon or Flickr have chosen to perform shorter cycles of over ten deployments to production a day. That process enables them to have a very specific scope per release and with the help of automation almost everywhere, especially in testing, creates higher quality deliveries.

How to DevOps?

One important thing to remember here is that you cannot call Merlin and ask him to send you a “DevOps person” to solve all your problems, including your personal ones.

In order to achieve a successful transition from a two-releases-a-year cycle to a ten-releases-a-day one, it’s going to take time, a lot and skill, a lot. The team in charge of the changes will have to study the way you work, analyze the current process, identify potential problems and then make a list of recommendations

Those recommendations usually include breaking the different walls between people. One big goal of DevOps is to make people realize that whatever their role, their objective is common with the rest of the project: to deliver quality and to do so efficiently. Imagine for one second that a bug is found in pre-production (it happens). Usually the sysadmin will perform an analysis within its domain and if he cannot find the cause or identifies it as a “not my fault”, will forward the bug to the development team who as usual will answer “it worked in dev., must be environment related”. The pointing fingers game will take some hours maybe days before someone finally jumps in and finds the problem.

Now imagine the same bug handled by people on a project where DevOps is used correctly. When the bug is identified by testers, developers and operations are contacted together and retrace all the steps. Is it due to an error in the specifications? Can we reproduce it in other environments? What changes in the code triggered that bug and so on and so on. By having people working together instead of one after another, you create ownership of the product and a strong team feeling. If everyone is concerned when a problem arises and if everyone understands the application from the conception to its application, problem solving becomes a breeze and an actual good way to create natural collaboration between people of different groups.

The other main changes that come with DevOps are related to automation. Maybe easier to implement than mentality changes, setting up automated releases, testing, deployments requires expertise and a lot of testing on the way but can lead to great time sparing.

DevOps in Real Life.

One my favorite thing in life is food. Eating it, making, talking about it… Let’s use food as a simple example of how to use DevOps.

Imagine yourself in a starred restaurant kitchen; there is the executive chef, a sous-chef, a saucier and a vegetable chef.

The chef has envisioned a dish and asked his new staff to do their parts based on what he explained to them. Ideally this would go well but: the sauce is too acidic for the vegetables and the plating is terrible with the shapes and colors making the dish look sad. Everyone blames each other and the utensils for not being adapted.

Add a zest of DevOps to the recipe and try again.

Now the vegetable and saucier chefs work together and make sure that what they produce respects the wishes of the chef while working perfectly with the protein produced by the sous. It doesn’t happen instantly but they all try the overall dish together and after many iterations, manage to produce an experience that is visually astonishing on a plate and which flavors combine divinely in a way that is neither too heavy nor too light. To be able to cook and plate correctly, they had to buy more adapted utensils that everyone in the staff could use if needed.

One month goes by and the head chef asks them once again to repeat the operation on a new dish.

This time the whole staff knows how to work together and while everyone is working on his own specialty, they all work together from the beginning, sharing their experience with the utensils and understand which way to go, tasting their creation as they progress, leading to another perfect dish done in a much shorter time.

DevOps is not magic.

Many things can go wrong in a project and DevOps might be one possible solution to solve some specific problems but it is important to remember that implementing new processes, changing mentalities and using new tools can take a very long time and be really expensive.

You have another definition? You don’t agree With me? Feel like adding something? The comments are here for that, please let me know what you think, sharing is caring!

December 3, 2014
The fashionable IT crowd

The IT Crowd

I was recently reading an article in Marie Claire UK (yes I do read non-nerdy publications, some higher AI should sentence my brain to enter a loop without an exit condition) which explained that women should start learning how to code in order to become successful professionally. That triggered my curiosity and I started to wonder when IT became classy enough to be mentioned in a fashion magazine. This might be the time for a little history.

Don’t blame Information Technology.

Once upon a time, well before the internet – yes kids, there was a time where people had to read books to access knowledge – IBM was ruling them all. It was such an important and powerful company that you could likely compare it to Google today. IBM salesmen were to wear suits, ties and an attaché case every day like other any other corporate person and techies had to wear a simple white shirt with an IBM logo on it. IT fashion at that time was pretty much neutral and IT was seen as any other field of work.

In the early eighties, Bill Gates who started to do business with IBM had a look that would, for some reason, stick with IT people for decades: oversized glasses, poorly shaped and tasteless beige tops with a pair of equally bad looking trousers.

Steve Jobs on the other hand when not representing his company officially was already seen wearing his now infamous denim and black turtleneck combo. The power of branding.

How come then that with so many different styles in circulation, one prevailed in people’s minds as the standard geek outfit? Well, in order to understand, we have to broaden our search a bit and we can then realize one thing: in the eighties, almost every person that had an interest in science had poor social skills and or almost no interest in fashion or styling. While this is a gross generalization a quick internet search for images of “nerd 80s style” should demonstrate what I mean.

Music has changed it all.

In 2001 Mp3 players had existed for years but were a niche market as their price was too high, their storage capacity too low (one album would fill up a player) and they required a computer and some technical knowledge. Downloading a song was also an obstacle as there was no massively spread peer to peer or legal solutions at that time.

Then came Apple with its iPod, almost like a piece of art that created curiosity and attraction and offered enough storage space for many albums at once. I think this was the first time the public saw an interest in a computer or mac related device. CDs while hugely popular were impractical – think of carrying more than one of them with you everywhere you go – huge and mostly unreliable for jogging or walking fast.

People who wanted an mp3 player and who did not own a computer had to get one and access to the internet. The internet which was mostly used by “people who knew” became more and more popular and people started to massively use emails and chats (msn, aim and all those brands which do not exist any longer) and slowly gained the knowledge to use internet in a more efficient way. This led internet providers to offer higher bandwidth and the development of a plethora of websites with ever more content.

With access to everything at all times, computers gained in popularity and the emergence of smartphones spread the use of internet even a bit further.

In the mid-2000s, technology, the people traditionally associated with it and their culture then became hip. That was the beginning of the “geek chic” trend, often confused nowadays with the hipster subculture. People started to wear old style clothes such as suspenders and those oversized horn-rimmed glasses. Not adapted to the business world, this trend quickly faded however with the public gaining awareness of things beyond glasses, thanks to popular TV shows such as The Big Bang Theory or Chuck, the geek culture spread widely.

Finally recommendable

All those factors contributed to IT becoming less and less a world of “freaks and geeks” and more and more a profession as acceptable and as open to everyone as any other, finally showing up as a recommendation for a professional path in a women’s magazine.

It was about time.

October 21, 2014
Programming: from too hard to too easy

I can still remember how happy I was the first time my friends and I managed to program a Pong alike game on our Texas Instrument calculators. It took us weeks before figuring out the algorithm and months before being able to render something decent, almost playable, with zeros and ones on the screen.

At that time, we had to understand low level languages that young folks can not even name today. We had no debug tool and the only way to understand why our application crashed was to try to reproduce the case… on paper.

Later on, I studied in the only university in France that was teaching both Cobol and Java. Their philosophy was that however important Java was becoming (it was the beginning of the two thousands), it was still important to understand the main concepts of IT. They also forced their students to learn the language theory but that was just for the fun. In my last year there, only 6 years after programming my first pong game, we had to produce an OpenGL 3D first person shooter game. It was nothing that we would ever use later on in our lives, but understanding the key concepts of 3D and being able to use complex math was more important than filling up a CV. The whole project took us a couple of weeks.

With today’s technologies, you can build up a playable level of a single game with the latest lighting and texturing technologies in just a couple of hours, thanks to the power, the diversity and the flexibility of the available tools.

The same concept applies to pretty much everything that requires coding. We went from writing eighty characters per line with no objects, to defining a variable name and a method call represented by a box.

Nowadays, most people learn IT the “fast way” that is, with tools that enable auto-completion, give coding advices and have integrated GUI builders based on drags and drops. Creating an application has never been that easy. A couple of clicks here and there, a Google search or two and voila!

But is time sparing worth sacrificing knowledge? What is the big picture on a long term perspective? What will happen to hardcore experts?

If programming is that easy, debugging becomes harder. With all that generated code and programming conventions not always being respected, if someone else than the original developer has to read and fix the code, things can become quite hard and costly. How many of us had to fix a code which contained variable names like txtBox1, txtBox2…, or even worse, ex girlfriends’ names? How many hours are spent yearly debugging simple mathematics operations because precedence rules are not respected? Those are just the easy ones, the most common and harder coding mistakes include, but are not limited to: global variables accessed and modified randomly, methods of tens of lines, exceptions being caught but discarded…

There are tons of resources out there for developers to learn from and many acronyms to discover or to deeper investigate like TDD or BDD (test driven deployment), which is an often mentioned key to high quality softwares, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) which describes the “first five principles” of object-oriented programming and design and so many more. Thanks to the internet, knowledge is only a click away, motivation however, has to be found somewhere else.

On a long term perspective, without proper training, programmers won’t learn much more about the fundamentals and might become somewhat limited. Their errors’ becoming someone else’s to fix and their lack of knowledge becoming time consuming for others.

Most companies understand that principle and have found an easy solution, encouraging through different means, their employees to develop their skills through seminars, conferences, classes and basically everything that can potentially make one become better. This tendency has started in most countries that understand that programming can be a career path and not only another step on a stair that leads to management. Unfortunately, training individuals can be costly and not everyone can afford it. That is where dedication and thrive to learn kick in, buying a book and reading it is affordable by most.

The other problem implied is that as time goes by, experts will become rarer and busier, leaving new programmers to themselves, in charge of their own fixing, eventually leading to chaos and destruction of the world as we know it.

Already in 1995, Niklaus Wirth stated that “software is getting slower more rapidly than hardware becomes faster”. A variant by David May is even more explicit by doing a corollary with Gordon Moore’s law: “Software efficiency halves every 18 months, compensating Moore’s law”.

This proves that knowledge is the key to a good programmer and IT, as every single science, always evolves and so should the people working with it.

October 1, 2014
COBOL: Completely Obsolete But Omnipresent Language

The programming language COBOL is a nuisance, something everyone wants to get rid of; however, I’m about to advise you to learn it. It might be a gold mine.

The IT world is a fast paced one where obsolescence is the rule and where things evolve so fast that any person who wants to understand it has to continuously learn and train. Languages, methodologies and technologies keep on changing, evolving to make programming easier, safer more robust and above all, faster. As to every rule, there is one exception.

In 1959, convinced that the English language would be more suitable for programming than machine code or the assembly language, Grace Hopper creates the first ever human-readable programming language that would survive for over fifty years: COBOL

COBOL, 55 years old and still in its youth, not ever thinking about retirement, has become a nuisance, something everyone wants to get rid of but no one has the courage to try.

Are we ready to replace COBOL?

Nowadays, 80% of financial transactions are made through COBOL programs and most of those programs have been written decades ago and have proven to be reliable, effective and efficient. To top it all most companies which are still using it have invested a lot of money in those systems and if it is not broken, why fix it?

So why would one want to change them? Well, it’s not Java. COBOL was created in an era where IT didn’t have the meaning it has today. A program was mainly designed to replace simple repetitive tasks such as retrieving data from a database, performing a couple of operations and generating a report or updating some other data. Today’s programs have to present a front-end to thousands of users, go through different layers of security, logic and quick data retrieving before accessing the back-end to ultimately alter data and send some information back to the user. Alternatively, a program can be a tool to design objects and buildings, communicate with your friends, frag your opponents, enhance your reality, you name it… The whole philosophy behind the conception of programs has changed so much in the last two decades that having such an outdated technology that almost no one knows anymore represents a potential danger. Only few people learn COBOL these days and even though those systems are not supposed to evolve much, there is always maintenance to be performed. But are we ready to replace it just yet?

Fast, robust and future-proof language

COBOL has been on the brink of death for years but its presence overall hasn’t changed. Not only are the cost to migrate from one technology to another huge but the choice of the replacing technology itself is a million dollars question. What better than COBOL to perform typical COBOL operations? While not designed to be an Object Oriented Language such as Java or C#, COBOL has slowly adopted some of their aspects, extending itself and its functionalities to a point where almost everything is possible. Everything with the exception maybe of creating user friendly or good looking Human-Machine Interface. In that matter, nothing has changed much since Hopper’s time. Many of us still remember the frustration of spending hours to get a simple screen with a couple modifiable fields and those who still use them must be dreaming every day to replace F5 and F6 by simple buttons…

But that was never the point; the point was to have a fast, robust and future-proof language.

COBOLs main contenders

The discussion is still opened as to which language could replace COBOL but here are some pros and cons to the main contenders:

– Java is easy to learn, well spread and has a huge community of developers already but is rather slow compared to other languages despite the existence of some specialized compilers and massive improvements in the last few versions. It is also arguably still in its youth and the yearly evolutions and changes to the language don’t play in its favor. Not to mention the recent security issues.

– C++ is fast, flexible and robust but it takes time to learn and understand and has what is maybe its biggest flow, potential memory leaks. Something COBOL and Java programmers have, almost, never heard of. By conception, it offers a lot of freedom to developers but that also implies few ready-to-use components and thus it’s less cost-worthy.

Let’s say that one day we manage to find a clear winner, another major problem will suddenly emerge. COBOL was made to perform all kind of operations in one block but we have learned throughout the years that modularity is the key to success. So if we replace COBOL itself by another language, we will also need to have databases and SQL, a front end and HTML, most likely a Business Process Management Software to externalize workflows… Basically, replacing COBOL programs means creating whole new ones.

The ultimate piece of advice

While it is possible to replace this aging language, this comes at such an extremely high cost that we can anticipate its presence in at least the next twenty years which brings us to the ultimate piece of advice of this paper: if you have the opportunity to learn it and enough motivation to write white on black interfaces, go for it. The pool of competent COBOL programmers is getting smaller by the day and the demand doesn’t change, meaning that this personal investment might reveal itself a gold mine.

September 3, 2014