Everything else

So I am drunk, this is a post that fits in those posts on the everything else part of the blog, I advise you to stop reading here, as per I am drunk. I just came back from my meeting with my sister, she makes me feel happy and proud.

She is so much more than me and she has a very beautiful family, she has done an wonderful job at raising hers daughter and I hope I get to be half as competent as her in raising my son.

She and my brother-in-law loves beer and we went to an nice place: emporio do alto do pinheiros <- you see, my markdown powers are not diminished by alcohol, long live Aaron Swartz legacy on many things that matters.

The place in question sells beer from around the world. Long live British beer! You guys are invaders and meddlers but you are redeemed by your beer. Americans not so much, you are even more meddlesome so you must work harder on your beer, you have much to improve, you have to acquire elven standards on beer to compensate for the amount you meddle in peoples internet and general affairs.

Bottom line, as much as someone in my condition can reach a bottom line without being the bottle one. Aliteration…

British beer is the best, closely followed by Belgium, for a nice surprise Norwegian was very good too, American not so much, don't do drugs, do not drink Brazilian's we are not as half as meddlers as anyone and yet our beer needs improving.

Also I am happy, very happy! Me, my wife and my kiddo are moving in to Montreal, which seems to be a fine place to raise him, I am on my last days on the drone factory that has become my job and the future seem brighter and sunnier although in a snowier place.

I also have to thank Bob Marshall for his post on rip agile. It was eye opener, I realised I don't want agile back, it is a bad brand, seriously people, who came out with this name? It is bad, it does not capture more than buzzword, it was bound to become something corporate zombies label horny would abuse.

I want to be treated as a human being, I want an Organic, Mindful, Soulful software development. Hint: Corny labels do not get abused by corporate drones.

I want the essence back, the dead empty shell the drones can have and feed on it.

Tomorrow I will regret this post, but the me from today vow not to let the me from tomorrow to take this down.

Peace out people, be happy.

The Fear of Agile Transformation

Excellent article, fear of change and lack of willingness to try out new things and risking failure is the single greatest enemy of agile adoption and success in most endeavours.

All Things Agile

“The snake which cannot shed its’ skin has to die.  As well as the minds which are prevented from changing their opinions; they cease to be mind.”  Friedrich Nietzsche

Recently, I was attending a Deep-Dive study group that was hosted by Lyssa Crispin and Michael Spayd of the Agile Coaching Institute.  During our discussions, I began to think about all of the agile transformation efforts I had participated on and what, in my opinion, seemed to be one of the deterrents to a successful agile transformation.

What I determined was that a good percentage of people that resisted the change to agile came from a very strong command-and-control background—individuals that were managers, at all levels, who were accustomed to being in charge and commanding people to do things, sometimes down to the task level.  Not all of these people were project managers, some were senior technical leads who had reached…

View original post 925 more words

The noble pursuit of ignorance

We’ve got our brains hooked up in cyberware(sort of), we have more data at our fingertips than any of our ancestors ever dreamed or dreamt of.

The big word of the moment is Bigdata, or how to search all this information. Maiden’s Prisoner starts playing in the background.

While through machine learning and pattern matching we make mechanical constructs try to emulate the most sophisticated pattern matcher of all, we deface and mechanize human beings turning them into machines unable to make inquires and search for answers.

Just numbers, prisoners to the mentality of the colonial and industrial age. Repeating the same “right answers”, learning nothing useful and being used like poor man’s hard driver in an gigantic cluster of replicated data, pieces to a dead machine. Unable to claim our rightful ignorance.

Not numbers, free-humans, let’s have minds of our own. Let’s start to convert all this data in wisdom and search for our high quality ignorance.

Wired to pair

The more I think of the practices the more I like pair programming, it is the one practice with a plethora of benefits from code review without attrition to source of social interaction, enforcement of good practices and code style, diffusion of information among team members, activation of learning part of the brain associated with social interaction…

I just came across an article that I again see relation to pair programming, we are wired to handle better stressful situations by sharing the burden as it is shown in this article.

