Adapt, connect, innovate or die...

Last Tuesday evening, I was invited by Thomson Reuters to attend one of their special events dedicated to innovation in finance.

The location was quite prestigious (i.e. the "Maison Blanche" in Paris) and both the organization and the speakers were truly excellent.

To be honest, I was expecting much more marketing and sales speech from Thomson Reuters than what we had actually. But Mind you, I am not complaining ;-)

The event started by a short but brilliant 20 mn talk from Navi Radjou. He's Innovation & Leadership strategist, but also co-author of the "Jugaad Innovation" book (A frugal and flexible approach to innovation to the 21st century).

We then continued with an excellent 45 minutes panel about HFT, algo trading and innovation in finance. This panel was animated by Guillaume Thouvenel (Executive Coach & IT Emergency Manager) and speaker were Jean-Marc Bouhelier (CEO Celoxica), Dominique Ceolin (CEO ABC Arbitrage), Olivier Martin (« Unified Platform » COO, Thomson Reuters), Philippe Musette-Sykes (Senior Advisor to the Board, Kepler Cheuvreux) and Riadh Zaatour (Quant Analyst, McKay Brothers).

After this panel and a conclusion by Rémy Granville (Thomson Reuters), we all networked around a buffet... in front of the illuminated Eiffel Tower.

Yes the panel was very interesting, but I'd like to focus here on Navi's intervention.

Innovation by Navi RADJOU

The topic was "how to reinvent financial services in the 21st century".  And its core topic was really about innovation.

Navi first tackled some of the CEO common beliefs/myths: "Our group is Invicible/Irremovable, our group is Universal, and" ... another belief  which I can't remember here, sorry ;-(

Irremovable?

In fact, the average lifetime of big company moved from 75 years (in 1940) to 15 years (in 2014)... Too big to fail? Nah... Navi took few examples of Disruptive effect.

For instance: Marriott & Accor are really big companies in the hostelery/inn business. But Airbnb jumped out of the blue in 2008. They are now able to provide more rooms to end-users than Accor and Marriott can. They can even do it in some emerging locations, were the ol' groups aren't able to create Inns or to take market shares.

Music, Taxis, ... in fact, the concept of impermanence seems to generalize in every business domain.

Wealth management is another digital disruption victim for instance.

Gulliver and Lilliputians ...

Because everything is possible now with crowd-founding. It's a new deal. For everyone (e.g. the recent 41 M$ raise for the RSI video game... 41 Millions $ !).

Universal?

By the way, do you know that Nigeria emerges 3rd most profitable stock market in the World?!?

Navi tackled the "Universal" belief of CEO (i.e. our activity or business model is universal). His main point was that there are lots of innovations and disruptive models emerging from all around the world. Africa, Asia, South America, ...

Let's take M-PESA for instance. This phone money transfer solution has dramatically transformed the lives of all Kenyans (no need to take the risk to walk with money in their pockets anymore). It has also revolutionized the way Kenya does business. Without banks.

According to Navi, there are lots of things to learn from what currently happens in those emerging countries & markets.


So. How to adapt, change and innovate to succeed and survive in that moving world?

Agility advocacy

Agility is a must for all modern companies. Indeed. When everything is changing all the time. Companies have to get ready to embrace those changes. Quickly enough.

The GAFA threat

Google-Apple-Facebook-Amazon. If you don't change and embrace new technologies & ways to make business, those giants will do it for you.

And there is a pattern here. Google is emblematic, but all those successful companies have built their own ecosystem to speed up & ease any of their new moves now. For financial services (and any other industries), there is probably something to learn from.

Transcend the Business/IT silo to innovate

According to Navi, the solution to innovate and be successful nowadays is to transcend the Business/IT silo. At last, I would say.

Open & connect with the others

Another key to success for companies is to open themselves to the others:

•  To open close discussions with their clients (through social networks, or via prototypes)
•  To open for co-construction with their partners
•  To open for co-innovation with their technology suppliers

"Innovation": a modern bias?

Navi also warned us about a bias that most of the company have nowadays: they create dedicated teams for innovation, dedicated awards, dedicated labs... Openness is the real path to follow. You have a lab? why not. But don't let dedicated people play alone to the game of innovation. Let's open it to everyone, including external partners.

By the past, innovation came from inside the 4 walls of the companies. Innovation is now happening outside the 4 walls. It's happening among partners, thanks to active networking that companies need to foster.

