In the long road of my developer life I had the chance to experience a very wide variety of organizational models. The most pleasant was in the context of very large open source projects, where actions are not planned but still organized, and things fall in their place seemingly naturally. Of course there is nothing natural in that. There is a category of people, that can be called catalysts, working as gardeners and building the pathways to collaboration. But because there is no predefined hierarchy, I thought chaos had some virtues.

In other hierarchical models, there is so much waste following the rule rather than its essence. It’s like there was an abstraction layer for efficiency and the staff follows the abstraction, paying no respect to the efficiency. Because after a time the set of rules is not making sense anymore. The environment moves fast and habits are hard to change. It’s taking long time for an organization to change its own internal rules.

But I also have seen non-hierarchical model totally fail. When you try to apply an open-source kind of organization inside a company, it cannot be done half-way, but it cannot be done fully.

For example the volatility of contributors is an essential part of the open-source organization model. Things are working the way they do because people are free to leave and join at will, or stop working when they decide. This is totally different in a company, even if you can get some approximation, leaving and joining is a more complicated process, and has a different set of motivations. And let’s not talk about the freedom to stop working at will.

This single factor leads the free-formed communities to get various incentives for contributors to feel good about their interaction in the community. The ones that don’t play well along other people just end up either in a leadership position because they are geniuses, or just leave because they don’t fit in. Or they stay and kill the project because everybody else leaves. But most likely they are the reason why forks exist.

But in a non-hierarchic company, those cowboys may end up hurting the whole process of collaboration by capturing some processes, getting very good at them, and give hell to everybody else for a time, under the privilege of the Power of the Bottleneck. It’s very hard to get those people to share knowledge because their position depends on it. If nothing is done, the situation will become uneasy and awkward at best.

Certainly in that type of situation, if there is some power in place to mitigate this danger, all can be good and well. But from my experience such power is hard to come by. Especially if the non-hierarchic aspect of the organization depends on him/her/it. Maybe there is some way to have some kind of catalyst role, but where I have seen such role in a company, it was informal and not an official position.

That’s too bad because I would love to experience again some real collective intelligence in the workplace the same way I have experienced it in some open source communities. I think maybe there are some companies out there that are doing that well, but most of the time it’s not going to be structural. Most likely it will come from a specific set of people that do real good in collaboration. I still wait to see a company that includes in its genetic code, in its fundamental principle, the seeds that make it possible to be efficient and still instinctive.

Well, almost 3 years. Green Ruby #1 was sent on feb 12th, 2013. Since then, we sent 156 editions, one per week without discontinuation, including a total of 5556 links. There is now 1691 subscribers to the newsletter. That’s quite something, for a mail that was just sent to some friends at the beginning.

During all this time, things didn’t change that much. In july 2013 the code was put on github and the process didn’t change much since then. I got a Rakefile to build the letter from yaml files and there is no need to change it. For the first 2 years Xenor was sending me some links by mail every weeks, then in 2015 Tysliu got back in and we used git to get both of their contributions. Later on, we got the slack channel where we throw between 10 to 30 links per weeks that I do my selection from. Nauman recently proved to be the most prolific contributor on slack. (btw if you want to join our slack group, it’s pretty open, just fire me an email).

We still don’t have any business project behind this publication. We are just a group of friends that like to keep in touch with the current trends, and that like to share the result of our weekly workout with our fellow coder brothers and sisters. Soon we will reach the limit of the free mailchimp usage (at 2000 subscribers), and that will be an interesting time. We will then ask people to unsubscribe if they don’t read the letter. Maybe registration will be closed if we reach the hard limit. But there is no plan to become a sustainable money-based adventure. So we’ll keep the cost to the minimum.

If you feel any gratefulness at all, pay it forward. Share your knowledge around you. Publish more open source code. Hug a friend or a stranger. Be nice and tolerant. Send some thank-you email to someone that published some open source code that saved your day. Love is wealth.

Recently Marcelo told me, that’s weird, how we do 10% research and specification, 40% implementation and 50% debugging in this industry. I’m more used to 70% research and specification, 20% implementation and 10% debugging. He was working in the hardhware industry for a while, and just came to a service-based company. This is actually a very interesting remark and it reminded me when I was in my twenties when I was working as a construction worker.

When I was young there was no internet and I had a 10 years break from computers. I had to take stupid jobs like working on construction sites for low wages. After that I went to art school and later on I worked on building sets for business shows. I have been shocked by the gap between those 2 worlds. When building a house, there is so much time spent writing plans, thinking things in advance. While in the show-business construction pattern, it was mostly about improvisation and managing inflexible time constraints, with one-time-use construction.

I feel there is the same gap in the software industry. Well it’s not exactly the same for sure, but the paradigm feels alike. In service software production, SaaS or ISP businesses, we tend to under-engineer the production. There are perfectly legitimate reasons for that, the life-cycle of a platform of service is quick, volatile and the value is not in the software asset but in the customer-user experience.

The Agile organization model reinforces this pattern, by providing a substitute to the early specifications, in the form of user experiences description. All this is fine and good. For a time. But with years passing we can see so many occurrences of ‘temporary’ projects becoming indestructible legacy monsters. It’s like there was some kind of tipping point where the development should shift from under-engineered to well-engineered but it’s rarely anticipated properly enough.

But it’s pretty hard to address that kind of problem. Throwing away the early instances is very costly, especially when the organization is shaped by a fast-paced reactive production model. Introducing proper engineering at early stages is also not a clever option, as the product has to adapt to the service, which depends on a constant feedback loop with the users.