I think it was twitted but for the life of me I can’t find the original reference, this was sitting on my bazillion of tabs to be read for some time.

Fun and Agile

Preamble

I figure that if we are to take agile back we should not let pass remarks that destroy the spirit of agile and we must reinforce what agile stands for.

So this is a kind of extended off-topic reply to a discussion in the linked in group about agile where I felt that a core tenet of agile was offended.

This is of course, my opinions on the subject, both on how to handle take agile back as on the subject at hand.

The issue

In the discussion about how to teach agile there were some people suggesting the use of games, in response it was stated by someone that:

  1. Agile is not fun;

  2. Agile is not a escape for the lazy or ones that don’t want to work hard to learn and upgrade their skills;

  3. Agile causes burnout;

  4. No pain, no gain.

The affirmation (2), I think is the worst off all, because it shows that you mistrust people by default. It is carrots and sticks all over it, it’s a gross misunderstanding on human motivation and that humans strive for mastery and achievement and it is precisely this distrustful culture that puts people on the defensive and utterly creates an environment of underachievement motivated by fear and conflict.

Human centred

A central characteristics of Agile, at least which I see as being core to Agile, is being Human centred and organic, contrary to more traditional methodologies that try to force human beings into forms, agile tries to understand humans and build around them in order to maximise the positive qualities and to smooth out defects.

Instead of destroying human beings by trying to make them into machine pieces and fit an arbitrary median norm, ending up with barely functional pieces, performing at the average minimum, Agile builds upon people and maximises contribution of each participant in the process, leveraging each individual’s qualities and protecting the whole from defects.

In order to archive that goal it is necessary to understand the human being which can only be done by understanding of human physiology, psychology and sociology. As with agile we are always in the feedback loop learning and improving, a good amount of empathy.

No carrots please

The first thing to understand is that we are not motivated by rewards.

It is an established knowledge that intrinsic motivation is much better than extrinsic motivation, there are experiments that show that if a person likes something and is paid to do it, she will like it less afterwards, for we associate the act of doing with the reward being the cause and not an intrinsic motive and the subject becomes less interesting.

Fear is the path to the dark side

When we are in fear or stressed, the reptilian brain takes over and shuts down the creative problem solving part of the brain, we enter a fight or run mode where route response and pre-programmed behaviour takes place.

Software development is intellectual work

This is an important point to realise, the least important part of programming is the actual writing of code, for that we have IDEs, where development bogs down is the design part when people are at lost on how to solve a problem, how to uncover a bug, or even worse when they are producing badly designed code that will “work” but later come back and haunt the team.

Intellectual work is very different from mechanical work for you don’t just drop it at the end of the day and restart the following day, where measurement of a task progress is merely the amount of stuff produced.

In intellectual work the task is ongoing 24 hours a day, our brain does not simply switch off from the task, it keeps processing unconsciously the problems and the creative process goes on and on.

The reason people have so many great ideas in the bath, when we bathe we are relaxed, running hot water is specially good at releasing hormones that causes relaxation, this engages the creative part of the brain, the pre-frontal cortex, ideas get finished and flow from the unconscious mind.

To maximise intellectual productivity one must keep the pre-frontal cortex engaged, this means being relaxed and avoiding extended period of stress.

Work around limitations

While command and control industrial age philosophies try to enforce policies and force people to follow an huge amount rules, Agile tries to remove the burden and set tools and mechanisms which would be the least intrusive, stressful or demanding, to let people do what they really excel at which is to think, have ideas, solve problems.

For example instead of using late code review which causes people to feel uncomfortable and judged, Agile uses pair programming which incorporates hot code review among other things. Instead of e-mail, planing tools, reports… A simple white board with histories.

The more you make people feel safe, comfortable, empowered, reduce bureaucracy noise, the more they will focus on actually working and produce stuff. If the process takes unto itself the role of compensating for the weakness, people can focus theirs energy on what actually matters.

To tire is an human weakness and thus it must be addressed by the methodology, if it is allowing people to burnout it is being done wrong. In fact there is a maxim for that: Work refreshed.