Navi then introduced us the 4 roles of innovation: the Inventor, the Transformer, the Sponsor, the Connector.

IT guys should be the Connectors for innovation. Not the inventors!

Instead of desperately trying to be Inventors, successful IT divisions are now much more Connectors.

IT guys must inform their business of what's going on with technologies.

You don't need to invent to innnovate! Knowledge is NOT power. Finding and sharing knowledge IS power.

And technology watch is not sufficient. We should also watch new usages  for inspiration. This is exactly what BBVA is doing with its Cross-Country Emerging Markets Unit.

Takeaways

Navi left us with few takeaways:

1. IT guys must exit the pure function of back office and become more strategic partner with their business
2. IT need to reinvent its relationship with its suppliers. Fostering more on (technological) partnerships and co-construction
3. IT needs to foster and rely on an "Agile Architecture" to sustain its business and to continuously innovate.

Agile Architecture?

Yes, with mostly 3 drivers/qualities:

1. Simplification
2. Openness (towards 3rd parties)
3. Evolution

Talking about simplification, you definitely have to see this!

Yes, I'd like to conclude this post with something that my mate Cyrille had shown me. It's a short, but exceptional TED talk from Yves MORIEUX:

> As work gets more complex, 6 rules to simplify <.

I strongly advise any people working in a big organization to take 12 minutes to see it. You won't regret it. A truly engaging & inspiring contribution.

Raising the bar

It's been a while now that we organize and attend various kind of Software Craftsmanship events at work.

Usually at noon, we leverage on our big company infrastructure (meeting rooms, town halls,...) to gather more and more people -month after month.

Our objectives: to meet, share, connect, learn, debate, code, hack...

After few years of difficulties (we faced some issues while our organization was scaling), we started now to raise the bar collectively by improving here and there our overall mindset and curiosity.

There is still lots of things to improve -mos def- but I have the feeling that we have triggered some kind of snowball effect here. A positive snowball effect.

Let me describe you the kind of events that continue to help us on that journey.

Brown Bag Lunches

The concept of Brown Bag Lunch (a.k.a. BBL) was probably the spark that ignited the fire of that positive dynamic. And this is still a very popular kind of event here. Probably the most popular one.

Introduced within our company by Romain LINSOLAS -our local Huggy Bear- and from an original idea of David GAGEOT (famous french Software Craftsman), the concept is pretty simple : we contact a speaker -usually an external one- and we welcome him for a free talk within our wall during lunch time. It's free, opened to every developer (first-come, first-served policy for seats). The topic may be whether on a craftsmanship technique, an open source library, a noSQL db, a kind of architecture (e.g. reactive, distributed, lambda, hexagonal), a low-latency middleware, etc.

Everyone is coming with his own Brown Bag (for the sandwich), and the organizer generally pays the speaker's lunch.

Usually between 1 or 2 hours depending on the topic and the Q&A session, this is the perfect spot for anyone to learn stuffs (even for the "I  have no-time for market watch" guys).

For the speaker it's a good way to prepare himself and to rehearse before a more official conference (like we did for our DEVOXX sessions). It's also the opportunity for him or her to meet and chat with other craftsmen, or to be the first one that the company will call when expertise on that area or product will be needed.


Since we have a lot of speakers working within our walls, but also a crowded audience of developers, we recently started to organize internal BBL sessions (with internal speakers). Some of us are also now "baggers", being capable to meet you within your company to talk (done with my mate Cyrille DUPUYDAUBY at betclic for instance).

If you are in France and want to organize BBLs, don't hesitate to consult the official site: http://www.brownbaglunch.fr/ to find speakers near your office. You won't regret the experience!

Coding Dojos

Widely-known, the coding dojo is an excellent way to learn and discover other concepts or techniques. It's also a great occasion to connect with and to have lots of fun with other passionate developers.

The concept? We meet at noon (10-20 persons in the same meeting room) and we try to solve in one hour or two, a small problem (the code kata) proposed by the chair of the session. 15 minutes before the end of the session, we all stop our progress, and make a public retrospective to share and challenge our various approaches. The occasion also for the chair to give us more hints about this kata that he usually has made before (few times, in other contexts).

Regarding the logistic, almost everyone brings his personal laptop. But since we usually pair, even those that didn't have a laptop may code. Depending on the kata also, everyone is picking the language of his choice to work it out (Java, C#, Javascript, F#, Scala, Clojure, Haskell, ...). 