I have the feeling that there is something missing. Like an evolution of agile that could include seeds of later engineering. Some way to make possible to start fast, and evolve in a solid and slower model later on without crisis or disruption. This is the perspective that I think was missing in that article I cited on green ruby 145. But I don’t know the answer to that problem. I suspect it will emerge by itself in the few next years.

For a while now, and more even since the rise of docker, it becomes a trend to split applications in parts and approach them as a collection of micro-services. This is not exactly new, I remember in 2002 having seen various applications based on this concept. But they had shortcomings. Development was harder and it imported a whole bunch of increased complexity because there was a lot of moving parts.

In a project that I have the occasion of following, I can watch the migration from monolith to micro-service and I can tell you, the architecture change is not simple technical decision. By splitting application there is a whole lot of application aspects that move out of the area of the developers team and are now the responsibility of the infrastructure team. The shift cannot be taken lightly.

From what I observed, the switch to micro-services can only be efficient if there was already a shift to a real devops organization. It means that the development and the infrastructure are more tightly coupled. Otherwise, it’s just a mess. The QA also can get crazy, and the networking layer gets increased complexity (or even dramatic latencies). Errors and services resilience also need an extra layer of attention.

Don’t move to micro-services if you are not ready for it, seriously, it can end up by shooting yourself in the foot.

Well in this last week of 2015, the have not been that much publication and the list of links is shorter than usual. Everybody is probably just having a life for a change, which is a good things :)

There is a lot of promising trends that may unleash in the coming year. I hope to see what ruby 3 will bring. Rails 5 is already almost out there too. But there is some interesting move on the side of Elixir as well, even if it’s still very young and hacky in my opinion.

On the frontend side, there is that big news that was announced last year, with Microsoft ditching IE old versions officially on january 12, it will be on tuesday next week. IE 11 would become the only supported version. A bold but welcome move. Maybe it will help adoption of JS recent native APIs. I suspect that if IE dies, jquery will not make any sense anymore as the JS stack will be more consistent then. But maybe I’m wrong, that’s just an intuition. And the end of support doesn’t mean there will be an instant extinction of old IEs, it may still take some more time.

Happy end of 2015

Take good time, use the calendar rotation as a pretext to have good resolutions, get wasted like if you were a teenager (wait, what? we all are teenagers here?), or do whatever makes you happy if like me you prefer to remain sober. See you in 2016.

SlackCast 2016

We had a lot of discussion with Nauman Tariq about how to make slack usage more lively, more useful, and such things. We worked together on a concept of event that we want to try next weekend. It will happen next Saturday (Jan 2nd) around 23:00 UTC (more or less 4 hours). If you want to participate, please shoot me an email, and we’ll give you the precise time when we know it, plus the how-to-join-in. It will be a first time, it won’t be perfect, but it will be a lot of fun.

Read more about it on the SlackCast manifesto. You also can join rubyonrails.link, that’s where it will happen.

It’s kind of a round number, this 150th edition of the Green Ruby Newsletter is an occasion to see where we are. At this day there are 1,610 subscribers to the email newsletter. The website has around 250 unique visits per day, which mostly are RSS readers. Those are anecdotal numbers. As we have no intention to monetize this initiative, it doesn’t matter that much. Soon we will enter in the red zone in the amount of subscribers and we will need to push some people out, those who forgot about the newsletter but also forgot to unsubscribe. It will happen when we reach 1,800 (because Mailchimp is still free under 2,000 subscribers).

During the whole life of the publication, we never missed one week. Last week, thanks to Xenor, I even could have some rest. Now I’m better, flu never last. We also have, for a couple of months, much more links contributions (thanks Nauman Tariq). All in all, our model seems to have been pretty sustainable.

This weekend we had our first hackathon in Taipei, organized by Gandi. That was pretty fun, to be there on the side of the organizers without actually being in charge of the organization for once. Such geek events are always so great for meeting and sharing, being forbidden to participate didn’t prevent me to push some ideas around.

During the course of the weekend, I joined mickey to push the creation of a Taiwan group for Elixir, for which we had an idea of a stream capture feature to gather slack discussion and index them. I also had an idea of event for FreeBSD portscamp with marcelo, so we made a FreeBSD Taiwan group on github as well (with a pretty neat logo). All this was actually not that much related to the hackathon but just emerging from natural proximity with other geeks.

Check my photos on flickr.

My attention was brought this week to Code in the dark events. It seems pretty cool. A 15 minutes race in html and css with no preview. But the thing that brought my attention to that format is the special editor used for those events with a special effect on the cursor. It seems to add a really dramatic effect on the competition. We need more ideas like that for pure geek fun.

First look at perl 6

For many people, Perl sounds like trauma. Because it didn’t move for a while, when I hear something is perl code, it sounds like it’s legacy code, old and dusty. Well, Perl 6 is going to come out for christmas and the situation may change. Perl 6 is in the lab for 15 years now, it’s more than time to get it shipped.

At first glance, they seem to have tried to ‘modernize’ the language, make it more idiomatic. It even seems it looks more like ruby, with the replacement of arrow by dots, the optional parenthesis, better exception handling. Well, overall, it feels cleaner. But it also seem to have some potential to mix functional and object-oriented in an interesting way.

So, maybe there is going to be a second life for the old perl. It’s a breaking version, old perl code will certainly break on the new version. So it’s almost like a new language. For sure I will still keep ruby as my preferred language, but I like multilingualism, so maybe I will give it a try .. again (last perl app I wrote was 12 years ago).

In 2 weeks Gandi organizes with .taipei registry a Hackhaton with pretty wide topic. It will be at at the Hi-tech Promotion Center in Taipei on December 5 and 6. I will be there (part of the jury), so if you want to have some week-end fun and are in Taipei at that time, feel free to join in. There will be prizes, free domains and hosting. I would love to see some ruby projects there.