We advance when we rest

Affirmation (4) no pain no gain, is a often repeated catch phrase, when we workout we cause lesion to tissue but when we rest, during the deep sleep, tissue is repaired and the body “learns” by forming better structures, the same goes for mental learning, during light sleep our brain organise information and commit to long term memory.

We know today when we exercise up until just before the pain, recovery is much faster and gain over time is greater than going past to pain, besides, exercising until pain there is formation of micro scars, which over time cripple the tissue. The same goes for mental health, if you rest before stress you recover faster, learn more and prevent mental injury.

The correct phrase would be: No rest, no gain, pain and eventually death.

We evolved to play

Play is a fundamental need for human beings. We evolved to play, it is the natural way for our species and many others to learn, when we play we are at the proper mental state for learning. There is a beautiful TED Talk by Steve Keil on the subject in which he does an excellent job at advocating for play and fun to boost work.

By promoting play and games you promote the development of skills without suffering, boredom and stress.

Fun is serious business

How do you maximise brain work in an unobtrusive way? Fun of course. If you reconcile fun with work you will have more brain power and less burnout. Actually, in order to be Agile, there must be fun.

The Human Connection

Born to share

From the moment we are born to the moment we die we are wired to connect and share everything we do. It is our connections that give meaning to our lives and they shape how we think and what we are. Even before we are born we start learning language, we learn the sounds of the language and the accent of our parents.

We come out and we are sponges for language, babies keep on running those learning algorithms making out which sound are each phoneme in a given language, as we are told in this TED Talk of Dr. Patricia Kuhl.

Babies exposed to language in the first year learn at amazing pace the sounds of the language, but the most striking is that in two weeks a baby not previously exposed to a language catches up, if a person comes to talk to him in a new language, and here is something very intriguing: it must be a person, not a television, not a radio, there must be firing of social neurons in order for the learning to occur.

But this is not the only learning that is shaped by our social interactions as we can see in another inspiring talk, this time by Professor Sugata Mitra who stumbled upon a great discovery with his experiment Hole in the Wall where he leaves a computer exposed to the street and finds out that the poor children, who had no previous contact with computers and without external assistance, are able to teach themselves all sorts of things. He explores this idea further and reports again in his next talk in his finding he observes that there must be more than one child, they must interact, even at first being wrong and advising one another wrongly, they end up building knowledge.

The birth place of ideas

But the benefit of human interaction for learning does not end in adolescence, we carry on “sinergizing” with others to produce and create as Steven Johnson explores on his Where good ideas comes from, we are nodes in a great human network load balancing ideas and knowledge and the interactions that allow the ideas to make sex are the real geniuses of the human race.

Programming is comunicating

Enter programming, one can argue that human languages are messy and ambiguous, on the other hand computer languages are clear and precise, besides you just need to make the computer understand what is said. It is easier than with humans. Right?

Computer languages are just like human languages, there are many ways to achieve the same result in a given language, more in some than in others(Perl comes to mind), specially on those with a high level of abstraction. The abundance of bugs on every program just shows how hard is to really get the message through the computer thick mind.

Having the computer to understand your meaning is just half the story, for there is maintenance, making the computer understand is never enough, unless you produce throw away software, you have to write code in an way that the non-native speakers, us humans, understand clearly the concepts intended for the computers.

On top of that, those concepts are not just something you knew all along. They are new ideas to solve the problems of the system being written, the act of writing computer programs is not just a passive activity of writing down something well known. It is a creative, engaging, challenging processes of creating new knowledge and writing it to be understood by two completely different beings.

The connection solution

Thus we have in programming the full stack, from learning what is needed to be done, how to do it and pass the knowledge around. Programing does benefit fully from keeping our social neurons firing and interacting at which pair programing excels. It provides the needed social context for the act of programing to keep our brains going, working full steam.