Firstly introduced by my friend and eXtreme Programmer Philippe BOURGAU, Cyrille MARTRAIRE and Gilles PHILIPPART were truly the ones that institutionalized the coding dojos then, as a regular event. Indeed, even if this summer was pretty quiet, last spring there were almost one coding dojo per week (usually nicely chaired by Eric LE MERDY). But I must admit that I miss the fun, creative and very informative sessions chaired by Jean-Laurent DE MORLHON (working elsewhere now). A true mindset inspiration for me, when I organized some of them afterwards.

By the way, here is a hint for you if you want to launch this kind of events within your working environment: don't hesitate to find an incentive to break the ice and make new developers joining the movement.

The chicken and the egg situation

Indeed, someone that never attended a coding dojo will be often reluctant to join one, but those that have tasted a coding dojo once, will usually be recurrent attendees.

That's a fact, a coding dojo may firstly appear impressive if you never attend it before. Will I be able to pair with guys I don't know yet? Will I be able to code as fast as the other attendees? ... are common questions silently un-asked. But once you've attended a first session, the result is always the same: we all realized that it is not only easy, but truly fun! (and BTW, kata aren't about complex algorithms, nor about any given tech stack that you wouldn't know)

To reach some .NET developers that were not used to contribute to such events (and probably a little bit shy or anxious, since they had lots of excuses to refuse again and again), my solution had been to make a deal with our purchase department and Microsoft, and to offer temporary MSDN account activations (i.e.  the ability to download a tons of MS product for free) to every developer that will attend their first coding dojo.

Whether you are contractor or internal employee, you will be able to install Visual Studio on your personal laptop, but only if you attend a coding dojo first. Here, I have to thanks again our purchase division mates, and our contact in MS for that. Because with that thing... No more chicken and egg problem for dojo attendance.

I won't detail much more on coding dojos, there already are lot of literature on that area, but simply give you some of my favorites: Gilded Rose (legacy code refactoring), The ("office") code carpaccio (my personal adaptation of the code carpaccio kata. i.e. how to slice your work in order to add business value on every 8 minutes iterations), Mars Rover (perfect for TDD design), the Cash Register (how to avoid being blocked by fragile tests when business requirements are changing blazing fast), etc.

Hackathons

Organized by our company, and hosted by Ecole42,  this hackfest has mobilized lots of developers during an entire WE (too bad that wasn’t during the week), around the theme: "create new kind of collaboration tools for distributed dev teams". A nice initiative that will surely be reproduced in the future.

Some other ideas we started to launch recently

"Hack da cafeteria"

During a recent discussion with Bernard NOTARIANNI (co-founder of the Paris #XProPa), we had an idea for a new kind of lunch-event.

Indeed, while I was explaining my proposal of organizing dinners in Paris for XP practitioners: wine, food and craftsmen (explanations here in French), he stopped me and said: "nice idea! but why don't we start here, within this company, by hacking the cafeteria at noon for debating around development topics?", "That's right! Why don't we?" ...  The concept of the Hack da cafeteria event was born.

This concept is pretty simple: we join the cafeteria with a topic to debate and to share about with other real practitioners (e.g. "How to convince skeptical dev and project managers to allow pair programming?", "Mob programming, how does it work for you?", "CQRS & event sourcing in action with concrete cases", "How DDD practices helped us within our projects", etc).

We split ourselves into tables of 6 to lunch and debate the topic of the day. After a 1 hour of lunch-debate, every tables merge for the coffee in order to share with the others tables their 2 or 3 highlights.

At the end of the day, a short minutes may be forwarded to anyone interested by this topic (especially the people that are not practitioner already, or located at the other side of the globe ;-)

The very first session is already scheduled and will occur early September. I'll surely post something about it after.

All those events are easily affordable, and are perfect occasions to break silos and to connect people from different cultures, teams and habits.

"Mate, you have to see this!"

Is another stuff to do at lunch-time. Something I would have liked to organize since a long time, but that I will actually schedule in 2 or 3 weeks from now (I've made my poll, and it seems that there is appetite on this too ;-)

The idea: to display somewhere at noon, the video of a talk, conference, quickie, ... that strongly impacted one of us, and that we wanted to share with peers. Not only to share its content by the way, but also to debate all together on it afterwards.

You don't have time to do some market watch? Let yourself leverage on other mates' best discoveries! Simple, easy, and the opportunity to open some technical debates, even if you can't attend some meetup evening events in Paris (what I call my geek evenings).

I've read pretty much the same concept within Sandro's book with tons of tips for the logistic when we don't have access to the ideal rooms/theaters (even if I'll try to borrow our official theater at work, if this initiative is having success). And we already have lots of videos (and debates) in mind for the first representations...

And last but not least, I'm proud to introduce you

The Lunch-box mob

How would we properly implement event sourcing to add more business value and audit trail capabilities to an Order Management System (OMS)? Will we be able to leverage on the LMAX Disruptor without being forced to reimplement all the associated LMAX stacks in .NET? (i.e. ressources pooling, cache-friendly collections, etc) How would we implement a Smart Order Routing system (SOR) with relevant low latency and throughput performances, but without scarifying code readability & maintainability for non-experts? Which programming paradigm to choose for this kind of reactive system: LMAX disruptor-based? In-house Sequencer-based? RX? F#? 

... were some of the questions that led Tomasz JASKULA (DDD and F# Paris co-founder) and I to pair together at noon with our laptops in order to spike and build stuffs (yeah: enough said! time to code ;-)

That why we created the Lunch-Box github organization, and started to work on an open source Simple Order Routing (a kind of Smart Order Routing financial system, but without the smart algorithm part). The #SORLunchBox project was born! (see details on the project's wiki)

We've been since joined by some mates that have both the SOR functional knowledge and the envy to collaborate. Again:  our Mob programming crew was born! (with 4 people for 1 keyboard and a big screen).

This is the very beginning, but since we are not working on the same teams, we decided to meet at least 2x2hours a week -at noon- to work on it. We split our project into various journeys, and will probably keep a logbooks to diffuse what we will discover, next to our code which is open sourced.

This kind of experimentation has lots of benefits. It has already learned us various things (functional, mob programming organization, etc.) and bring lots of fun too! And who knows : maybe this spike open source project will help other teams, but also help ourselves (through the feedback of people elsewhere).

Experiment, talk, learn, debate, build, and share

What i'm saying, as a conclusion, is that you always have lots of benefits to experiment, talk, learn, debate, build, and share. Yes, sharing your passion, your failures, your discoveries is good, and helpful. For you, and the others.

Most of the events and occasions I talked about in that post are free and very easy to organize. Don't wait that your company or structure help you to start. Also, don't expect to have lots of people with you to start doing things. Start with 2 people, communicate on it, have fun... and let the other join the initiative.

Be the spark that will ignite the fire of Software Craftsmanship within your organization! 

The pragmatic architect

is obviously use-case-driven

A pragmatic architect is someone that gathers use cases and constraints before thinking solution.

Even more, a pragmatic architect cares about the 'why are we doing this?' (i.e. the underlying business goal, that is too often not clearly explicited and shared). He reviews and confronts any option or action with this initial business objective. He tries to deliver projects that will have impact, not only to ship software.

A pragmatic architect does not confuse architecture with tools and frameworks. He also likes architectures to scream their intentions.

knows there is no such thing as 'absolute truth or architecture'

A pragmatic architect knows that there is no absolute truth or solution. She understands that every choice or trade-off is depending on a context (including human considerations).

A pragmatic architect experiences what she recommends to the others. She stands by her choices with the rest of the team or stakeholders.

A pragmatic architect fosters situations where people can live without her. She tries to setup systems that make people fall into the pit of success.

is also a pragmatic programmer

A pragmatic architect is also a pragmatic programmer and a software craftsman. He really enjoys coding and to improve himself at it. If he could not code during working hours (i.e. the slides and diagrams kingdom), he may contribute to open source projects at home.

As every pragmatic programmer, he likes to script and automate every recurrent and painful things as much as possible. He is obviously a big fan of Continuous Delivery.

A pragmatic architect also understands that Continuous Build is not Continuous Integration.

A pragmatic architect is not only talking about Test Driven Development to every reluctant mate, he tries to show the benefits of TDD as often as possible during concrete pair programming sessions.

A pragmatic architect knows the 9 indispensable rules of debugging, and is always willing to remind them to anyone that may need it. A pragmatic architect is also an ego-less programmer.

A pragmatic architect is capable to discuss the strengths and weakness of Object Oriented Programming or Functional Programming to other mates. He likes to step aside and get perspectives on things, and fundamentally needs to understand the reasons of every choices.

A pragmatic architect knows about patterns and anti-patterns, he values GRASP, GOF and POSA patterns, but also cares about the Capacity and Stability ones. As every software craftsman, he also embraces the SOLID principles. But more than anything else, he likes that things stay as simple as possible.

A pragmatic architect likes abstractions, but is aware of the law of leaky abstractions. He also knows that "the pitfall of dogmatism is inherent in any effort of abstraction".

A pragmatic architect has lots of ideas, but he likes nothing more than to share and to debate them with others. But mostly to confront his ideas with the real world. Also, a pragmatic architect does not fear to try. He knows that failure is mother of success. And he usually does not put all his eggs in one basket.

A pragmatic architect does not fear risks, he rather mitigates them.

cares to understand the business stakes.

A pragmatic architect is curious, this is one of the reasons why she chosen this job. And even if she's an hardcore technical addict, a pragmatic architect is someone that cares to understand the business stakes.

A pragmatic architect always prioritizes the work according to the value it brings to the project. This is why she usually defers decisions about the choice of frameworks or tools to be used (db for instance)..

A pragmatic architect always asks 'Why?' five times, so that she can find out the real root causes, intentions, or needs behind her interlocutors words.

A pragmatic architect likes to explicit every kind of implicit. She makes everyone to be on the same page. She's even able to ask naive and silly questions she already knew the answer, just for shy people in the room to heard it. She usually ask people to re-phrase things in order to check they have understood what was said.

A pragmatic architect has not only a vision for the project or the IS, but she cares to share it with ALL the stakeholders involved.

A pragmatic architect is an enthusiastic team player. She really enjoys to collaborate with people and teams.

A pragmatic architect understands that Behavior Driven Design (BDD) is not a matter of tools, but a matter of collaboration and communication among various actors (Biz/BA, ops, QA & DEV).

A pragmatic architect is agile, but doesn't feel the need to repeat it to everyone. She is now more concerned about how to scale agility within the organizations, and how to improve current practices.

A pragmatic architect is as capable of putting project's primary focus on the core domain with Domain Driven Design (DDD), that understanding the technical challenges of all technical stacks. She is multilingual (biz, managers, dev, ops,...).

A pragmatic architect understands that we should stop trying to model the real-world, but only what matter to our software usages instead.

A pragmatic architect understands that event sourcing is not only a technique for technical challenges like High Availability, but something that may bring real business added values.

does not guess, he measures.

A pragmatic architect doesn't like early optimizations. A pragmatic architect does not guess, he measures instead.

A pragmatic architect has both network and hardware skills. He knows not only HTTP, but he masters IP, TCP, UDP... He also tries to avoid having too many war stories, by learning from others' experiences. He also knows how multicast is working under the hood, and other stuffs like it's possible to do unicast with UDP, what is false sharing, what every programmer should know about memory,  etc. A pragmatic architect is able to understand the impacts of route flapping and network routing convergence on the systems we build. He is a real interlocutor for infrastructure guys and network engineers. He can do that because he is dramatically curious, and always willing to discover new things when he heard about it.

A pragmatic architect is a multi-threading expert, and this is why he tries to help people not to play with threads. A pragmatic architect also likes to spot the deadlocks at home, but hates to do that in production.

A pragmatic architect knows about Recovery Oriented Computing (ROC) and builds production ready systems. He tries to minimize the impacts of bugs on the system when they happen, rather than trusting the idea of a world without bug (ha, ha, ha ;-). Thus, he cares to setup some 'what if ...' workshop sessions before going under production, and to deal with exceptions at system integration points within the system he builds.

A pragmatic architect also knows and cares about mechanical sympathy. He also knows -thanks to the CAP theorem- that you can't have your cake (HA) and eat it (Utter Consistency) too! 

A pragmatic architect is still wary of benchmarks. He knows that almost all of them are done under conditions that have no relationship with what's interesting in the real-world.

A pragmatic architect remembers Schrödinger's cat when he profiles systems (and is also wary of heisenbugs).

likes 'easy in, easy out' technologies 

A pragmatic architect hates golden hammers. She constantly tries to avoid having her own ones.

A pragmatic architect likes 'easy in, easy out' technologies. That's kind of logical, cause she naturally does not like strong dependencies and coupling. And this is why she often promotes the hexagonal architecture.

A pragmatic architect is usually wary of frameworks and rather uses libraries. She tries to know when and where the abstractions will leak.

A pragmatic architect has more to propose than layers architecture only. When she proposes a layers architecture, she intentionally knows why, and is able to explain it to her mates.

A pragmatic architect knows various technologies such as LDAP, NTP, RDBMS, NoSQL, etc. She's really curious, and always willing to discover new things or paradigms.

Of course, a pragmatic architect likes, but also animates Brown Bag Lunches!

reads tons of books, but doesn't blindly apply things 'by the book'

A pragmatic architect is open-minded, and curious. He likes to break silos, and thus enjoys reading things on various other disciplines (not only IT).

A pragmatic architect enjoys to step back and raises his head; he's usually good for the job thanks to his systemic mindset.

A pragmatic architect reads tons of books, but he does not apply things 'by the book'.

A pragmatic architect attends to various IT conferences or 'geek' meetups. He's very social, and always willing to share what he has learned to the mates that couldn't attend those events. He then  spreads the words via twitter, blogs, mails, presentations, coffee breaks, etc.

A pragmatic architect may use acronyms (when he's tired ;-) ; but is always willing to explain their meaning when he sees question tags in the eyes of his interlocutors. He cares about how people receive and understand his words and messages. Thus, he's able to use tricks to re-focus his interlocutors on the core objectives when they diverge.

I already told you, but a pragmatic architect likes simplicity.

A pragmatic architect is aware of the power of humor to communicate with others (except within this current post ;-P

has no IT religion

A pragmatic architect has no IT religion and is not dogmatic. He doesn't care stupid debates like java vs. NET, etc. He's able to think out of the box, and adapts to contexts and people that will implement the systems.

A pragmatic architect cares about others point of views.

A pragmatic architect is able to convince others with a crystal-clear speech. 

But above all, a Pragmatic architect is able to adapt his positions and to challenge himself. 

Last update: November 16th 2013

The 10 commandments of Egoless Programming

Thanks to my friend dupdob, I've just read the excellent post on kitchensoap's blog: on being a senior engineer.

This must-read-post includes the excellent 10 commandments of Egoless Programming, apparently found on @wyattdanger's blog post (on receiving advice from his dad). Simply Awesome...

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.
9. Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.
10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

wiked! the solution to DRY all our projects KM

Since my latest post: It's really time to DRY our apps' Knowledge Management! I had the occasion to share this topic with several mates, and thus to discover that the maven site plugin was perfectly fine for what I intended to do (thanks to Christophe LALLEMENT & Alexandre NAVARRO by the way).

Thus, no need to reinvent the wheel for that (which is perfect fine for me).

So I started to play with maven (quite new for the .NET expert I am), and especially with the maven site plugin ecosystem. At the end, it took me several hours in order to fully understand how to use it properly. With some questions like:

• Which maven plugins (and versions) should I configure within the pom.xml I intend to use in order to generate the web site for my project (which is not a java project by the way)?
• Which minimal pom.xml could I set in order to generate a web site with the mvn site command-line (important for non-java project, and to KISS)
• Where should I put images and other resources in order to be able to reference them properly from my markdown pages
• Why and when should I have to call `mvn clean` before the `mvn site` command-line in some rare cases (like when changing the project name whithin the pom.xml file)
• How to set a better look n feel to the overall generated web site?
• Which markdown syntax was working, and which one was not well supported by the tools (i.e. the atx-style headers)?
• etc.

I finally intended to package something that would help me (and others) to quickly setup such web site generation solution for every new project Knowledge Management.

Thus, i'm proud to present you the wiked! solution,  now available on gitHub.

More than a simple bootstrapper that will ease you to earn some time when setup-ing such a solution for your project, wiked! also offers you a structure and some content for all your projects web sites (see the values and practices section for instance).

And since the DRY principle was one of my driver, I won't fully describe here what wiked! is all about. If you are interested, you can have a look at the wiked! ReadME.md

Hope this help.

It's really time to DRY our apps' Knowledge Management!

While I was reading the amazing Pragmatic Programmer manifesto, several years ago from now, I really enjoyed the "Keep Knowledge in Plain Text" principle (tip 20).

Unfortunately, I never really took the time to apply this principle seriously for the Knowledge Management (KM) of the various projects on which I worked. Every time, I lazily put all the team/application related informations whether in a wiki, or as MS Office documents stored on a Sharepoint... (sad panda ;-)


Last time, while I was having a lunch with a colleague of mine (a well-known and passionate french craftsman), I realized how lazy I was so far regarding this KM topic. With 2 or 3 words only (read-only wiki, Markdown documentation, SCM), Cyrille starry-eyed the dormant craftsman in me.

Indeed, since:

• wiki web sites for DEV teams usually finishes badly (e.g.: lots of different wikis/sections for the same component/teams, no proper knowledge of what is still relevant and what is deprecated, structure mess, etc)
• documentation created separately from code or components is less likely to be correct and up to date
• it’s not easy to compare/diff MS Office documents
• it’s important for every piece of knowledge to have a single, unambiguous, authoritative representation within a system (DRY principle)
• the text documentation has becoming more important than ever since the advent of the blue book (to express the ubiquitous language of our projects, to clarify some large-scale design intents, etc)

It would be a good idea for us to find a way to get rid of traditional team wiki site, and instead to write every documentation in:

• text files written in Markdown format (we may benefit from any Markdown existing tool/editors)
• stored within the SCM of our project (e.g.: SVN, git)
• and to make our Software Factory (re)generate a static web site (like a read-only wiki) every time we changed those Markdown text files from within our SCM. 

As benefits, our team/application documentation will:

• always be up-to-date and versioned
• easily diff-able (text files with Markdown format)
• respect the dry principle (with our SCM as its golden source)
• easily browsable by everyone in a readonly but readable wiki-like web site (DEV, QA, Support teams, …)
• easily modifiable by team members in a well know and official location (as easy as creating/modifying a text file in a SCM)

Of course, the idea here would be not to reinvent the wheel, but to reuse any existing Markdown renderer & static web site generators instead (the step beyond the github Readme.md file). But if I can’t find something and make it out quickly, I would probably initiate an open source project to implement such system.

Cyrille was right: it's probably time for us now to kill wikis! and to reinvent them.

Last but not least: a very interesting post of Cyrille about Collaborative Artifacts as Code.



BREAKING NEWS: I found a solution for my use cases, described here.

My personal motto for software development

Here are my four commandments for software development. Nothing is really new, but these are the basis criteria I try to follow each time I code a class :

1. Make it testable
2. Make it simple
3. Make it readable
4. Make it cohesive

Make it testable: because the test act like a specification and helps us to focus on design before writing our implementation code (cf Test Driven Development).

Make it simple: because complexity has several costs (difficulties to enter the code for every newcomer, painful sessions of debugage, bigger slowness for modification, ... ).

Make it readable: because source code must be human-readable (whereas binaries must be computer-executable), and because we usually do not work alone !
The choice of our method/variable names, the adoption of common naming and coding guidelines, and the quality of our source code comments (which must expose our intentions) is crucial.

Make it cohesive: because cohesion (the measure of how strongly-related and focused the responsibilities of a single class are) brings reliability, reusability, and understandability. It is essential to be capable of formalizing the responsibilities of a class in order to ensure its cohesion (I usually ask my teammates to make their best in order to write a precise and clear "summary comment" at the top of each one ot them). Highly cohesive classes are also usually easy to test (cf. Make it testable).


Like the Test-Driven Development motto (Red, Green, Refactor), I think this kind of reminder may be useful in our daily work.

Long, low-energy stand up meetings tend to distract and mute the day

Martin Fowler has recently post a nice paper about patterns of daily Stand-up meetings (It's Not Just Standing Up).

I completely agree with him when he says that sharing commitment is one of the stand-up meeting success keys.

"Making daily commitments to each other as a team is the most important goal of daily stand-ups. Sharing commitment is more important than sharing progress or status. This is not to say that an observer will not have a sense of progress and status from the stand-up, but this is secondary to team members publicly committing to each other, and identifying obstacles that prevent them from meeting their commitments."

Obviously, when this commitment objective is not targeted, this may lead to situations like:

"Team members are facing and talking to the manager or meeting facilitator instead of to the team. This indicates that the daily stand-up is for the manager/facilitator when it is actually supposed to be for the team. "

To avoid the skids and to fully benefit from this kind of meeting, it is useful to keep in mind the three points that every participant must quickly address:

• What did I accomplish yesterday?
• What will I do today?
• What obstacles are impeding my progress