Programing is not the mechanic act of typing code, for that we have IDEs, what slows down to a stop development is the lack of ideas, even worse: bad ideas that creep in and if left in the system cause all kinds of misunderstandings(A.K.A.:bugs) and troubles like the time taken to understand a piece of code to fix it that will accumulate cost along a project.

Pair programing, by satisfying our social cravings, as seeing in the prevalence of social networks, reduce time spent on them, for that need is supplied in the act of programing itself. Through positive peer pressure it keeps the quality of code high for no one likes to show bad coding style. It homogenizes knowledge among the team both from the application inner works as with technical knowledge and knowledge in general.

It also builds bounds among the team and sthrengtens confidence which make people work more motivated.

Conclusion

Pair programing makes the endeavor of programing more humane, rises the quality of the software produced and generates knowledge. It is a very powerfull tool that works in tandem with agile values and is too valuable to not be applied even outside agile environment.

Join Take Back Agile

Taking Agile Back

Recently with his post I Want Agile Back Tim Ottinger launched a movement of rescuing the agile movement and it’s values. I heartily agree with him that the state of agile is disheartening this days. Agile has being kidnapped by the very machine that it rose to stand against.

Agile is not fast

Agile does not mean fast, half-backed, ill thought of code. Agile means being able and ready to react soon to changes in the environment so that you do not spend time and energy producing something that has not value. The very idea birthing from the wish to produce quality.

Agile is human first

Agile is about recognizing that software is an human process and understanding and valuing humans in the process instead of hammering them down to bits into the process.

Agile is being honest

Even if it let income go, it is to be transparent and let the customer let the project go if it is not giving him value anymore. It is not about squeezing profit at the expense of everything else.

Agile is not about titles

Agile is not about being master, manager, boss, über developer, or any title of power or lack of it. It is about the power of collaboration with everyone being equally important to the success of the enterprise and contributing to the mix of skills without adding one more pretty initials to the business card.

Agile is about satisfaction

Satisfaction in working with others and having the feeling of the job well done. Satisfaction of the craftsman over a piece produced with mastery. Satisfaction of seeing the customer happy with value added through the software.

Join

If you believed the agile manifest and want to see a world where software is written thusly, join the movement to take agile back:
– Google plus community
– Google groups
– Twitter@TakeBackAgile

— may the code be with you

On Mastering Programming

After having written a long reply to the linkedin group on the subject: ‘What does the term, “Master Programmer”, evoke in you?’ and loosing it due to non-masterful use of a simple tool, the web browser, I decided that it was an interesting enough subject to start again but to blog it.

The Michael Fuhrman suggested that a master programmer would have a set of attributes that would characterize him as being a master programmer, those attributes being:

  • Technically Articulate
  • Teaching
  • Creative, Inspirational and Motivational
  • Decision Making Process
  • Problem Understanding
  • Skills Problem Solving
  • Skills Systems Analysis
  • Project Management
  • Team Building Skills
  • Enterprise Coding Standards
  • Scalable Application Design
  • Object Oriented Programming
  • FrameWorks
  • Design Guides
  • Pair
  • Coding Unit Testing

I agree with this list of skills with the exclusion of the Object Oriented Programming, despite the fact I am a Object Oriented bigot, I recognize that using object oriented paradigm is not mandatory and there are great programmers around that adhere to different paradigms.

There was an argument about mastery being a title given by others establishing a relation of teacher and student. But the meaning of the word as defined in the dictionary, or the modern dictionary at least, the all knowing Google:

mas-ter-y
ˈmast(ə)rē/
noun: mastery
1. comprehensive knowledge or skill in a subject oraccomplishment.

The idea of a master being a teacher, I think, comes from the guild system were an apprentice would have to find a master craftsman to teach him the craft and he would eventually become a journeyman and then, maybe, a master himself.

But this very system required that the person aspiring to mastership would earn a certain minimum sum of money, thus proving the exercise of the craft, and the production of a masterpiece to be judged by the guild masters. Thus, even then, the mastery was something that is acquired by achievement of skill and not a relation to a student.

Although the right to have student was reserved to a
master, and this makes sense since you have to really know something to teach it.

So we move to a more interesting objection: the impossibility of mastery in programing due to the fact that programing is an ever changing field and that is
impossible to really learn it, there was even an assertion that on other fields it is assumed that it takes 10 years, probably the 10k hours of practice rule, to become a master, but in programming a person with 10 years of experience would become obsolete and even a liability.

In my opinion, there is a fundamental error here, the assumption that a master programmer is someone that have mastered a single language or technology. This
is, after all, an ever changing field, so the ability to cope with change must be something included in the skill set of a master programmer, in fact “hackers”
are respected in the basis of theirs ability to hack and learn, that is to cut something into pieces and understand it.

Indeed, something you see in great programmers is not only great knowledge but willingness and skill in searching for even more knowledge. In truth, you can see it in any master of any field, not in fake masters but in those capable of holding people in awe, they are humble and they recognize there is always something new to learn and any source of knowledge is valid.

That is why masters learn from theirs students, they keep an open and watchful mind. A long time ago someone in Sun Java forums cited a research that showed
that humble people always out perform arrogant people, the theory is that the humble is always trying to improve while the arrogant knowing little thinks he knows it all and so he stops learning.

Besides, anyone that has lived the evolution Java in the web, for example, the rise of Servlets and how they were unruly to produce the view side, the creation of the JSP to facilitate the writing of pages, the subsequent troubles with business code embedded in them, then the emergence of the pattern using Servlets to execute logic and then dispatch to simpler JSPs to render the result, and
then Struts to handle the tedious boilerplate code of parsing request values and creating an indirection level to navigation has a much better grasp and
understanding of why we have all the buzzwords of today, what are the problems related to not following certain practices and the advantages of doing than someone just jumping in the fray.

The same goes to about anything in the field, someone that has experienced many languages and have written code in assembler, basic, C, COBOL, etc. has a better sense of what is good, what is bad, what works what becomes spaghetti than someone that is just learning programming now and thinks that Ruby is much better than Java because a hello word in it is shorter.

Some things in the field are ever changing, but those things are only the crust, languages are mostly syntax sugar, and like learning human languages once you
start learning new languages, each language becomes easier and you start to see the correlation among them.

Some other things are much more permanent, research skill, design patterns and other patterns in general, logic, inter-personal skills, problem solving,
abstraction, communication, etc. Those things carry from one language or technology to another and a person that has applied this skills for 10k hours and have them ingrained will write better code no matter the language, will be able to notice struggle in a novice and be able to help him because he understands people better and understands the problem and the nature of the struggle better.

This person will have a better gut feeling about code smells and will have a seemingly preternatural skill to debug, will have a larger palette of tools to
solve a problem, will be better able and have a more comprehensive vocabulary to communicate a problem and a solution.

And most important of all in programming, this person will be better equipped to research, will be more effective in formulating the right questions to solve a problem at hand. Will know how better google for, read documentation, hack the code.

As masters of others fields a master programmer will be able to draw knowledge from other fields to programming for his understanding of the subject is such that he is able to see the essence of the things, much like Musashi has said in Go Rin No Sho, just like a master tennis player will find relation in how you swing a racket and how you swing a sword or how the force is generated in the
hips just like kicks and punches in martial arts.

In Chinese, Kung Fu it is not the name of a martial art, the word to martial art is Wushu, kung fu refers to something you have learned through effort and time and often you can see in kung fu movies people totally unrelated to martial arts performing in fights because they can extrapolate that which they know well into other fields.

They have achieved the understanding of the Do, in Musashi terms.

A master programmer, like martial arts masters will also know well his environment and will have it set up properly to his advantage and will know to use the right tools for the job, he will also have the physical skills, typing
so fast and using shortcuts so effectively that a novice watching him work will have difficulty in understanding what is happening and it will look like arcane magic done by hand gestures.

He will design an interface in an IDE making things pop into existence one minute and in the following one, will drop to command line and set a server through ssh no sweat.

Well, that is what I think a master of programming would be.

May the code be with you.